Re: [PATCH 4/5] Net: ath5k, license is GPLv2

Started by unknown sender on Aug 29, 2007 · 10 messages from 6 authors · Last reply Aug 30, 2007

open the first message on its own page

Message details and related content
On Tue, 28 Aug 2007 18:11:55 BST, Christoph Hellwig said:
On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
quoted
ath5k, license is GPLv2

The files are available only under GPLv2 since now.
Is this really a good idea?  Most of the reverse-engineering was
done by the OpenBSD folks, and it would certainly be helpful to
work together with them on new hardware revisions, etc..
The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
to remove the BSD/other license.   Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.
Message details and related content
On 8/29/07, Valdis.Kletnieks@vt.edu [off-list ref] wrote:
The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
to remove the BSD/other license.   Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.
This mess has been occurring in the kernel for years. The DRM graphics
drivers are used in both BSD and Linux. It is quite easy to contribute
something to this code via LKML and think you are doing it under the
GPL. Doesn't a patch against the kernel have to be GPL? When these
patches get pulled back into BSD and distributed with it, did BSD get
infected with the GPL? AFAIK this has never been legally sorted out.

-- 
Jon Smirl
jonsmirl@gmail.com
Message details and related content
quoted
to remove the BSD/other license.   Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.
This mess has been occurring in the kernel for years. The DRM graphics
drivers are used in both BSD and Linux. It is quite easy to contribute
something to this code via LKML and think you are doing it under the
GPL. Doesn't a patch against the kernel have to be GPL? When these
patches get pulled back into BSD and distributed with it, did BSD get
infected with the GPL? AFAIK this has never been legally sorted out.
I'm not aware anyone has felt it needed "sorting out". Its not exactly
complicated.

	BSD non advertising is compatible with GPL

The GPL says:
	"when you distribute the same sections as part of a whole which
	is a work based on the Program, the distribution of the whole
	must be on the terms of this License, "

The BSD license doesn't conflict with that

The GPL (and copyright law also say)

"If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to ..."

All a bit irrelevant anyway as Ath5K code (not the .h file) say:

 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") version 2 as published by the Free
 * Software Foundation.

So Jiri is choosing to distribute it under the GPL, and with his changes
GPL only.

So whats the problem ?
Message details and related content
On 8/29/07, Alan Cox [off-list ref] wrote:
quoted
quoted
to remove the BSD/other license.   Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.
This mess has been occurring in the kernel for years. The DRM graphics
drivers are used in both BSD and Linux. It is quite easy to contribute
something to this code via LKML and think you are doing it under the
GPL. Doesn't a patch against the kernel have to be GPL? When these
patches get pulled back into BSD and distributed with it, did BSD get
infected with the GPL? AFAIK this has never been legally sorted out.
I'm not aware anyone has felt it needed "sorting out". Its not exactly
complicated.

        BSD non advertising is compatible with GPL

The GPL says:
        "when you distribute the same sections as part of a whole which
        is a work based on the Program, the distribution of the whole
        must be on the terms of this License, "

The BSD license doesn't conflict with that

The GPL (and copyright law also say)

"If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to ..."

All a bit irrelevant anyway as Ath5K code (not the .h file) say:

 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") version 2 as published by the Free
 * Software Foundation.

So Jiri is choosing to distribute it under the GPL, and with his changes
GPL only.

So whats the problem ?
BSD code can definitely be brought into a GPL project as you describe.
The problem is the other direction.

Aren't patches made against the kernel GPL'd if the author doesn't
explicitly grant them more liberal BSD license in addition?

The problem then comes in taking the patches that were only made
available against GPL code and reshipping them under the BSD license
without the author explicitly agreeing to this.

What if a patch spans both code that is pure GPL and code imported
from BSD, how do you license it?

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Message details and related content
Aren't patches made against the kernel GPL'd if the author doesn't
explicitly grant them more liberal BSD license in addition?
That would be the normal assumption.
The problem then comes in taking the patches that were only made
available against GPL code and reshipping them under the BSD license
without the author explicitly agreeing to this.

What if a patch spans both code that is pure GPL and code imported
from BSD, how do you license it?
See the acpi codebase for a worked example.

Alan
Message details and related content
On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
What if a patch spans both code that is pure GPL and code imported
from BSD, how do you license it?
I think it's a valid assumption, if we say that the author
of the patch read the license header of a file and agreed with it.
So the patch is licensed to whatever the fileheader says. And if
there's none, it's licensed with the COPYING terms.
If a patch author likes some other license conditions, he must
explicitely add them with the patch to the file, saying that this
and that part have these and those conditions. Of course they must
be compatible with the original license.

-- 
Greetings Michael.
Message details and related content
On 29-08-2007 21:37, Michael Buesch wrote:
On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
quoted
What if a patch spans both code that is pure GPL and code imported
from BSD, how do you license it?
I think it's a valid assumption, if we say that the author
of the patch read the license header of a file and agreed with it.
So the patch is licensed to whatever the fileheader says. And if
there's none, it's licensed with the COPYING terms.
If a patch author likes some other license conditions, he must
explicitely add them with the patch to the file, saying that this
and that part have these and those conditions. Of course they must
be compatible with the original license.
I didn't track this thread from the beginning, so maybe I repeat
somebody's ideas (probably like above), but IMHO: do we have to be
so selfish/pedantic? Can't we sometimes 'donate' a little bit to our
'older' bsd cousins or half-brothers? I think, it could be like this:

- if our changes are minor and authors of these changes don't mind
the file could stay BSD licensed only; plus we ask BSD to let it be
dual licensed (but no big hassle);

- otherwise, we should always distinctly mark all GPL parts.

Regards,
Jarek P.

PS: there is probably some mess with gmail addresses in this thread.
Message details and related content
Is it actually necessary to change the license?  With the dual-license, you can keep a single code-base for both BSD and Linux platforms, which seems terribly important to me.  It'd be awful to lose that.  It would be a maintenance nightmare for BSD.  Is it even possible--in real life, I mean--to accept GPLed patches into a BSD project?  Nightmare, I tell you!
Message details and related content
On 30-08-2007 13:59, Johannes Berg wrote:
On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
quoted
How about asking for changes to be dual-licenced too ?
In theory, that could work, but in practice relying on functions that
the Linux kernel offers in GPLv2-only headers etc. will make the result
GPLv2 anyway, and disentangling it would be a nightmare.
Why?

Very good point, but, in my opinion, it should be still resonable for
both sides: it simply means such changes are mostly unusable for the
other side, but nobody is going to waste time for marking all these
places, or care about suing if accidentally the changes, after some
adaptation, are usable for the other side. Unless you think or know
that "#include xyz" or "print_linux_way()" should add more than these
(maybe unusable) words or lines only?

Jarek P.
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help