Re: Code "borrowed" without attribution to original authors

[Sascha Hauer <s.hauer@pengutronix.de>]

On Wed, Oct 06, 2010 at 03:56:44PM +0200, Wolfgang Denk wrote:
> Dear Sascha,
> 
> In message <20101006072749.GR28242@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:
> 
> commit 6cd752f9:
> ...
>     The check condition is similat to what is in linux/next.
> 
> commit 18b5a4b4:
> ...
>     This makes it similar to what is in the kernel NAND driver.
> 
> commit aad4a28b:
> ...
>     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.
> 
> commit 4f41e7ea:
> ...
>     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.
> 
> commit aaa8eec5:
> ...
>     This patch adds support for NANDs greater than 2 GB.
>     Patch is based on the MTD NAND driver in the kernel.
> 
> commit 154b5484:
> ...
>     Update chipselect handling in davinci_nand.c so that it can
>     handle 2 GByte chips the same way Linux does:  as one device,
> 
> commit 8d2effea:
> ...
>     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
>     meanwhile.
> 
> commit c45912d8:
> ...
>     NAND: sync with 2.6.27
> 
>     This brings the core NAND code up to date with the Linux kernel.
> 
> commit cfa460ad:
> ...
>     Update MTD to that of Linux 2.6.22.1
> 
>     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 2.6.22.1 and will enable support for very large NAND devices
> 
> etc.
> 
> 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,
> for example:
> 
> 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?

We can (and actually I prefered Jean-Christophe had done it) add a
hint in the commit log saying that the code is derived from U-Boot,
but I will not dig through the U-Boot commit log to see who actually
made a commit looking similar to a barebox commit, and I do not expect
anyone to do so.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox