Hi all,
The ACPI AML interpreter (i.e. code in directories under drivers/acpi, but
not source in drivers/acpi directly) has been released by us (Intel) under
the GPL. It has also been released separately under a looser license, so
that other OS vendors may make use of it.
One consequence of this is that we have not been able to benefit directly
from patches from other Linux contributors. The reason is, patches submitted
to code only under the GPL must also be GPL, and therefore we cannot take
them directly and still make our code available under a license other than
the GPL. (We have to determine the problem the patch fixes and then do the
fix ourselves.)
This has slowed development and lessened community participation in the
development process.
In order to solve this, we are considering releasing the Linux version of
the interpreter under a dual license. This would allow direct incorporation
of changes. Any patches submitted against the ACPI core code would
implicitly be allowed to be used by us in a non-GPL context. This is already
done elsewhere in the Linux kernel source by the PCMCIA code, for example.
Comments?
Regards -- Andy
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
[email protected]
On Fri, Dec 06, 2002 at 04:10:00PM -0800, Grover, Andrew wrote:
> Hi all,
Hi Andrew,
>...
> One consequence of this is that we have not been able to benefit directly
> from patches from other Linux contributors. The reason is, patches submitted
> to code only under the GPL must also be GPL, and therefore we cannot take
> them directly and still make our code available under a license other than
> the GPL. (We have to determine the problem the patch fixes and then do the
> fix ourselves.)
>...
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
>
> Comments?
two comments regarding the right of an author to freely choose under
which license(s) he wants to make his patch available:
If a submitter wants to allow you to use his patch under both licenses
he's already able to allow you to do so.
You can't forbid people to send GPL-only patches, so if a person doesn't
want his patch under your looser license you can't enforce that he also
releases it under your looser license.
> Regards -- Andy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 7 Dec 2002 01:24:06 +0100, Adrian Bunk wrote:
>On Fri, Dec 06, 2002 at 04:10:00PM -0800, Grover, Andrew wrote:
>You can't forbid people to send GPL-only patches, so if a person doesn't
>want his patch under your looser license you can't enforce that he also
>releases it under your looser license.
No, but then you just reject the patch.
DS
On Fri, Dec 06, 2002 at 04:10:00PM -0800, Grover, Andrew wrote:
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
>
> Comments?
I think that's fine. Please use a known license for the second option,
i.e. MPL.
On Fri, Dec 06, 2002 at 04:36:13PM -0800, David Schwartz wrote:
> On Sat, 7 Dec 2002 01:24:06 +0100, Adrian Bunk wrote:
>
> >You can't forbid people to send GPL-only patches, so if a person doesn't
> >want his patch under your looser license you can't enforce that he also
> >releases it under your looser license.
>
> No, but then you just reject the patch.
Surely.
> DS
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 2002-12-07 at 00:10, Grover, Andrew wrote:
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
I think this is an extremely good idea. I certainly would have no
problem contributing cleanup/fixes to the project under those terms. And
if I did something large and mega cool with ACPI I can still GPL it only
and you can still ignore it 8)
There is a tradition of contributing patches back under the license the
project you are contributing to used (and ACPI is certainly big enough
to be 'a project' not just a patch)
Suits me fine
Alan
Grover, Andrew wrote:
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
I think this is great.
Since pcmcia already set an example with their license, I think it's a
great model to follow.
I also echo other comments to choose an already-known license like the
MPL or BSD (etc.) so that lawyers don't have extra work ;-)
Jeff
On Fri, Dec 06, 2002 at 04:10:00PM -0800, Grover, Andrew wrote:
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
Fine with me too. What would the other license be?
thanks,
greg k-h
In article <[email protected]>,
Adrian Bunk <[email protected]> wrote:
>
>You can't forbid people to send GPL-only patches, so if a person doesn't
>want his patch under your looser license you can't enforce that he also
>releases it under your looser license.
That's true, but on the other hand we've had these dual-license things
before (PCMCIA has been mentioned, but we've had reiserfs and a number
of drivers like aic7xxx too), and I don't think I've _ever_ gotten a
patch submission that disallowed the dual license.
In fact, I don't think I'd even merge a patch where the submitter tried
to limit dual-license code to a simgle license (it might happen with
some non-maintained stuff where the original source of the dual license
is gone, but if somebody tried to send me an ACPI patch that said "this
is GPL only", then I just wouldn't take it).
I suspect the same "refuse to accept license limiting patches" would be
true of most kernel maintainers. At least to me a choice of license by
the _original_ author is a hell of a lot more important than the
technical legality of then limiting it to just one license.
So yes, dual-license code can become GPL-only, but not in _my_ tree.
Somebody else can go off and make their own GPL-only additions, and
quite frankly I would find it so morally offensive to ignore the intent
of the original author that I wouldn't take the code even if it was an
improvement (and I've found that people who are narrow-minded about
licenses are narrow-minded about other things too, so I doubt it _would_
be an improvement).
Linus
Thanks Linus. I don't think that I have any inherent moral right to
dual-license reiserfs, but it sure is pragmatic to do so, and the
courtesy of permitting me to do so is gratefully accepted from our
contributors.
A bit more than half of our income comes from the dual licensing, and
we'd not have survived to this date fiscally without it. If anyone on
the reiserfs team ever owns a Boxster;-) at sometime in the future, it
will be from dual-licensing to Apple, a storage appliance vendor, or the
like.
Hans
Linus Torvalds wrote:
>In article <[email protected]>,
>Adrian Bunk <[email protected]> wrote:
>
>
>>You can't forbid people to send GPL-only patches, so if a person doesn't
>>want his patch under your looser license you can't enforce that he also
>>releases it under your looser license.
>>
>>
>
>That's true, but on the other hand we've had these dual-license things
>before (PCMCIA has been mentioned, but we've had reiserfs and a number
>of drivers like aic7xxx too), and I don't think I've _ever_ gotten a
>patch submission that disallowed the dual license.
>
>In fact, I don't think I'd even merge a patch where the submitter tried
>to limit dual-license code to a simgle license (it might happen with
>some non-maintained stuff where the original source of the dual license
>is gone, but if somebody tried to send me an ACPI patch that said "this
>is GPL only", then I just wouldn't take it).
>
>I suspect the same "refuse to accept license limiting patches" would be
>true of most kernel maintainers. At least to me a choice of license by
>the _original_ author is a hell of a lot more important than the
>technical legality of then limiting it to just one license.
>
>So yes, dual-license code can become GPL-only, but not in _my_ tree.
>
>Somebody else can go off and make their own GPL-only additions, and
>quite frankly I would find it so morally offensive to ignore the intent
>of the original author that I wouldn't take the code even if it was an
>improvement (and I've found that people who are narrow-minded about
>licenses are narrow-minded about other things too, so I doubt it _would_
>be an improvement).
>
> Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Followup to: <[email protected]>
By author: [email protected] (Linus Torvalds)
In newsgroup: linux.dev.kernel
>
> In fact, I don't think I'd even merge a patch where the submitter tried
> to limit dual-license code to a simgle license (it might happen with
> some non-maintained stuff where the original source of the dual license
> is gone, but if somebody tried to send me an ACPI patch that said "this
> is GPL only", then I just wouldn't take it).
>
> So yes, dual-license code can become GPL-only, but not in _my_ tree.
>
This is good. I'd like to keep klibc under a BSD/GPL license because
some people (e.g. Al Viro) have issued concerns about making a
nondynamic user-space library GPL or LGPL, and I pretty much agree
with their concerns. The current klibc tarball isn't completely
"untainted", since it contains "fixed"/modified kernel headers in a
few places, but I'm hoping to migrate those changes back into the
kernel headers proper once the merge is done.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Hi!
> In order to solve this, we are considering releasing the Linux version of
> the interpreter under a dual license. This would allow direct incorporation
> of changes. Any patches submitted against the ACPI core code would
> implicitly be allowed to be used by us in a non-GPL context. This is already
> done elsewhere in the Linux kernel source by the PCMCIA code, for example.
>
> Comments?
Good idea, and should have been done year
ago. I was always wondering why noone
patches ACPI :-).
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...