Code "borrowed" without attribution to original authors
s.hauer at pengutronix.de
Thu Oct 7 04:06:46 EDT 2010
On Wed, Oct 06, 2010 at 03:56:44PM +0200, Wolfgang Denk wrote:
> Dear Sascha,
> 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:
> 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
> 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 126.96.36.199
> 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 188.8.131.52 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,
> 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.
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 |
More information about the barebox