Code "borrowed" without attribution to original authors
wd at denx.de
Wed Oct 6 09:56:44 EDT 2010
In message <20101006072749.GR28242 at pengutronix.de> you wrote:
> > We all have been working long enough in free and open source software
> > projects that I can assume you are well aware of the basic principles
> > of open source software licensing and the requirement to attribute
> > code to its original authors.
> Does that mean U-Boot has credits to all the original mtd authors when
> updating U-Boots mtd support to a newer kernel? /me is digging in the
> archives; no, it has not. Does that mean with
We try hard to properly attribute code to the original sources. I do
not claim that everything in U-Boot is perfect, and if you look long
enough (and especially far enough back into our 10+ years of
history), you probably can find exceptions. We are trying to improve,
and we take all hints on such topics serious.
In each and everycase, whenever someone asked us (either on the
U-Boot mailing list or directly) about Copyright issues or similar
topics, we always addressed these questions directly and as good as
possible. Please feel free to search the archives.
In the specific case of MTD updates you mention here the commit
messages (extracted with "git log drivers/mtd") contain for example:
The check condition is similat to what is in linux/next.
This makes it similar to what is in the kernel NAND driver.
This was originally part of Thomas Gleixner's patch for
adding support for 4KiB pages.
This is not part of the U-Boot NAND driver so updating the
driver with this to sync up with the kernel NAND driver.
This patch updates the "chip_shift" calculation in the
NAND driver. This is being done to sync up the NAND driver with
the kernel NAND driver.
This patch adds support for NANDs greater than 2 GB.
Patch is based on the MTD NAND driver in the kernel.
Update chipselect handling in davinci_nand.c so that it can
handle 2 GByte chips the same way Linux does: as one device,
This patch brings the U-Boot MTD infrastructure in sync with the current
Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size
support and a resync of the mtdpart.c file which has seen multiple fixes
NAND: sync with 2.6.27
This brings the core NAND code up to date with the Linux kernel.
Update MTD to that of Linux 188.8.131.52
A lot changed in the Linux MTD code, since it was last ported from
Linux to U-Boot. This patch takes U-Boot NAND support to the level
of Linux 184.108.40.206 and will enable support for very large NAND devices
As you can see, we try to document where such code is coming from.
> 9b7076229ec6a958bd835ab70745f7676297ce82 Ilya Yanok is the original
> author of jffs2 summary support? No, it's the same in the Linux kernel.
No, he is not. Yes, you are right, proper attibution is missing in
this commit, too. Such cases can happen, even with sevral people
reviewing the submitted patches.
But as you can see from the many examples above we at least _try_ to
be careful about code atributions and copyrights.
> Does that mean you are the original author of include/linux/list.h in
> 700a0c648df72f2c8e0589c0d0470b5ffd7cab7b? Obviously not.
Ah, you have to go back to an example from 5 years ago? At the time
of that patch, the whole git project was just a mere 4 months old,
and git version control had been used for the Linux kernel for just a
very few weeks. There was no tradition to have Signed-off-by: lines
yet, etc. Many things were far from perfect, then.
But even then, the first line of the commit message reads:
Add common (with Linux) MTD partition scheme and ...
The wording "common (with Linux)" may not be really good either, but
at least it's a pretty clear hint. And the file in question is
located in include/linux/ , which also carries a certain meaning.
We have learned our lessons since then.
And if someone points out errors in our processes, we are answerable
for our mistakes and try to improve.
> Please lets go not down that road, it leads to nowhere.
> We obviously copy code from other projects like U-Boot and the kernel
> and we do our best to keep the copyrights intact, but we can only do
> this on a per file base, not on a per commit base. That said,
Please explain why it should be impossible in a commit message to say
that the hundreds of lines of code you add were not written by the
signees, but taken from somewhare else? In the examples I listed one
could even give the corresponding git commit ID from the U-Boot repo,
0ceafe1 Replace direct header access with the API routines
Copied from U-Boot commit b97a2a0
Do you think such a short hint cannot be done?
For your reference:
Author: Marian Balakowicz <m8 at semihalf.com>
Date: Tue Jan 8 18:14:09 2008 +0100
[new uImage] Define a API for image handling operations
- Add inline helper macros for basic header processing
- Move common non inline code common/image.c
===> - Replace direct header access with the API routines
- Rename IH_CPU_* to IH_ARCH_*
Signed-off-by: Marian Balakowicz <m8 at semihalf.com>
> common/image.c has a copyright to semihalf in U-Boot which is missing in
> barebox, we can add this. Note that Jean-Christophe added a copyright to
> *you* and not to *him* to this file, which means that he did not even
> try to put this his own work.
The copyright in the files is one thing. Attribution of large blocks
of code you import is another thing. My request is to attribute such code.
More information about the barebox