mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Wolfgang Denk <wd@denx.de>
Cc: barebox@lists.infradead.org
Subject: Re: Code "borrowed" without attribution to original authors
Date: Thu, 7 Oct 2010 10:06:46 +0200	[thread overview]
Message-ID: <20101007080646.GB28242@pengutronix.de> (raw)
In-Reply-To: <20101006135644.8D7051539A0@gemini.denx.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

  parent reply	other threads:[~2010-10-07  8:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-05 13:52 Wolfgang Denk
2010-10-05 16:00 ` Jean-Christophe PLAGNIOL-VILLARD
2010-10-05 16:20   ` Jean-Christophe PLAGNIOL-VILLARD
2010-10-05 17:53     ` Wolfgang Denk
2010-10-06  3:03       ` Jean-Christophe PLAGNIOL-VILLARD
2010-10-06  7:27 ` Sascha Hauer
2010-10-06 13:56   ` Wolfgang Denk
2010-10-07  7:38     ` Uwe Kleine-König
     [not found]       ` <20101007080810.EFDC4153A7E@gemini.denx.de>
2010-10-07  8:37         ` Uwe Kleine-König
2010-10-07  8:06     ` Sascha Hauer [this message]
2010-10-07  8:45       ` Wolfgang Denk
2010-10-07 12:45         ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101007080646.GB28242@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=wd@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox