On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> 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..
On 8/28/07, Christoph Hellwig <[email protected]> wrote:
> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> > 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..
Technically the best we can do is to leave the license as dual
licensed, but keep in that technically that means nothing and is just
for show, the GPL is what would apply as its derivative work and is
the most restrictive license. This applies to any other driver in the
kernel right now with a dual license tag.
Luis
> > 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 ?
On 30-08-2007 13:59, Johannes Berg wrote:
> On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
>
>> 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.
On 8/29/07, Alan Cox <[email protected]> wrote:
> > > 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
[email protected]
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.
> 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
On 29-08-2007 21:37, Michael Buesch wrote:
> 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.
>
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.
On 8/29/07, [email protected] <[email protected]> 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
[email protected]
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!
On Thu, Aug 30, 2007 at 10:26:52AM +0200, Jarek Poplawski wrote:
...
> PS: there is probably some mess with gmail addresses in this thread.
...or maybe it's OK... Sorry.
Jarek P.
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:
> > 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.