Message-ID: <20130328035018.GA11872@roeck-us.net>
Date:	Wed, 27 Mar 2013 20:50:18 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Lubomir Rintel <lkundrak@...sk>, linux-kernel@...r.kernel.org,
	Dom Cobley <popcornmix@...il.com>,
	Wim Van Sebroeck <wim@...ana.be>,
	linux-rpi-kernel@...ts.infradead.org,
	linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v4] watchdog: Add Broadcom BCM2835 watchdog timer driver

On Wed, Mar 27, 2013 at 09:00:29PM -0600, Stephen Warren wrote:
> On 03/27/2013 10:40 AM, Lubomir Rintel wrote:
> > This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
> > used in Raspberry Pi and Roku 2 devices.
> > 
> > Signed-off-by: Lubomir Rintel <lkundrak@...sk>
> > Signed-off-by: Dom Cobley <popcornmix@...il.com>
> 
> Those two s-o-b lines should be swapped, since if Dom did sign off on
> any part of this patch, he did it before you did.
> 
> That said...
> 
> I wonder if it's actually appropriate to include Dom's s-o-b here, since
> I don't think he really wrote this patch itself. I think you mentioned
> that you hadn't use much of the downstream driver except for some defines?
> 
> To be clear, I mentioned the existence of the S-o-b line downstream
> simply to demonstrate that the commits you were getting information from
> had correctly followed the process described in
> Documentation/SubmittingPatches, and so it was OK to use that
> information while creating a GPL'd driver.
> 
> So there are a couple of ways that this patch could have been created:
> 
> 1) You took the downstream commit itself, cherry-picked it into the
> upstream kernel, modified it to suit upstream, and then submitted that.
> The modifications might be extensive, such as renaming the file,
> removing parts of the code that the upstream watchdog core now handles,
> adding some new features, fixing bugs, cleanup, etc.; whatever is needed
> to upstream the patch.
> 
> In this case, I believe it would be appropriate to maintain any S-o-b
> lines from the original downstream commit, and add yours. But, I believe
> you should also (a) maintain the git author field from the original
> downstream commit (b) include a list of the changes you made to the
> patch in the commit description, so you can be blamed for them rather
> than the original author:-)
> 
> 2) You read the downstream commit for information, but created a
> completely new driver for the upstream kernel, using the downstream
> driver just as a reference. In this case, I believe it's fine for the
> git author field to be you, and for the only s-o-b line present to be
> yours, since you really did write the patch from scratch. However, you
> should credit the downstream work in the (c) header and/or commit
> description.
> 
> This current patch sees to be a slight hybrid of both approaches (you're
> listed as the git author, but have included Dom's s-o-b line on a patch
> I don't think he created, and wasn't directly derived from one he created).
> 
> I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van
> Sebroeck, since he's the watchdog maintainer and would be the person who
> applies this patch.
> 
I wondered about the same.

I think 2) would be more appropriate. My approach would have been to reference
previous work in the file header, something along the line of "derived from
xxx", and add a copyright statement from the original work if there was one -
pretty much what you propose above.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists