You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Noah Slater <ns...@apache.org> on 2008/07/18 20:11:47 UTC
Using a GPL library with Apache CouchDB
Hello,
The CouchDB community have been discussing the issues around using an external
library and/or bindings for full text database search.
A candidate that keeps coming up as a possibility for us is Xapian.
Xapian and it's libraries are covered by the GPL 2 or later, which includes the
GPL 3 which is "compatible" with the Apache Licence 2.
My question is, can CouchDB do any of the following:
* Write a full text search component for the core distribution that uses the
Xapian libraries that are installed on your system, without directly bundling
either Xapian or it's related libraries.
* As above but bundling Xapian or the library in the release artifact.
Thanks,
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by sebb <se...@gmail.com>.
On 18/07/2008, Noah Slater <ns...@apache.org> wrote:
> On Fri, Jul 18, 2008 at 08:20:32PM +0100, sebb wrote:
> > What about using Lucene Nutch instead?
>
>
> Well, I don't want to get into the discussion of what search technology people
> prefer as that is an ongoing debate, and yes Lucene has been mentioned. My
> personal opinion is that Java is a pretty heavy dependency for the core.
>
Sorry, I assumed that CouchDB was written in Java ...
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Noah Slater wrote:
> On Fri, Jul 18, 2008 at 08:20:32PM +0100, sebb wrote:
>> What about using Lucene Nutch instead?
>
> Well, I don't want to get into the discussion of what search technology people
> prefer as that is an ongoing debate, and yes Lucene has been mentioned. My
> personal opinion is that Java is a pretty heavy dependency for the core.
>
>>>From my understanding of the compatibility between the AL2 and the GPL3 is that
> you can base an AL2 licensed work on a GPL3 library without changing licensing.
>
> Is that not the case? If not, what does "compatible" mean?
>
> Please note, these are not rhetoric questions, I am genuinely confused. :)
Justin and Sam have it right, but you would be less confused if you consider
the converse question, why did the FSF claim that GPLv2 was incompatible
with AL 1.1 or 2.0?
In the case of AL 1.1, the GPL states the resulting license of the work
cannot contain additional restrictions. The AL 1.1 had a BSD-style advert
clause. Ergo, you couldn't combine GPLv2 and ALv1.1 into a workable
license.
In the case of AL 2.0, again the GPL states the resulting license of the
work cannot contain additional restrictions. The AL 2.0 has patent language
with respect to the work, and the FSF therefore found there was no license
that you could apply.
Of course, this is all balony if you are the author (or have agreement by
the authors) to license your work under GPL+++. There's nothing the FSF
can do if you publish under a GPL license plus additional terms, other than
insist that your license cannot be called GPL.
You cannot combine another authors' GPL published work and add terms without
their consent, so the FSF is effectively, if not literally, right.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Jul 18, 2008 at 1:51 PM, Noah Slater <ns...@apache.org> wrote:
> From my understanding of the compatibility between the AL2 and the GPL3 is that
> you can base an AL2 licensed work on a GPL3 library without changing licensing.
>
> Is that not the case? If not, what does "compatible" mean?
>
> Please note, these are not rhetoric questions, I am genuinely confused. :)
It's the opposite: "compatibility" means that you can incorporate AL2
into GPLv3 code, but, for the GPLv3, it doesn't work the other way.
-- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Noah Slater <ns...@apache.org>.
On Sat, Jul 19, 2008 at 10:57:56AM -0800, Philippe Ombredanne wrote:
> My 2 cents:
Thank you, I have forwarded this to the CouchDB list for discussion.
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Thu, 2008-07-24 at 19:39 -0700, Henri Yandell wrote:
> On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman <no...@devtech.com> wrote:
> > Sam Ruby wrote:
> >> Philippe Ombredanne wrote:
> >> > I can see potentially a path to using Xapian with CouchDB, but it would
> >> > involve:
> >> > - technology neutrality of the interface
> >> > - some work done outside of the ASF
> >> This approach is not dissimilar to utilizing mysql through JDBC, which
> >> is allowed.
> >
> > On a related note, consider the following...
> >
> > The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a myriad
> > of outside technologies. Presume that the ASF designs an AL licensed
> > management plugin interface that would be implemented per managed
> > technology. Some outside technologies to be managed might be GPL licensed.
> > What would be the issue(s) with hosting implementations of that plugin
> > interface where one or more implementations for external items to be managed
> > might touch GPL in order to implement that plugin for the GPL licensed
> > external entity?
>
> The questions we would ask ourselves would be:
>
> 1) Is the plugin interface deemed sufficient to make the GPL product
> and the main Apache product (Lokahi/Tashi) independent of each other?
> 2) Are we happy hosting the bridge code under GPL?
^GPL^Apache License. IMHO, we will not host any bridge code that is GPL
licensed.
If the bridge code is Apache Licensed and third parties decide to write
code against it that is GPL licensed, then this is perfectly fine with
me. We already have that:
http://svn.apache.org/viewvc/db/jdo/trunk/api2/src/java is the API
and
http://speedo.objectweb.org/
http://sourceforge.net/projects/jdoinstruments
are (L)GPLed implementations of that API.
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
Open Source Consulting, Development, Design |
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
char name_buf[257]; /* max unix filename is 256, right? */
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Santiago Gala <sa...@gmail.com>.
On Sun, Jul 27, 2008 at 2:10 PM, Santiago Gala <sa...@gmail.com> wrote:
> On Sat, Jul 26, 2008 at 10:47 PM, Ralph Goers
> <Ra...@dslextreme.com> wrote:
> (...)
>> As you referred to in your response, this is my pessimistic view. My
>> optimistic view is that they are out of their minds and that no court would
>> ever agree with them that simply using GPL'd code mandates that the work as
>> a whole be under the GPL, especially where such use is a small part of the
>> work as a whole.
>>
>
> Dont forget the non-exclusionary nature of software. Even if a court
> would mandate distribution of THE WORK AS A WHOLE under the GPL, the
> SCM revision just before the GPL code was added, or the changes after
> it that no are needed for the integration of the GPL work into THE
> WORK AS A WHOLE (i.e. the work previous to the addition + evolution)
> would still be under the AL 2.0 License.
>
> I mean, the fact that two works are integrated into a larger work,
> with potentially different copyright than any of the components, does
> not preclude the components to keep existing. It is much like the fact
> that a screen adaptation is done using "Macbeth", and gets
> copyrighted, does not impede the original play editions keep having
> their original copyright status (public domain or whatever) and/or
> licenses.
>
Note to self: never, ever, try again to write consistent English
legalese so close to siesta time, with 34C or so here. :)
> Regards
> Santiago
>
>>
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> DISCLAIMER: Discussions on this list are informational and educational
>> only. Statements made on this list are not privileged, do not
>> constitute legal advice, and do not necessarily reflect the opinions
>> and policies of the ASF. See <http://www.apache.org/licenses/> for
>> official ASF policies and documents.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Santiago Gala <sa...@gmail.com>.
On Sat, Jul 26, 2008 at 10:47 PM, Ralph Goers
<Ra...@dslextreme.com> wrote:
(...)
> As you referred to in your response, this is my pessimistic view. My
> optimistic view is that they are out of their minds and that no court would
> ever agree with them that simply using GPL'd code mandates that the work as
> a whole be under the GPL, especially where such use is a small part of the
> work as a whole.
>
Dont forget the non-exclusionary nature of software. Even if a court
would mandate distribution of THE WORK AS A WHOLE under the GPL, the
SCM revision just before the GPL code was added, or the changes after
it that no are needed for the integration of the GPL work into THE
WORK AS A WHOLE (i.e. the work previous to the addition + evolution)
would still be under the AL 2.0 License.
I mean, the fact that two works are integrated into a larger work,
with potentially different copyright than any of the components, does
not preclude the components to keep existing. It is much like the fact
that a screen adaptation is done using "Macbeth", and gets
copyrighted, does not impede the original play editions keep having
their original copyright status (public domain or whatever) and/or
licenses.
Regards
Santiago
>
> Ralph
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Jul 27, 2008 at 2:52 AM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
> Sam Ruby wrote:
>>
>> Both the GPL and FSF are clear on this matter: simple 'use' of GPL
>> software does not require modifications to programs (even to the
>> original GPL software itself!) to be released in any form.
>>
>> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
>>
>> - Sam Ruby
>
> I'm not sure why you linked to that particular FAQ. All it speaks to is that
> you are free to do what you want if you don't distribute the software.
But... that's key. If we don't distribute MySQL or its driver, then
are not 'copying', and the GPL (which ultimately is a copyright
license) does not apply.
If a user assembles an ASF project which uses JDBC, and then installs
MySQL and its driver separately, and then wires them together, and
does not distribute the result -- even if they make modifications to
one or more of the components -- then that link speaks to what it
required of them.
> http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper
Yes, that is relevant; but only to those who are interested in copying
and distributing works derived from GPL-covered parts. Since we are
interested in enabling people to produce and distribute works derived
from Apache projects under terms to do so under terms under terms no
more restrictive than those of the Apache License, Version 2.0 itself;
we need to make sure that dependencies on projects like MySQL are
truly optional.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sam Ruby wrote:
>
>
> Both the GPL and FSF are clear on this matter: simple 'use' of GPL
> software does not require modifications to programs (even to the
> original GPL software itself!) to be released in any form.
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
>
> - Sam Ruby
>
>
I'm not sure why you linked to that particular FAQ. All it speaks to is
that you are free to do what you want if you don't distribute the software.
I think more appropriate links are
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation,
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem and most
especially relevant to this discussion
http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper.
Ralph
<http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jul 26, 2008 at 4:47 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
> Henri Yandell wrote:
>>
>> On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ra...@dslextreme.com>
>> wrote:
>>
>>> Henri Yandell wrote:
>>>
>>>> So, wrt my reply:
>>>>
>>>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>>>> occurs).
>>>> 2) We decide if we're happy to host the bridge to the GPL work, which
>>>> we decide if we want to release under AL 2.0 or GPL.
>>>
>>> This makes no sense to me. Forget for a moment that many think the FSF's
>>> position on derivative works is total nonsense. Going by their position
>>> the
>>> bridge code must be licensed under the GPL and can't be Apache licensed
>>> since it is a derivative work of the project being bridged.
>>
>> Here's my reasoning here.
>>
>> If I take a GPL project, and add a new feature by inlining a piece of
>> existing Apache code, I don't magically affect the original licensing
>> of that existing Apache code, only the fact that it is now in or with
>> a larger piece of GPL'd work. Similarly, we should be able to consider
>> any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
>> library and then consider GPL as a larger licensing affecting it when
>> that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
>> if we decide we're concerned about the GPLv2 compatibility bit and
>> we're talking GPLv2.
>
> My understanding is the FSF's position is that you can take something under
> the Apache license and use it from a GPL'd work with no problems (at least
> with GPL3) but the whole work will be under the GPL. OTOH, if you take
> something under the Apache license and provide some kind of glue to the
> GPL'd work, then the GPL "infects" the Apache licensed work because it is a
> derivative work and requires the distribution as a whole to be GPL'd. The
> code under the Apache license remains only under the Apache license.
> However, if the Apache licensed code can't easily be separated from the
> GPL'd code then it might as well be under the GPL.
>
> As you referred to in your response, this is my pessimistic view. My
> optimistic view is that they are out of their minds and that no court would
> ever agree with them that simply using GPL'd code mandates that the work as
> a whole be under the GPL, especially where such use is a small part of the
> work as a whole.
Both the GPL and FSF are clear on this matter: simple 'use' of GPL
software does not require modifications to programs (even to the
original GPL software itself!) to be released in any form.
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henri Yandell <ba...@apache.org>.
On Sat, Jul 26, 2008 at 11:32 PM, Henri Yandell <ba...@apache.org> wrote:
> On Sat, Jul 26, 2008 at 1:47 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
>>
>>
>> Henri Yandell wrote:
>>>
>>> On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ra...@dslextreme.com>
>>> wrote:
>>>
>>>>
>>>> Henri Yandell wrote:
>>>>
>>>>>
>>>>> So, wrt my reply:
>>>>>
>>>>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>>>>> occurs).
>>>>> 2) We decide if we're happy to host the bridge to the GPL work, which
>>>>> we decide if we want to release under AL 2.0 or GPL.
>>>>>
>>>>>
>>>>
>>>> This makes no sense to me. Forget for a moment that many think the FSF's
>>>> position on derivative works is total nonsense. Going by their position
>>>> the
>>>> bridge code must be licensed under the GPL and can't be Apache licensed
>>>> since it is a derivative work of the project being bridged.
>>>>
>>>
>>> Here's my reasoning here.
>>>
>>> If I take a GPL project, and add a new feature by inlining a piece of
>>> existing Apache code, I don't magically affect the original licensing
>>> of that existing Apache code, only the fact that it is now in or with
>>> a larger piece of GPL'd work. Similarly, we should be able to consider
>>> any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
>>> library and then consider GPL as a larger licensing affecting it when
>>> that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
>>> if we decide we're concerned about the GPLv2 compatibility bit and
>>> we're talking GPLv2.
>>>
>>
>> My understanding is the FSF's position is that you can take something under
>> the Apache license and use it from a GPL'd work with no problems (at least
>> with GPL3) but the whole work will be under the GPL. OTOH, if you take
>> something under the Apache license and provide some kind of glue to the
>> GPL'd work, then the GPL "infects" the Apache licensed work because it is a
>> derivative work and requires the distribution as a whole to be GPL'd. The
>> code under the Apache license remains only under the Apache license.
>> However, if the Apache licensed code can't easily be separated from the
>> GPL'd code then it might as well be under the GPL.
>
> Exactly.
>
> Our source code remains AL 2.0, but when we distributed it for use
> with a GPL product, it is inside a GPL package (though I don't
> understand if that means the code is now dual-licensed, or whether the
> source is AL 2.0 but there is some vague and translucent GPL ether
> surrounding it).
>
> There is a good reason for doing this. It allows someone (imo) to
> take, say a Mysql JDBC driver, and create a Derby JDBC driver from it
> without affecting the licensing of the new Derby driver. If we simply
> applied GPL to it all, then we would have to treat that authored code
> as a risky source.
>
> So... I'm somewhat tempted by the idea of our still writing source
> under a GPL compatible license, and then having some level of GPL
> apply to the release.
>
> We're getting quite far down the hypothetical path though - time to
> wait for a real use case I think.
Before I start a 'wtf' thread there, I'm supposing we wrote the Mysql
JDBC driver. I don't mean any existing driver.
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henri Yandell <ba...@apache.org>.
On Sat, Jul 26, 2008 at 1:47 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
>
> Henri Yandell wrote:
>>
>> On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ra...@dslextreme.com>
>> wrote:
>>
>>>
>>> Henri Yandell wrote:
>>>
>>>>
>>>> So, wrt my reply:
>>>>
>>>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>>>> occurs).
>>>> 2) We decide if we're happy to host the bridge to the GPL work, which
>>>> we decide if we want to release under AL 2.0 or GPL.
>>>>
>>>>
>>>
>>> This makes no sense to me. Forget for a moment that many think the FSF's
>>> position on derivative works is total nonsense. Going by their position
>>> the
>>> bridge code must be licensed under the GPL and can't be Apache licensed
>>> since it is a derivative work of the project being bridged.
>>>
>>
>> Here's my reasoning here.
>>
>> If I take a GPL project, and add a new feature by inlining a piece of
>> existing Apache code, I don't magically affect the original licensing
>> of that existing Apache code, only the fact that it is now in or with
>> a larger piece of GPL'd work. Similarly, we should be able to consider
>> any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
>> library and then consider GPL as a larger licensing affecting it when
>> that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
>> if we decide we're concerned about the GPLv2 compatibility bit and
>> we're talking GPLv2.
>>
>
> My understanding is the FSF's position is that you can take something under
> the Apache license and use it from a GPL'd work with no problems (at least
> with GPL3) but the whole work will be under the GPL. OTOH, if you take
> something under the Apache license and provide some kind of glue to the
> GPL'd work, then the GPL "infects" the Apache licensed work because it is a
> derivative work and requires the distribution as a whole to be GPL'd. The
> code under the Apache license remains only under the Apache license.
> However, if the Apache licensed code can't easily be separated from the
> GPL'd code then it might as well be under the GPL.
Exactly.
Our source code remains AL 2.0, but when we distributed it for use
with a GPL product, it is inside a GPL package (though I don't
understand if that means the code is now dual-licensed, or whether the
source is AL 2.0 but there is some vague and translucent GPL ether
surrounding it).
There is a good reason for doing this. It allows someone (imo) to
take, say a Mysql JDBC driver, and create a Derby JDBC driver from it
without affecting the licensing of the new Derby driver. If we simply
applied GPL to it all, then we would have to treat that authored code
as a risky source.
So... I'm somewhat tempted by the idea of our still writing source
under a GPL compatible license, and then having some level of GPL
apply to the release.
We're getting quite far down the hypothetical path though - time to
wait for a real use case I think.
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Ralph Goers <Ra...@dslextreme.com>.
Henri Yandell wrote:
> On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
>> Henri Yandell wrote:
>>
>>> So, wrt my reply:
>>>
>>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>>> occurs).
>>> 2) We decide if we're happy to host the bridge to the GPL work, which
>>> we decide if we want to release under AL 2.0 or GPL.
>>>
>>>
>> This makes no sense to me. Forget for a moment that many think the FSF's
>> position on derivative works is total nonsense. Going by their position the
>> bridge code must be licensed under the GPL and can't be Apache licensed
>> since it is a derivative work of the project being bridged.
>>
>
> Here's my reasoning here.
>
> If I take a GPL project, and add a new feature by inlining a piece of
> existing Apache code, I don't magically affect the original licensing
> of that existing Apache code, only the fact that it is now in or with
> a larger piece of GPL'd work. Similarly, we should be able to consider
> any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
> library and then consider GPL as a larger licensing affecting it when
> that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
> if we decide we're concerned about the GPLv2 compatibility bit and
> we're talking GPLv2.
>
My understanding is the FSF's position is that you can take something
under the Apache license and use it from a GPL'd work with no problems
(at least with GPL3) but the whole work will be under the GPL. OTOH, if
you take something under the Apache license and provide some kind of
glue to the GPL'd work, then the GPL "infects" the Apache licensed work
because it is a derivative work and requires the distribution as a whole
to be GPL'd. The code under the Apache license remains only under the
Apache license. However, if the Apache licensed code can't easily be
separated from the GPL'd code then it might as well be under the GPL.
As you referred to in your response, this is my pessimistic view. My
optimistic view is that they are out of their minds and that no court
would ever agree with them that simply using GPL'd code mandates that
the work as a whole be under the GPL, especially where such use is a
small part of the work as a whole.
Ralph
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henri Yandell <ba...@apache.org>.
On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
>
> Henri Yandell wrote:
>>
>> So, wrt my reply:
>>
>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>> occurs).
>> 2) We decide if we're happy to host the bridge to the GPL work, which
>> we decide if we want to release under AL 2.0 or GPL.
>>
>
> This makes no sense to me. Forget for a moment that many think the FSF's
> position on derivative works is total nonsense. Going by their position the
> bridge code must be licensed under the GPL and can't be Apache licensed
> since it is a derivative work of the project being bridged.
Here's my reasoning here.
If I take a GPL project, and add a new feature by inlining a piece of
existing Apache code, I don't magically affect the original licensing
of that existing Apache code, only the fact that it is now in or with
a larger piece of GPL'd work. Similarly, we should be able to consider
any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
library and then consider GPL as a larger licensing affecting it when
that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
if we decide we're concerned about the GPLv2 compatibility bit and
we're talking GPLv2.
I think that's all quite complex though and it's probably easier to
say "Keep the bridge library small" and "use GPL".
> Getting even more paranoid, I'd argue that simply creating a bridge
> interface doesn't really help if the only thing around to implement it is
> under the GPL (i.e. the bridge to the "real" thing) . If push came to shove
> I'd imagine someone who liked to pay lawyers would argue that was just some
> fancy way to dance around the problem and the work using the bridge API was
> still a derivative. However, with multiple implementations I'd find it hard
> to believe anyone would go along with that.
I think we would mandate as policy that there must be alternatives. So
if you wanted to use gnu-regexp, you would have to do so through a
commons-regexp facade that let you talk to ORO as well. In the Lokahi
example, the plugin interface would have to be used for other
applications too. You couldn't hardware permissive things in and then
have a 'GPL licensed plugin'.
> Of course, maybe the FSF has relaxed their position on what a derivative
> work is since the last time I checked. I'm well aware that many folks using
> the GPL don't even seem to agree with them.
No clue :) I like to take a pessimistic view; am just thinking out loud above.
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Ralph Goers <Ra...@dslextreme.com>.
Henri Yandell wrote:
>
> So, wrt my reply:
>
> 1) We judge if that bridging/plugin API is sufficient (ie: no binding occurs).
> 2) We decide if we're happy to host the bridge to the GPL work, which
> we decide if we want to release under AL 2.0 or GPL.
>
This makes no sense to me. Forget for a moment that many think the
FSF's position on derivative works is total nonsense. Going by their
position the bridge code must be licensed under the GPL and can't be
Apache licensed since it is a derivative work of the project being bridged.
Getting even more paranoid, I'd argue that simply creating a bridge
interface doesn't really help if the only thing around to implement it
is under the GPL (i.e. the bridge to the "real" thing) . If push came to
shove I'd imagine someone who liked to pay lawyers would argue that was
just some fancy way to dance around the problem and the work using the
bridge API was still a derivative. However, with multiple
implementations I'd find it hard to believe anyone would go along with that.
Of course, maybe the FSF has relaxed their position on what a derivative
work is since the last time I checked. I'm well aware that many folks
using the GPL don't even seem to agree with them.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Jul 24, 2008 at 7:49 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Henri Yandell wrote:
>>
>> On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman <no...@devtech.com> wrote:
>>>
>>> Sam Ruby wrote:
>>>>
>>>> Philippe Ombredanne wrote:
>>>>>
>>>>> I can see potentially a path to using Xapian with CouchDB, but it would
>>>>> involve:
>>>>> - technology neutrality of the interface
>>>>> - some work done outside of the ASF
>>>>
>>>> This approach is not dissimilar to utilizing mysql through JDBC, which
>>>> is allowed.
>>>
>>> On a related note, consider the following...
>>>
>>> The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a
>>> myriad
>>> of outside technologies. Presume that the ASF designs an AL licensed
>>> management plugin interface that would be implemented per managed
>>> technology. Some outside technologies to be managed might be GPL
>>> licensed.
>>> What would be the issue(s) with hosting implementations of that plugin
>>> interface where one or more implementations for external items to be
>>> managed
>>> might touch GPL in order to implement that plugin for the GPL licensed
>>> external entity?
>>
>> The questions we would ask ourselves would be:
>>
>> 1) Is the plugin interface deemed sufficient to make the GPL product
>> and the main Apache product (Lokahi/Tashi) independent of each other?
>> 2) Are we happy hosting the bridge code under GPL?
>>
>> The first is specific so we would hit that when the time comes. For
>> the second, I claim the answer would be "Yes" depending on:
>>
>> b) The existence of the bridge makes the main Apache product more
>> valuable (PMC's decision).
>> a) The code for that bridge is relatively small compared to the rest
>> of the product.
>
> Are we talking GPL or LGPL?
He said GPL :) We're talking GPL.
> No matter how it stacks up, any GPL binding makes the resulting work GPL.
>
> So, if it's bound to the main project, I think the answer is no.
'bind/bound' = what? :) I'm guessing this is what'll lead to your
further conversation with Joe; I'm assuming you are defining 'bind' as
anything that makes the resulting work GPL.
Hypothetical - We have a project that has a bridging/plugin API. They
then create two implementations/bridges of the API, one to a GPL work
and one to an AL 2.0 work.
So, wrt my reply:
1) We judge if that bridging/plugin API is sufficient (ie: no binding occurs).
2) We decide if we're happy to host the bridge to the GPL work, which
we decide if we want to release under AL 2.0 or GPL.
We would never distribute the GPL work. As AL 2.0 is compatible with
GPLv3 (and we believe with GPLv2), I don't see any reason why we
couldn't release our unbound source/binary under our own license, but
it might confuse. To avoid confusion, I would also recommend that we
release that bridge independently of the main product.
> If it's a command line stub, and the main project is AL, then it's something
> to consider. It would be nice to hear from the denizens of the GPL world
> on this subject.
Command line stub = some form of bridging API mechanism? Or are we
literally talking about invoking things on the command line, which
takes us miles away from any license issues and on to politics (ie: I
see nothing wrong with an ASF application invoking a GPL app, it's
just another license).
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jul 24, 2008 at 10:49 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Henri Yandell wrote:
>>
>> On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman <no...@devtech.com> wrote:
>>>
>>> Sam Ruby wrote:
>>>>
>>>> Philippe Ombredanne wrote:
>>>>>
>>>>> I can see potentially a path to using Xapian with CouchDB, but it would
>>>>> involve:
>>>>> - technology neutrality of the interface
>>>>> - some work done outside of the ASF
>>>>
>>>> This approach is not dissimilar to utilizing mysql through JDBC, which
>>>> is allowed.
>>>
>>> On a related note, consider the following...
>>>
>>> The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a
>>> myriad
>>> of outside technologies. Presume that the ASF designs an AL licensed
>>> management plugin interface that would be implemented per managed
>>> technology. Some outside technologies to be managed might be GPL
>>> licensed.
>>> What would be the issue(s) with hosting implementations of that plugin
>>> interface where one or more implementations for external items to be
>>> managed
>>> might touch GPL in order to implement that plugin for the GPL licensed
>>> external entity?
>>
>> The questions we would ask ourselves would be:
>>
>> 1) Is the plugin interface deemed sufficient to make the GPL product
>> and the main Apache product (Lokahi/Tashi) independent of each other?
>> 2) Are we happy hosting the bridge code under GPL?
>>
>> The first is specific so we would hit that when the time comes. For
>> the second, I claim the answer would be "Yes" depending on:
>>
>> b) The existence of the bridge makes the main Apache product more
>> valuable (PMC's decision).
>> a) The code for that bridge is relatively small compared to the rest
>> of the product.
>
> Are we talking GPL or LGPL?
>
> No matter how it stacks up, any GPL binding makes the resulting work GPL.
The word "any" is too far reaching.
> So, if it's bound to the main project, I think the answer is no.
>
> If it's a command line stub, and the main project is AL, then it's something
> to consider. It would be nice to hear from the denizens of the GPL world
> on this subject.
A command line stub would meet the criteria of "any" yet clearly is OK.
JDBC is a a "standard" interface which we can implement under our
license. Those that implement the "other half" of that interface may
do so under their choice of license, including proprietary or Free
licenses. Oracle and MySQL are examples of such implementations, and
both may be used (but not distributed with) through JDBC with Apache
projects.
> Bill
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Fri, 7/25/08, Henning Schmiedehausen <hp...@intermeta.de> wrote:
> >
> > 1.2. How is Xen licensed?
> >
> > Xen is Open Source, and is released under terms of the
> > GNU General Public License. Operating systems or other
> > applications written to use Xen's hypercall interface
> > are not derived works of Xen, hence may be licensed
> > differently.
> That is the hypervisor and without that exception, you e.g.
> couldn't run
> *BSD or Windows under it.
>
> We are talking C-API and that is (AFAICS) firmly GPL
> licensed.
It depends on what part of the C API you are using then. Some
of the API is LGPL (ie the piece libvirt interfaces with), and
AFAICT most, if not all, of the python API it ships with
is LGPL as well.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Thu, 2008-07-24 at 20:59 -0700, Joe Schaefer wrote:
> Here's a statement from a GPL user [1]:
>
> 1.2. How is Xen licensed?
>
> Xen is Open Source, and is released under terms of the GNU General Public License. Operating systems or other applications written to use Xen's hypercall interface are not derived works of Xen, hence may be licensed differently.
>
>
> [1]http://wiki.xensource.com/xenwiki/XenFaq#head-4086ca7d1e78bcb5d40ffebae5b84881881851fa
That is the hypervisor and without that exception, you e.g. couldn't run
*BSD or Windows under it.
We are talking C-API and that is (AFAICS) firmly GPL licensed.
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | JEE, Linux, Unix
91054 Buckenhof, Germany -- +49 9131 506540 | Apache Java Software
Open Source Consulting, Development, Design |
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
char name_buf[257]; /* max unix filename is 256, right? */
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Thu, 7/24/08, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> No matter how it stacks up, any GPL binding makes the
> resulting work GPL.
Bzzt.
> So, if it's bound to the main project, I think the
> answer is no.
>
> If it's a command line stub, and the main project is
> AL, then it's something
> to consider. It would be nice to hear from the denizens of
> the GPL world on this subject.
Here's a statement from a GPL user [1]:
1.2. How is Xen licensed?
Xen is Open Source, and is released under terms of the GNU General Public License. Operating systems or other applications written to use Xen's hypercall interface are not derived works of Xen, hence may be licensed differently.
[1]http://wiki.xensource.com/xenwiki/XenFaq#head-4086ca7d1e78bcb5d40ffebae5b84881881851fa
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henri Yandell wrote:
> On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman <no...@devtech.com> wrote:
>> Sam Ruby wrote:
>>> Philippe Ombredanne wrote:
>>>> I can see potentially a path to using Xapian with CouchDB, but it would
>>>> involve:
>>>> - technology neutrality of the interface
>>>> - some work done outside of the ASF
>>> This approach is not dissimilar to utilizing mysql through JDBC, which
>>> is allowed.
>> On a related note, consider the following...
>>
>> The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a myriad
>> of outside technologies. Presume that the ASF designs an AL licensed
>> management plugin interface that would be implemented per managed
>> technology. Some outside technologies to be managed might be GPL licensed.
>> What would be the issue(s) with hosting implementations of that plugin
>> interface where one or more implementations for external items to be managed
>> might touch GPL in order to implement that plugin for the GPL licensed
>> external entity?
>
> The questions we would ask ourselves would be:
>
> 1) Is the plugin interface deemed sufficient to make the GPL product
> and the main Apache product (Lokahi/Tashi) independent of each other?
> 2) Are we happy hosting the bridge code under GPL?
>
> The first is specific so we would hit that when the time comes. For
> the second, I claim the answer would be "Yes" depending on:
>
> b) The existence of the bridge makes the main Apache product more
> valuable (PMC's decision).
> a) The code for that bridge is relatively small compared to the rest
> of the product.
Are we talking GPL or LGPL?
No matter how it stacks up, any GPL binding makes the resulting work GPL.
So, if it's bound to the main project, I think the answer is no.
If it's a command line stub, and the main project is AL, then it's something
to consider. It would be nice to hear from the denizens of the GPL world
on this subject.
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jul 28, 2008 at 7:42 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>
> --- On Mon, 7/28/08, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> I'm not exactly clear how Xen got introduced into this conversation,
>> but it makes a great example. The FSF has made both GPL
>> and LGPL licenses available, the key difference being how they treat
>> other applications which make use of the interfaces provided.
>> For us to treat statements on a wiki (on a wiki!) that ascribe the
>> behavior of the LGPL to the GPL as somehow being more authoritative
>> than what the license itself may say boggles the mind.
>
> Fortunately nobody's suggesting that. What I am suggesting when it
> comes to Xen is not to read the FAQ, but to get specific about which
> interfaces are actually required. Because as I've said many times now,
> the license under discussion will depend on which interface people
> want to use. It's not all GPL by any stretch, and being the copyright
> holders they *can* provide LGPL'd (or BSD'd) interfaces to GPL'd code.
Cool. If they provide an interface under a license listed on
<http://www.apache.org/legal/resolved.html> as "considered to be
similar in terms", there is no need to check back here. If the
license differs, lets discuss, and we will see what we can do.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Assaf Arkin <ar...@intalio.com>.
>From the FAQ: "Operating systems or other applications written to use
Xen's hypercall interface are not derived works of Xen, hence may be
licensed differently." That's at best a clarification. To be usable
as permission, I need to know exactly which portions of the code I'm
allowed to use in a manner that deviates from the GPL.
Which, thankfully Xen takes care of by applying the appropriate licenses:
http://xenbits.xensource.com/xen-3.2-testing.hg?file/6de4320d71f9/COPYING
2GNU General Public License
3--------------------------
4
5Most files in this repository are licensed under the terms of the GNU
6General Public License (GPL), a copy of which is attached at the end
7of this notice. Note that the only valid version of the GPL as far as
8the files in this repository are concerned is _this_ particular
9version of the license (i.e., *only* v2, not v2.2 or v3.x or
10whatever), unless explicitly otherwise stated.
11
12Licensing Exceptions (the relaxed BSD-style license)
13----------------------------------------------------
14
15For the convenience of users and those who are porting OSes to run as
16Xen guests, certain files in this repository are not subject to the
17GPL when distributed separately or included in software packages
18outside this repository. Instead we specify a much more relaxed
19BSD-style license. Affected files include the Xen interface headers
20(xen/include/public/COPYING), and various drivers, support functions
21and header files within the Linux source trees on
22http://xenbits.xensource.com/linux-2.6.X-xen.hg. In all such cases,
23license terms are stated at the top of the file or in a COPYING file
24in the same directory. Note that _any_ file that is modified and then
25distributed within a Linux kernel is still subject to the GNU GPL.
A couple of examples from include/public:
http://xenbits.xensource.com/xen-3.2-testing.hg?file/6de4320d71f9/xen/include/public/COPYING
http://xenbits.xensource.com/xen-3.2-testing.hg?file/6de4320d71f9/xen/include/public/callback.h
Assaf
On Mon, Jul 28, 2008 at 2:35 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Mon, Jul 28, 2008 at 2:02 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> If, however, the owners of the program are claiming that parts of
>> their code are covered under GPLv2, and other parts which would be
>> covered by clause 2b of GPLv2 are not subject to the terms of GPLv2,
>> then we have a contradiction that needs to be resolved. One way to
>> view this is that it is not our problem, and that the owners have
>> reduced their ability to pursue claims of copyright infringement.
>
> Remember that Xen is free to license their code (or parts of their
> code) under as many licenses as they like. (For a fee, you can likely
> get Xen from Citrix under another license.) The GPL isn't exclusive.
> So, for those files in include/public/, one set of terms Xen has
> decided to offer to the public is GPLv2 and another option is the
> BSD-style license.
>
> I think, in this case given the Xen team's comments in COPYING, their
> intent for the exception is about as clear as it could ever be given
> the constraints of the GPL. The risk for us and our downstream
> users/developers using those headers covered by the exception is, I
> feel, minimal and darn close to zero.
>
>> However, they may not have that option if their code constitutes "a
>> work based on" another program also made available under the GPLv2
>> license.
>
> True, but I don't believe that's the case here. -- justin
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Jul 28, 2008 at 2:02 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> If, however, the owners of the program are claiming that parts of
> their code are covered under GPLv2, and other parts which would be
> covered by clause 2b of GPLv2 are not subject to the terms of GPLv2,
> then we have a contradiction that needs to be resolved. One way to
> view this is that it is not our problem, and that the owners have
> reduced their ability to pursue claims of copyright infringement.
Remember that Xen is free to license their code (or parts of their
code) under as many licenses as they like. (For a fee, you can likely
get Xen from Citrix under another license.) The GPL isn't exclusive.
So, for those files in include/public/, one set of terms Xen has
decided to offer to the public is GPLv2 and another option is the
BSD-style license.
I think, in this case given the Xen team's comments in COPYING, their
intent for the exception is about as clear as it could ever be given
the constraints of the GPL. The risk for us and our downstream
users/developers using those headers covered by the exception is, I
feel, minimal and darn close to zero.
> However, they may not have that option if their code constitutes "a
> work based on" another program also made available under the GPLv2
> license.
True, but I don't believe that's the case here. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jul 28, 2008 at 5:30 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Excuse me for butting in, but you may be trying to accomplish more than ASF
> has the time or inclination to do.
Please feel free to "butt in" at any time.
> As long as we do not actually distribute software under other licenses, then
> creating dependencies on that software is not copyright infringement. It
> isn't even contributory to copyright infringement. There is certainly no
> copyright licensing obligation relating to that other software. Dependencies
> on GPL code may be disfavored for other reasons, but worrying about
> copyright infringement isn't one of them.
"other reasons" (as described in [1], under Approximation 1) include a
desire to ensure that dependencies are licensed under similar terms.
> ASF's sole obligation is to let people know what they're getting from ASF,
> including disclosing external dependencies. That is a commercial nicety
> (backed up by our disclaimer of warranty!), but it is not a copyright law or
> licensing obligation.
>
> This also presents a huge opportunity for individual ASF members to set up
> separate (and presumably profitable) businesses combining and distributing
> Apache and other software in functional combinations as services or products
> for customers. You can scrub the licenses and determine for yourselves if
> you can risk distributing such combination software. In most cases, you'll
> find that you can.
If the dependency is purely optional, or represents a strategic
decision of the ASF (for example, our decision to pursue Java despite
the fact that it was not then licensed under "similar terms", nor is
it now) then I have no problem with it. See also Approximation 3 on
the same page.
> /Larry
[1] http://www.apache.org/legal/ramblings.html
- Sam Ruby
>> -----Original Message-----
>> From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
>> Sent: Monday, July 28, 2008 2:03 PM
>> To: legal-discuss@apache.org
>> Subject: Re: Licenses are not always what they seem [was: RE: GPL
>> licensing question ...]
>>
>> On Mon, Jul 28, 2008 at 4:32 PM, Justin Erenkrantz
>> <ju...@erenkrantz.com> wrote:
>> > On Mon, Jul 28, 2008 at 1:12 PM, Sam Ruby <ru...@intertwingly.net>
>> wrote:
>> >> Agreed. Just so that we are clear, and using Xen as a example. Xen
>> >> has a hypercall interface[1]. If an ASF project wishes to make use of
>> >> this interface, the statement currently appearing on the Xen wiki[2]
>> >> is not sufficient.
>> >
>> > I don't know if you overlooked my earlier posts referring to it, but
>> > how are the exceptions listed Xen's COPYING insufficient
>> > (http://lxr.xensource.com/lxr/source/COPYING)? -- justin
>>
>> You previously said you were comfortable relying on that. I don't yet
>> have sufficient information to be as comfortable as you appear to be.
>> Permit me to explain.
>>
>> Placing two discrete things in the same hg repository or in the same
>> tarball does not require them both to be licensed equivalently, so
>> there is no concern there.
>>
>> If, however, the owners of the program are claiming that parts of
>> their code are covered under GPLv2, and other parts which would be
>> covered by clause 2b of GPLv2 are not subject to the terms of GPLv2,
>> then we have a contradiction that needs to be resolved. One way to
>> view this is that it is not our problem, and that the owners have
>> reduced their ability to pursue claims of copyright infringement.
>> However, they may not have that option if their code constitutes "a
>> work based on" another program also made available under the GPLv2
>> license.
>>
>> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Excuse me for butting in, but you may be trying to accomplish more than ASF
has the time or inclination to do.
As long as we do not actually distribute software under other licenses, then
creating dependencies on that software is not copyright infringement. It
isn't even contributory to copyright infringement. There is certainly no
copyright licensing obligation relating to that other software. Dependencies
on GPL code may be disfavored for other reasons, but worrying about
copyright infringement isn't one of them.
ASF's sole obligation is to let people know what they're getting from ASF,
including disclosing external dependencies. That is a commercial nicety
(backed up by our disclaimer of warranty!), but it is not a copyright law or
licensing obligation.
This also presents a huge opportunity for individual ASF members to set up
separate (and presumably profitable) businesses combining and distributing
Apache and other software in functional combinations as services or products
for customers. You can scrub the licenses and determine for yourselves if
you can risk distributing such combination software. In most cases, you'll
find that you can.
/Larry
> -----Original Message-----
> From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
> Sent: Monday, July 28, 2008 2:03 PM
> To: legal-discuss@apache.org
> Subject: Re: Licenses are not always what they seem [was: RE: GPL
> licensing question ...]
>
> On Mon, Jul 28, 2008 at 4:32 PM, Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
> > On Mon, Jul 28, 2008 at 1:12 PM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> >> Agreed. Just so that we are clear, and using Xen as a example. Xen
> >> has a hypercall interface[1]. If an ASF project wishes to make use of
> >> this interface, the statement currently appearing on the Xen wiki[2]
> >> is not sufficient.
> >
> > I don't know if you overlooked my earlier posts referring to it, but
> > how are the exceptions listed Xen's COPYING insufficient
> > (http://lxr.xensource.com/lxr/source/COPYING)? -- justin
>
> You previously said you were comfortable relying on that. I don't yet
> have sufficient information to be as comfortable as you appear to be.
> Permit me to explain.
>
> Placing two discrete things in the same hg repository or in the same
> tarball does not require them both to be licensed equivalently, so
> there is no concern there.
>
> If, however, the owners of the program are claiming that parts of
> their code are covered under GPLv2, and other parts which would be
> covered by clause 2b of GPLv2 are not subject to the terms of GPLv2,
> then we have a contradiction that needs to be resolved. One way to
> view this is that it is not our problem, and that the owners have
> reduced their ability to pursue claims of copyright infringement.
> However, they may not have that option if their code constitutes "a
> work based on" another program also made available under the GPLv2
> license.
>
> - Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jul 28, 2008 at 4:32 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Mon, Jul 28, 2008 at 1:12 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> Agreed. Just so that we are clear, and using Xen as a example. Xen
>> has a hypercall interface[1]. If an ASF project wishes to make use of
>> this interface, the statement currently appearing on the Xen wiki[2]
>> is not sufficient.
>
> I don't know if you overlooked my earlier posts referring to it, but
> how are the exceptions listed Xen's COPYING insufficient
> (http://lxr.xensource.com/lxr/source/COPYING)? -- justin
You previously said you were comfortable relying on that. I don't yet
have sufficient information to be as comfortable as you appear to be.
Permit me to explain.
Placing two discrete things in the same hg repository or in the same
tarball does not require them both to be licensed equivalently, so
there is no concern there.
If, however, the owners of the program are claiming that parts of
their code are covered under GPLv2, and other parts which would be
covered by clause 2b of GPLv2 are not subject to the terms of GPLv2,
then we have a contradiction that needs to be resolved. One way to
view this is that it is not our problem, and that the owners have
reduced their ability to pursue claims of copyright infringement.
However, they may not have that option if their code constitutes "a
work based on" another program also made available under the GPLv2
license.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Jul 28, 2008 at 1:12 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Agreed. Just so that we are clear, and using Xen as a example. Xen
> has a hypercall interface[1]. If an ASF project wishes to make use of
> this interface, the statement currently appearing on the Xen wiki[2]
> is not sufficient.
I don't know if you overlooked my earlier posts referring to it, but
how are the exceptions listed Xen's COPYING insufficient
(http://lxr.xensource.com/lxr/source/COPYING)? -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jul 28, 2008 at 2:46 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Jul 28, 2008, at 3:04 AM, Sam Ruby wrote:
>>
>> It makes exactly the same amount of sense as us treating a checkbox in
>> JIRA as sufficient permission for simple three line bug patch, but we
>> demand multiple ICLAs and generally a CCLA or two when the incubator
>> accepts an entire codebase which was previously released under a
>> different license.
>
> We don't need the checkbox at all. And what we "demand" of new submissions
> to incubator is that the original authors want to maintain it at the ASF
> (or let others maintain it at the ASF) and give us the ability to relicense
> in accordance with our nonprofit purpose. How that ended up being a demand
> for signed iCLAs is anyone's guess. IMO, the incubator has an obscene
> inclination towards paperwork for the same reason that any large institution
> needs forms in triplicate -- because they prefer to simplify their own
> process and documented requirements rather than simplify the task of
> the volunteers bringing in new code.
<chuckle>
While the incubator is responsible for the execution, I see
requirements for a clear audit trail as being derived from this
committee's predecessors. If this group were to say that we no longer
saw this as necessary, I am sure that the incubator would be quick to
comply.
That being said, the notion of an ASF product with a dependency on
GPL'ed code is something I, for one, would like to move very slowly
and carefully on; and in the process make sure that there is as little
room as possible for misunderstandings. Which means that I am for a
clear audit trail, complete with i's dotted and t's crossed. Not to
simply my own workload. And, as you correctly point out, in a desire
to simply the task of volunteers bringing in new code. But rather to
satisfy my own desire to make sure that we have every right to make
available our product under only the terms of the Apache Software
License, Version 2.0.
>> If the authors of a given bit of code wishes to dual license their
>> code, they should do so. But for someone to make the claim that a GPL
>> license gives the ASF permission to redistribute code that depends on
>> it under the Apache License is a bit of a stretch.
>
> I don't think anyone claimed that. Note, however, that a dual license
> happens whenever the owner says "yes, you can do that". It does not
> need to be in the form of a new LICENSE text document inserted in the
> package bundle and then formally released.
>
> Keep in mind that copyright defines the exclusive rights of the owner.
> It is always the owner's statements that matter first, even if they
> don't correlate with other licenses the owner has granted.
Agreed. Just so that we are clear, and using Xen as a example. Xen
has a hypercall interface[1]. If an ASF project wishes to make use of
this interface, the statement currently appearing on the Xen wiki[2]
is not sufficient.
However, if we were to get explicit permissions the owner, that would
be sufficient. I would be more comfortable if that were in writing,
but we will worry about that when we get there.
If there is a single owner (by virtue of copyright assignment),
obtaining permission may be simple. If copyright assignment was not
done, then permissions from each owner may be necessary. And given
the nature of the GPL license, that may involve obtaining explicit
permissions from other works from which Xen was derived.
> ....Roy
- Sam Ruby
[1] http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/interface/interface.html#SECTION00610000000000000000
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 28, 2008, at 3:04 AM, Sam Ruby wrote:
> It makes exactly the same amount of sense as us treating a checkbox in
> JIRA as sufficient permission for simple three line bug patch, but we
> demand multiple ICLAs and generally a CCLA or two when the incubator
> accepts an entire codebase which was previously released under a
> different license.
We don't need the checkbox at all. And what we "demand" of new
submissions
to incubator is that the original authors want to maintain it at the ASF
(or let others maintain it at the ASF) and give us the ability to
relicense
in accordance with our nonprofit purpose. How that ended up being a
demand
for signed iCLAs is anyone's guess. IMO, the incubator has an obscene
inclination towards paperwork for the same reason that any large
institution
needs forms in triplicate -- because they prefer to simplify their own
process and documented requirements rather than simplify the task of
the volunteers bringing in new code.
> If the authors of a given bit of code wishes to dual license their
> code, they should do so. But for someone to make the claim that a GPL
> license gives the ASF permission to redistribute code that depends on
> it under the Apache License is a bit of a stretch.
I don't think anyone claimed that. Note, however, that a dual license
happens whenever the owner says "yes, you can do that". It does not
need to be in the form of a new LICENSE text document inserted in the
package bundle and then formally released.
Keep in mind that copyright defines the exclusive rights of the owner.
It is always the owner's statements that matter first, even if they
don't correlate with other licenses the owner has granted.
....Roy
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Mon, 7/28/08, Sam Ruby <ru...@intertwingly.net> wrote:
> I'm not exactly clear how Xen got introduced into this conversation,
> but it makes a great example. The FSF has made both GPL
> and LGPL licenses available, the key difference being how they treat
> other applications which make use of the interfaces provided.
> For us to treat statements on a wiki (on a wiki!) that ascribe the
> behavior of the LGPL to the GPL as somehow being more authoritative
> than what the license itself may say boggles the mind.
Fortunately nobody's suggesting that. What I am suggesting when it
comes to Xen is not to read the FAQ, but to get specific about which
interfaces are actually required. Because as I've said many times now,
the license under discussion will depend on which interface people
want to use. It's not all GPL by any stretch, and being the copyright
holders they *can* provide LGPL'd (or BSD'd) interfaces to GPL'd code.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jul 28, 2008 at 1:42 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Jul 27, 2008, at 6:53 PM, Sam Ruby wrote:
>>
>> On Sun, Jul 27, 2008 at 7:57 PM, Joe Schaefer <jo...@yahoo.com>
>> wrote:
>>>
>>> --- On Sun, 7/27/08, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>
>>>>> That would be
>>>>> equivalent to Microsoft
>>>>> donating a bunch of OOXML code and some agreement of
>>>>> their choosing without
>>>>> doing a software grant or CLA and saying "Sure,
>>>>> go ahead.".
>>>
>>> If "go ahead" means license it under the AL 2.0, and
>>> the person saying "go ahead" has sufficient authority,
>>> that is perfectly fine with me, no matter what the
>>> "agreement of their choosing" is. This is exactly the
>>> situation we had at one point with Harmony, where the
>>> CEO of Sun was making very public statements about what
>>> Apache was entitled to do with its codebase, where Sun
>>> was simultaneously making a different set of demands
>>> in private.
>>
>> Disagree with the above. If a person with "sufficient authority"
>> makes inherently contradictory statements (namely: the license of the
>> code is X, and what you are allowed to do is Y, where X != Y), then it
>> is not perfectly fine.
>
> That doesn't make any sense. What Joe said is correct -- permission
> granted cannot be retroactively denied, no matter how many contrary
> variations on other permissions may be found in the wild. There is
> no limit to the number and variety of nonexclusive licenses that can
> be given by the copyright owner, and nobody other than the copyright
> owner has any standing in the issue. In other words, if the owner
> says that everyone may copy the code under GPL license and the ASF
> may redistribute the same code under the Apache License, that is not
> a legal contradiction.
It makes exactly the same amount of sense as us treating a checkbox in
JIRA as sufficient permission for simple three line bug patch, but we
demand multiple ICLAs and generally a CCLA or two when the incubator
accepts an entire codebase which was previously released under a
different license.
If the authors of a given bit of code wishes to dual license their
code, they should do so. But for someone to make the claim that a GPL
license gives the ASF permission to redistribute code that depends on
it under the Apache License is a bit of a stretch.
>>>> If the amount and nature of the code in question is of the
>>>> nature where we would feel comfortable accepting it as a
>>>> contribution by virtue of a JIRA checkbox being checked, then I
>>>> wouldn't object. Anything more substantial, and like Ralph, I would
>>>> definitely object.
>>>
>>> What would you be objecting to, exactly? That the normal
>>> process for contributions wasn't followed? And what does
>>> that have to do with getting explicit permission for using
>>> GPL'd interfaces in an Apache project?
>>
>> If the person, no matter what their authority, is making assertions
>> that are contrary to their license, then I object to taking an email
>> or a web page as more authoritative than the license.
>
> A license is just a bunch of words. The only thing that gives it any
> sort of authority over a given bag of bits is the assumption that the
> owner made that association. If the owner makes other associations,
> they are just as binding (and far easier to derive authority) than
> the bunch of words that happens to be found near the copyrighted work.
We've all encountered people with profound misunderstandings of what
the license that they selected actually means -- note: I'm not talking
about a momentary gaffe here or there, but actual beliefs which are
widely divergent from what the words in the license actually mean.
Going back to Joe's words 'see what the author says. If he says "yes"
in some manner that's satisfactory to this committee', I would assert
that a text file in SVN which captures one author's perhaps muddled
thinking on what a given license means is not sufficient for this
committee to agree to allow an ASF product on an GPL licensed work.
I'm not exactly clear how Xen got introduced into this conversation,
but it makes a great example. The FSF has made both GPL and LGPL
licenses available, the key difference being how they treat other
applications which make use of the interfaces provided. For us to
treat statements on a wiki (on a wiki!) that ascribe the behavior of
the LGPL to the GPL as somehow being more authoritative than what the
license itself may say boggles the mind.
> ....Roy
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 27, 2008, at 6:53 PM, Sam Ruby wrote:
> On Sun, Jul 27, 2008 at 7:57 PM, Joe Schaefer
> <jo...@yahoo.com> wrote:
>> --- On Sun, 7/27/08, Sam Ruby <ru...@intertwingly.net> wrote:
>>>> That would be
>>>> equivalent to Microsoft
>>>> donating a bunch of OOXML code and some agreement of
>>>> their choosing without
>>>> doing a software grant or CLA and saying "Sure,
>>>> go ahead.".
>>
>> If "go ahead" means license it under the AL 2.0, and
>> the person saying "go ahead" has sufficient authority,
>> that is perfectly fine with me, no matter what the
>> "agreement of their choosing" is. This is exactly the
>> situation we had at one point with Harmony, where the
>> CEO of Sun was making very public statements about what
>> Apache was entitled to do with its codebase, where Sun
>> was simultaneously making a different set of demands
>> in private.
>
> Disagree with the above. If a person with "sufficient authority"
> makes inherently contradictory statements (namely: the license of the
> code is X, and what you are allowed to do is Y, where X != Y), then it
> is not perfectly fine.
That doesn't make any sense. What Joe said is correct -- permission
granted cannot be retroactively denied, no matter how many contrary
variations on other permissions may be found in the wild. There is
no limit to the number and variety of nonexclusive licenses that can
be given by the copyright owner, and nobody other than the copyright
owner has any standing in the issue. In other words, if the owner
says that everyone may copy the code under GPL license and the ASF
may redistribute the same code under the Apache License, that is not
a legal contradiction.
>>> If the amount and nature of the code in question is of the
>>> nature where we would feel comfortable accepting it as a
>>> contribution by virtue of a JIRA checkbox being checked, then I
>>> wouldn't object. Anything more substantial, and like Ralph, I would
>>> definitely object.
>>
>> What would you be objecting to, exactly? That the normal
>> process for contributions wasn't followed? And what does
>> that have to do with getting explicit permission for using
>> GPL'd interfaces in an Apache project?
>
> If the person, no matter what their authority, is making assertions
> that are contrary to their license, then I object to taking an email
> or a web page as more authoritative than the license.
A license is just a bunch of words. The only thing that gives it any
sort of authority over a given bag of bits is the assumption that the
owner made that association. If the owner makes other associations,
they are just as binding (and far easier to derive authority) than
the bunch of words that happens to be found near the copyrighted work.
....Roy
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Jul 27, 2008 at 7:57 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> --- On Sun, 7/27/08, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Sun, Jul 27, 2008 at 6:23 PM, Ralph Goers
>> <Ra...@dslextreme.com> wrote:
>> >
>> > Joe Schaefer wrote:
>> >>
>> >> That's an email from the copyright owner
>> >> (O'Reilly) to one of
>> >> our projects granting them explicit permission to
>> >> use code from a book. That's hardly a signed document,
>> >> but it's entirely good enough IMO.
>> >
>> > Did O'Reilly change the terms of the license? If
>> > so, I didn't see it in the
>> > email. Just giving permission to incorporate the code
>> > into an Apache project
>> > doesn't necessarily mean it can be.
>
> Nonsense.
In the O'Reilly case cited, I agree that the permission obtained was sufficient.
>> > That would be
>> > equivalent to Microsoft
>> > donating a bunch of OOXML code and some agreement of
>> > their choosing without
>> > doing a software grant or CLA and saying "Sure,
>> > go ahead.".
>
> If "go ahead" means license it under the AL 2.0, and
> the person saying "go ahead" has sufficient authority,
> that is perfectly fine with me, no matter what the
> "agreement of their choosing" is. This is exactly the
> situation we had at one point with Harmony, where the
> CEO of Sun was making very public statements about what
> Apache was entitled to do with its codebase, where Sun
> was simultaneously making a different set of demands
> in private.
Disagree with the above. If a person with "sufficient authority"
makes inherently contradictory statements (namely: the license of the
code is X, and what you are allowed to do is Y, where X != Y), then it
is not perfectly fine.
>> If the amount and nature of the code in question is of the
>> nature where we would feel comfortable accepting it as a
>> contribution by virtue of a JIRA checkbox being checked, then I
>> wouldn't object. Anything more substantial, and like Ralph, I would
>> definitely object.
>
> What would you be objecting to, exactly? That the normal
> process for contributions wasn't followed? And what does
> that have to do with getting explicit permission for using
> GPL'd interfaces in an Apache project?
If the person, no matter what their authority, is making assertions
that are contrary to their license, then I object to taking an email
or a web page as more authoritative than the license.
>> Which is to say that I find an this example (where one
>> learns a technique from a book intended to teach such techniques,
>> and then one applies these techniques with explicit permission from the
>> author and publisher, while honoring their request for attribution) to
>> be quite different from the original GPL question.
>
> You implicitly asked for an example of what "explicit permission"
> meant. So I fetched you a rock, and you are now questioning it's shape.
I disagree. You have a bolder in your trailer. And handed me a shiny
pebble. I said that was a nice pebble, and accepted the pebble, but
have not opened the gate for the trailer.
> Again I will repeat: Xen is a complex piece of software, and uses
> mixed licensing (GPL, LGPL, and BSD-ish). When the Xen authors
> say using the hypervisor APIs don't induce GPL, they're merely
> stating the obvious: there is no way an operating system can
> possibly be considered a derivative work of a hypervisor. It
> is an optional interface which people code to for compatibility
> reasons. IMO that is exactly the logic courts will use in
> dealing with whether something is a derivative work. It won't
> be based on linking, dependencies, IPC, or any other baloney
> this committee invents in order to deal with the GPL.
A statement that "there is no way an operating system can possibly be
considered a derivative work of a hypervisor" is something that can be
determined independent of any appeal to authority. Assuming it is
true (and it sounds reasonable), then "permissions" from "authority"
are simply irrelevant.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Sun, 7/27/08, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sun, Jul 27, 2008 at 6:23 PM, Ralph Goers
> <Ra...@dslextreme.com> wrote:
> >
> > Joe Schaefer wrote:
> >>
> >> That's an email from the copyright owner
> >> (O'Reilly) to one of
> >> our projects granting them explicit permission to
> >> use code from a book. That's hardly a signed document,
> >> but it's entirely good enough IMO.
> >
> > Did O'Reilly change the terms of the license? If
> > so, I didn't see it in the
> > email. Just giving permission to incorporate the code
> > into an Apache project
> > doesn't necessarily mean it can be.
Nonsense.
> > That would be
> > equivalent to Microsoft
> > donating a bunch of OOXML code and some agreement of
> > their choosing without
> > doing a software grant or CLA and saying "Sure,
> > go ahead.".
If "go ahead" means license it under the AL 2.0, and
the person saying "go ahead" has sufficient authority,
that is perfectly fine with me, no matter what the
"agreement of their choosing" is. This is exactly the
situation we had at one point with Harmony, where the
CEO of Sun was making very public statements about what
Apache was entitled to do with its codebase, where Sun
was simultaneously making a different set of demands
in private.
> If the amount and nature of the code in question is of the
> nature where we would feel comfortable accepting it as a
> contribution by virtue of a JIRA checkbox being checked, then I
> wouldn't object. Anything more substantial, and like Ralph, I would
> definitely object.
What would you be objecting to, exactly? That the normal
process for contributions wasn't followed? And what does
that have to do with getting explicit permission for using
GPL'd interfaces in an Apache project?
> Which is to say that I find an this example (where one
> learns a technique from a book intended to teach such techniques,
> and then one applies these techniques with explicit permission from the
> author and publisher, while honoring their request for attribution) to
> be quite different from the original GPL question.
You implicitly asked for an example of what "explicit permission"
meant. So I fetched you a rock, and you are now questioning it's shape.
Again I will repeat: Xen is a complex piece of software, and uses
mixed licensing (GPL, LGPL, and BSD-ish). When the Xen authors
say using the hypervisor APIs don't induce GPL, they're merely
stating the obvious: there is no way an operating system can
possibly be considered a derivative work of a hypervisor. It
is an optional interface which people code to for compatibility
reasons. IMO that is exactly the logic courts will use in
dealing with whether something is a derivative work. It won't
be based on linking, dependencies, IPC, or any other baloney
this committee invents in order to deal with the GPL.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Jul 27, 2008 at 6:23 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
>
> Joe Schaefer wrote:
>>
>> What I mean is something along these lines:
>>
>> http://svn.apache.org/repos/asf/forrest/trunk/lib/core/oreilly.permission.txt
>>
>> That's an email from the copyright owner (O'Reilly) to one of
>> our projects granting them explicit permission to use code
>> from a book. That's hardly a signed document, but it's entirely good
>> enough IMO.
>
> Did O'Reilly change the terms of the license? If so, I didn't see it in the
> email. Just giving permission to incorporate the code into an Apache project
> doesn't necessarily mean it can be. That would be equivalent to Microsoft
> donating a bunch of OOXML code and some agreement of their choosing without
> doing a software grant or CLA and saying "Sure, go ahead.".
If the amount and nature of the code in question is of the nature
where we would feel comfortable accepting it as a contribution by
virtue of a JIRA checkbox being checked, then I wouldn't object.
Anything more substantial, and like Ralph, I would definitely object.
Which is to say that I find an this example (where one learns a
technique from a book intended to teach such techniques, and then one
applies these techniques with explicit permission from the author and
publisher, while honoring their request for attribution) to be quite
different from the original GPL question.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing
question ...]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>
> What I mean is something along these lines:
>
> http://svn.apache.org/repos/asf/forrest/trunk/lib/core/oreilly.permission.txt
>
> That's an email from the copyright owner (O'Reilly) to one of
> our projects granting them explicit permission to use code
> from a book. That's hardly a signed document, but it's
> entirely good enough IMO.
>
>
Did O'Reilly change the terms of the license? If so, I didn't see it in
the email. Just giving permission to incorporate the code into an Apache
project doesn't necessarily mean it can be. That would be equivalent to
Microsoft donating a bunch of OOXML code and some agreement of their
choosing without doing a software grant or CLA and saying "Sure, go ahead.".
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Sun, 7/27/08, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jul 26, 2008 at 11:38 PM, Joe Schaefer
> <jo...@yahoo.com> wrote:
> > --- On Sat, 7/26/08, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> >> If we wish to do something with a body of code,
> >> and the provided
> >> license does not give us the permissions we need,
> >> we should seek another license.
> >
> > Which is exactly what explicit permission is, a
> > license which
> > trumps all other considerations.
>
> If by explicit, you mean a signed agreement between the ASF
> and the third party that covers the terms, then I agree.
>
> If you mean verbal statement, a statement in email, a note
> on a web page, or any or all of the above when made by one of the
> contributors to the body of code, then I think that falls
> a bit short of what we need.
What I mean is something along these lines:
http://svn.apache.org/repos/asf/forrest/trunk/lib/core/oreilly.permission.txt
That's an email from the copyright owner (O'Reilly) to one of
our projects granting them explicit permission to use code
from a book. That's hardly a signed document, but it's
entirely good enough IMO.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jul 26, 2008 at 11:38 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> --- On Sat, 7/26/08, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> If we wish to do something with a body of code, and the
>> provided
>> license does not give us the permissions we need, we should
>> seek
>> another license.
>
> Which is exactly what explicit permission is, a license which
> trumps all other considerations.
If by explicit, you mean a signed agreement between the ASF and the
third party that covers the terms, then I agree.
If you mean verbal statement, a statement in email, a note on a web
page, or any or all of the above when made by one of the contributors
to the body of code, then I think that falls a bit short of what we
need.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Sat, 7/26/08, Sam Ruby <ru...@intertwingly.net> wrote:
> If we wish to do something with a body of code, and the
> provided
> license does not give us the permissions we need, we should
> seek
> another license.
Which is exactly what explicit permission is, a license which
trumps all other considerations.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jul 26, 2008 at 5:26 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Sat, Jul 26, 2008 at 1:53 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
>> I think this is dangerous. I suspect that should a court rule on the GPL
>> that other courts will look to prior rulings as their guide, not what the
>> authors say the license says.
>
> I don't agree - if the author(s) explicitly say, "You can do X" and we
> go off and do X, then they are not on very solid ground to later
> challenge that. (If they change their minds later, we might choose to
> honor that request as we're generally nice guys.)
Independent of the GPL, court rulings, and the like, if the author
creates a license that states X, and then either verbally or even in
writing suggests that what they really mean is !X, then we have a
problem.
This is the inverse of the problem that we have seen where our license
states that our licensees have specific rights, but we have been asked
at various times to post notices to accompany our distributions that
say, in essence "not so fast, what we really mean is something else".
If we wish to do something with a body of code, and the provided
license does not give us the permissions we need, we should seek
another license.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing
question ...]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>
> Rather than deal with the question in the abstract, let me
> focus on the Xen situation. Citrix bought Xen for half a
> billion dollars, and I suspect what they got for that was
> significantly more than a trademark. Citrix also releases
> XenServer, which is a closed source product based on Xen.
>
> So either Xen uses copyright assignment and has elected to
> dual-license the product (unlikely), or the devs have built
> enough liberal license terms into the source to admit an
> aftermarket for proprietary products developed using
> Xen interfaces.
>
> If I were looking for an authoritative answer to whether
> or not Apache can do certain things with Xen, I would first
> look for a response from Citrix, and additionally check
> the comments in the source for potential third-party
> interests in whatever APIs we would like to make use of.
>
>
Again, I have no idea what Xen's license(s) is/are. If Xen has its own
unique license then looking at it and getting any clarification needed
from them makes sense. If they are using a license commonly used by
others (such as the GPL) then looking at the license and interpreting it
in its most pessimistic terms makes sense (to me). As I said earlier, if
Xen is licensed under the GPL I see no value asking the authors of Xen
what they believe the GPL says. That topic has already been covered by
many lawyers, including I believe, those who are involved with Apache.
Why not just ask them?
Ralph
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Sat, 7/26/08, Noel J. Bergman <no...@devtech.com> wrote:
> Justin Erenkrantz wrote:
> > Ralph Goers wrote:
> > > I suspect that should a court rule on the GPL
> > > that other
> > > courts will look to prior rulings as their guide,
> > > not what the authors say the license says.
>
> > I don't agree - if the author(s) explicitly say,
> > "You can do X" and we
> > go off and do X, then they are not on very solid
> > ground to later
> > challenge that. (If they change their minds later, we
> > might choose to
> > honor that request as we're generally nice guys.)
>
> Who is the author of a GPL work when they (may) freely
> commingle work from
> many GPL licensing authors, and don't necessarily track
> provenance? If we
> go by the claimed copyright on the files, is that
> sufficient to know whose
> opinion(s) matters?
Rather than deal with the question in the abstract, let me
focus on the Xen situation. Citrix bought Xen for half a
billion dollars, and I suspect what they got for that was
significantly more than a trademark. Citrix also releases
XenServer, which is a closed source product based on Xen.
So either Xen uses copyright assignment and has elected to
dual-license the product (unlikely), or the devs have built
enough liberal license terms into the source to admit an
aftermarket for proprietary products developed using
Xen interfaces.
If I were looking for an authoritative answer to whether
or not Apache can do certain things with Xen, I would first
look for a response from Citrix, and additionally check
the comments in the source for potential third-party
interests in whatever APIs we would like to make use of.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> Ralph Goers wrote:
> > I suspect that should a court rule on the GPL that other
> > courts will look to prior rulings as their guide, not
> > what the authors say the license says.
> I don't agree - if the author(s) explicitly say, "You can do X" and we
> go off and do X, then they are not on very solid ground to later
> challenge that. (If they change their minds later, we might choose to
> honor that request as we're generally nice guys.)
Who is the author of a GPL work when they (may) freely commingle work from
many GPL licensing authors, and don't necessarily track provenance? If we
go by the claimed copyright on the files, is that sufficient to know whose
opinion(s) matters?
--- Noel
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sat, Jul 26, 2008 at 1:53 PM, Ralph Goers <Ra...@dslextreme.com> wrote:
> I think this is dangerous. I suspect that should a court rule on the GPL
> that other courts will look to prior rulings as their guide, not what the
> authors say the license says.
I don't agree - if the author(s) explicitly say, "You can do X" and we
go off and do X, then they are not on very solid ground to later
challenge that. (If they change their minds later, we might choose to
honor that request as we're generally nice guys.)
> When folks put up stuff on their web site that
> is certainly helpful, but not completely. What if you have one GPL'd work
> used in another GPL'd work and their opinions on the license disagree?
We'd almost certainly choose the least permissive opinion.
> How
> can we have one interpretation of the license for one project and a
> different interpretation of the same license for another?
For example, Xen states that the GPL does "*not* cover guest operating
systems that use Xen services via normal hypercalls...":
http://lxr.xensource.com/lxr/source/xen/COPYING
If we have explicit permission from the author(s) for a particular use
case, then I'm comfortable relying upon that. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing
question ...]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
> --- On Sat, 7/26/08, Philippe Ombredanne <po...@gmail.com> wrote:
>
>
>> Joe Schaefer wrote on Thursday, July 24, 2008 6:50 PM
>>
>>> Eh, if we're talking about Xen, wouldn't it
>>> make sense to
>>> actually consult the author of that particular piece
>>> of software instead of pretending there is some
>>> unilateral
>>> interpretation of the GPL that is buttressed by actual
>>> case law?
>>>
>> I am always trying to consul the authors when possible.
>> I have seen folks with understanding of the GPL or open
>> source licenses in general very differently.
>>
>
> Right. In dealing with actual requests involving the GPL, I would
> like to see us adopt a policy where we ask the author "this
> is what we'd like to do, and these are the terms we'd like
> to license it under, is that ok" and see what the author says.
> If he says "yes" in some manner that's satisfactory to this
> committee, then I think the committee should approve the request.
>
I think this is dangerous. I suspect that should a court rule on the GPL
that other courts will look to prior rulings as their guide, not what
the authors say the license says. When folks put up stuff on their web
site that is certainly helpful, but not completely. What if you have one
GPL'd work used in another GPL'd work and their opinions on the license
disagree? How can we have one interpretation of the license for one
project and a different interpretation of the same license for another?
> This way we can avoid all the abstract nonsense about dependencies,
> license boundaries, etc. and just honor the intentions of the
> software's author. In situations where we can't get satisfactory
> authorization, or can't reliably figure out who wrote it,
> just say no to GPL.
>
> I think Xen, should it ever come before this committee for
> deliberation, is a good use case for this kind of policy,
> because the software is complex and the licensing scheme
> is mixed (and may be subject to change).
>
Not having looked at the licensing scheme I really can't comment on that.
Ralph
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Sat, 7/26/08, Philippe Ombredanne <po...@gmail.com> wrote:
> Joe Schaefer wrote on Thursday, July 24, 2008 6:50 PM
> > Eh, if we're talking about Xen, wouldn't it
> > make sense to
> > actually consult the author of that particular piece
> > of software instead of pretending there is some
> > unilateral
> > interpretation of the GPL that is buttressed by actual
> > case law?
> I am always trying to consul the authors when possible.
> I have seen folks with understanding of the GPL or open
> source licenses in general very differently.
Right. In dealing with actual requests involving the GPL, I would
like to see us adopt a policy where we ask the author "this
is what we'd like to do, and these are the terms we'd like
to license it under, is that ok" and see what the author says.
If he says "yes" in some manner that's satisfactory to this
committee, then I think the committee should approve the request.
This way we can avoid all the abstract nonsense about dependencies,
license boundaries, etc. and just honor the intentions of the
software's author. In situations where we can't get satisfactory
authorization, or can't reliably figure out who wrote it,
just say no to GPL.
I think Xen, should it ever come before this committee for
deliberation, is a good use case for this kind of policy,
because the software is complex and the licensing scheme
is mixed (and may be subject to change).
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Licenses are not always what they seem [was: RE: GPL licensing question ...]
Posted by Philippe Ombredanne <po...@gmail.com>.
Joe Schaefer wrote on Thursday, July 24, 2008 6:50 PM
> Eh, if we're talking about Xen, wouldn't it make sense to
> actually consult the author of that particular piece
> of software instead of pretending there is some unilateral
> interpretation of the GPL that is buttressed by actual
> case law?
I am always trying to consul the authors when possible.
I have seen folks with understanding of the GPL or open source licenses in
general very differently.
For instance I have seen folks saying:
My software is under this open license XYZ but you cannot use it in a
commecial endeavour.
Even if it shows a poor understanding of the license itself, if the
expressed intention of an author is to add fruther restrictions in the form
of some additional mention on their web site, or any other form (a readme
note, etc) I tend to consider it as being part of the resultant license.
I.e. the explicit standard license they use plus their interpretation as
explained in writing on their web site is the actual license (whatever that
license is) regardless of the apparent conflicts.
In a similar fashion, I have seen folks with poor license understanding that
released their wares explicitely under the ASL, but had their own code
tightly bound with copyleft code (including copyleft code modfied for the
purpose of a tighter integration)
--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf -
http://eclipse.org/vep - http://labs.jboss.org/drools/ -
http://developer.mozilla.org/en/docs/XULRunner
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Joe Schaefer <jo...@yahoo.com>.
--- On Thu, 7/24/08, Henri Yandell <ba...@apache.org> wrote:
> On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman
> > On a related note, consider the following...
> >
> > The ASF hosts projects, e.g., Lokahi and Tashi, that
> > want to manage a myriad
> > of outside technologies. Presume that the ASF designs
> > an AL licensed
> > management plugin interface that would be implemented
> > per managed
> > technology. Some outside technologies to be managed
> > might be GPL licensed.
> > What would be the issue(s) with hosting
> > implementations of that plugin
> > interface where one or more implementations for
> > external items to be managed
> > might touch GPL in order to implement that plugin for
> > the GPL licensed
> > external entity?
>
> The questions we would ask ourselves would be:
>
> 1) Is the plugin interface deemed sufficient to make the
> GPL product
> and the main Apache product (Lokahi/Tashi) independent of
> each other?
> 2) Are we happy hosting the bridge code under GPL?
>
> The first is specific so we would hit that when the time
> comes. For
> the second, I claim the answer would be "Yes"
Eh, if we're talking about Xen, wouldn't it make sense to
actually consult the author of that particular piece
of software instead of pretending there is some unilateral
interpretation of the GPL that is buttressed by actual
case law?
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GPL licensing question ...
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Jul 24, 2008 at 4:42 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Sam Ruby wrote:
>> Philippe Ombredanne wrote:
>> > I can see potentially a path to using Xapian with CouchDB, but it would
>> > involve:
>> > - technology neutrality of the interface
>> > - some work done outside of the ASF
>> This approach is not dissimilar to utilizing mysql through JDBC, which
>> is allowed.
>
> On a related note, consider the following...
>
> The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a myriad
> of outside technologies. Presume that the ASF designs an AL licensed
> management plugin interface that would be implemented per managed
> technology. Some outside technologies to be managed might be GPL licensed.
> What would be the issue(s) with hosting implementations of that plugin
> interface where one or more implementations for external items to be managed
> might touch GPL in order to implement that plugin for the GPL licensed
> external entity?
The questions we would ask ourselves would be:
1) Is the plugin interface deemed sufficient to make the GPL product
and the main Apache product (Lokahi/Tashi) independent of each other?
2) Are we happy hosting the bridge code under GPL?
The first is specific so we would hit that when the time comes. For
the second, I claim the answer would be "Yes" depending on:
b) The existence of the bridge makes the main Apache product more
valuable (PMC's decision).
a) The code for that bridge is relatively small compared to the rest
of the product.
Hen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
GPL licensing question ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam Ruby wrote:
> Philippe Ombredanne wrote:
> > I can see potentially a path to using Xapian with CouchDB, but it would
> > involve:
> > - technology neutrality of the interface
> > - some work done outside of the ASF
> This approach is not dissimilar to utilizing mysql through JDBC, which
> is allowed.
On a related note, consider the following...
The ASF hosts projects, e.g., Lokahi and Tashi, that want to manage a myriad
of outside technologies. Presume that the ASF designs an AL licensed
management plugin interface that would be implemented per managed
technology. Some outside technologies to be managed might be GPL licensed.
What would be the issue(s) with hosting implementations of that plugin
interface where one or more implementations for external items to be managed
might touch GPL in order to implement that plugin for the GPL licensed
external entity?
--- Noel
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jul 19, 2008 at 2:57 PM, Philippe Ombredanne
<po...@gmail.com> wrote:
> On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
>> After reading your post Sam, it seems clear that we can't use
>> Xapian even if it was allowed by the GPL because this would go against the
>
>> principal of not requiring any GPL code dependencies. What a shame.
>
> My 2 cents:
> a possible approach would be to expose some kind of interface /plugin (that
> has no knowledge of Xapian) such that
> - various index engines can be plugged in.
> - there is a reference implementation available for some index technology
> provided under ASL
> - other projects outside of the ASF can implement and provide a CouchDB
> index plugin for Xapian if they feel like it, under whatever license they
> feel they can or shall use.
>
> So I can see potentially a path to using Xapian with CouchDB, but it would
> involve:
> - technology neutrality of the interface
> - some work done outside of the ASF
>
>> I am still curious to know if the "linking" aspect applies to "import
> xapian".
> IMHO the linking aspect applies to "import xapian" and in general to any
> kind of approach where the Xapian interfaces would have to be known from
> CouchDb ASF provided code for an integration to work.
> I would see establishing some kind of hard linkage and dependency between
> the two technologies as "linking".
> But I tend to consider linking in a technology neutral way, beyond the
> interpretation of what linking means for the FSF or what it means a specific
> programming language, so take my words lightly.
>
> Does this make sense ?
This approach is not dissimilar to utilizing mysql through JDBC, which
is allowed.
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jul 18, 2008 at 10:23:13PM -0400, Sam Ruby wrote:
> Part company? Sound ominous.
Well, my presence on this list is a temporary affair. Nothing ominous at all. :)
> Apache project do not have dependencies which would preclude use of
> that product in a commercial context.
On Sat, Jul 19, 2008 at 02:09:21AM -0500, William A. Rowe, Jr. wrote:
> Commercialism has nothing to do with it... when building apps that have
> nothing to do with my apache or work-life, I've been hampered a number of
> times by copy left restrictions. These are not allowed at the ASF because
> the freedom is granted to the developer, not to the nebulous "source code".
Sure. Well, it's not as black and white as some people from ASF make out, nor
the people from the FSF. In each case the decision to enforce copyleft depends
on the personal value system you hold. I happen to prefer the copyleft value
system for large creative works but the ASF doesn't, which is fine.
Thanks clarifying the issues.
Best,
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
> William A. Rowe, Jr. wrote:
>>
>> no, the wording is that Apache projects don't contain dependencies which
>> restrict the "developer" from their choice of application.
> Well, I almost understand this sentence. "developer" and "application"
> are ambiguous but I believe I understand your meaning. Assuming you mean
> "Apache projects don't restrict "developers" from using the projects in
> any way they desire, then I'd agree. But Sam was talking about
> commercial products. I was simply trying to point out that it wasn't
> being a commercial product that was the problem, but the ability to
> choose any license they desire.
Exactly. Combining any work with a GPL work results in a GPL license.
Combining a AL work with any subset of a BSD advertising-free license
results in that license, as we are one of the more liberal licenses.
e.g. the consumer/developer has the *choice*, as opposed to the creator
imposing a choice on the consumer/developer.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Ralph Goers <Ra...@dslextreme.com>.
William A. Rowe, Jr. wrote:
>
>
>> I would have worded it "Apache projects do not have dependencies
>> which would preclude their use in a proprietary licensed commercial
>> context".
>
> wtf?
>
> no, the wording is that Apache projects don't contain dependencies which
> restrict the "developer" from their choice of application.
Well, I almost understand this sentence. "developer" and "application"
are ambiguous but I believe I understand your meaning. Assuming you mean
"Apache projects don't restrict "developers" from using the projects in
any way they desire, then I'd agree. But Sam was talking about
commercial products. I was simply trying to point out that it wasn't
being a commercial product that was the problem, but the ability to
choose any license they desire.
Ralph
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
> Sam Ruby wrote:
>>> I am still curious to know if the "linking" aspect applies to "import
>>> xapian".
>>>
>>
>> I see that Bill has provided the legal answer. Let me augment that
>> with a policy statement:
>>
>> Apache project do not have dependencies which would preclude use of
>> that product in a commercial context.
>>
>>
> That is an odd answer. There is nothing in the GPL prohibiting a
> commercial context.
agreed.
> I would have worded it "Apache projects do not have dependencies which
> would preclude their use in a proprietary licensed commercial context".
wtf?
no, the wording is that Apache projects don't contain dependencies which
restrict the "developer" from their choice of application.
E.g., it's the same nonsense as the GPL "no additional restrictions", only
applied to the AL. And this would be objectionable, why?
Commercialism has nothing to do with it... when building apps that have
nothing to do with my apache or work-life, I've been hampered a number of
times by copy left restrictions. These are not allowed at the ASF because
the freedom is granted to the developer, not to the nebulous "source code".
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sam Ruby wrote:
>> I am still curious to know if the "linking" aspect applies to "import xapian".
>>
>
> I see that Bill has provided the legal answer. Let me augment that
> with a policy statement:
>
> Apache project do not have dependencies which would preclude use of
> that product in a commercial context.
>
>
That is an odd answer. There is nothing in the GPL prohibiting a
commercial context.
I would have worded it "Apache projects do not have dependencies which
would preclude their use in a proprietary licensed commercial context".
Ralph
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jul 18, 2008 at 7:07 PM, Noah Slater <ns...@apache.org> wrote:
> On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
>> On last question before I part company... am I correct in thinking that these
>> annoying restrictions still apply to CouchDB even though the only thing we
>> would be (potentially) doing is "import xapian" in a custom Python
>> application.
Part company? Sound ominous.
> After reading your post Sam, it seems clear that we can't use Xapian even if it
> was allowed by the GPL because this would go against the principal of not
> requiring any GPL code dependencies. What a shame.
Permit me to reword that for you. It would be a shame if an Apache
project were to have a dependency which would preclude use of that
product in a commercial context.
> I am still curious to know if the "linking" aspect applies to "import xapian".
I see that Bill has provided the legal answer. Let me augment that
with a policy statement:
Apache project do not have dependencies which would preclude use of
that product in a commercial context.
> --
> Noah Slater, http://people.apache.org/~nslater/
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Ceki Gulcu <ce...@qos.ch>.
Robert Burrell Donkin wrote:
> but creating an interface just to get round the GPL is not only
> unethical but also dubious in licensing terms
Unless the GPLed code chooses to implement the said interface, implicitly
endorsing it.
> - robert
--
Ceki Gülcü
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Using a GPL library with Apache CouchDB
Posted by Philippe Ombredanne <po...@gmail.com>.
Robert Burrell Donkin wrote:
> providing it's carefully and honestly done as described, yes
> but creating an interface just to get round the GPL is not only
> unethical but also dubious in licensing terms
Agreed, though the point is not to work around the GPL at all, but rather
support different indexing technologies through a common interface, be it
Lucene, Lucy, Xapian or anything else.
> FWIW http://lucene.apache.org/lucy/ is written in C and is AL'd
Too bad it seems to be flatlining with no code activity in the last 16
months.
--
Cheers
Philippe
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf -
http://eclipse.org/vep - http://labs.jboss.org/drools/ -
http://developer.mozilla.org/en/docs/XULRunner
> -----Original Message-----
> From: Robert Burrell Donkin [mailto:rdonkin@apache.org]
> Sent: Wednesday, July 23, 2008 10:55 AM
> To: Legal Discuss
> Subject: RE: Using a GPL library with Apache CouchDB
>
>
>
> On Sat, 2008-07-19 at 10:57 -0800, Philippe Ombredanne wrote:
> > On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
> > > After reading your post Sam, it seems clear that we can't use
> > > Xapian even if it was allowed by the GPL because this
> would go against the
> >
> > > principal of not requiring any GPL code dependencies.
> What a shame.
> >
> > My 2 cents:
> > a possible approach would be to expose some kind of
> interface /plugin (that
> > has no knowledge of Xapian) such that
> > - various index engines can be plugged in.
> > - there is a reference implementation available for some
> index technology
> > provided under ASL
> > - other projects outside of the ASF can implement and
> provide a CouchDB
> > index plugin for Xapian if they feel like it, under
> whatever license they
> > feel they can or shall use.
> >
> > So I can see potentially a path to using Xapian with
> CouchDB, but it would
> > involve:
> > - technology neutrality of the interface
> > - some work done outside of the ASF
> >
> > > I am still curious to know if the "linking" aspect
> applies to "import
> > xapian".
> > IMHO the linking aspect applies to "import xapian" and in
> general to any
> > kind of approach where the Xapian interfaces would have to
> be known from
> > CouchDb ASF provided code for an integration to work.
> > I would see establishing some kind of hard linkage and
> dependency between
> > the two technologies as "linking".
> > But I tend to consider linking in a technology neutral way,
> beyond the
> > interpretation of what linking means for the FSF or what it
> means a specific
> > programming language, so take my words lightly.
> >
> > Does this make sense ?
>
> providing it's carefully and honestly done as described, yes
>
> but creating an interface just to get round the GPL is not only
> unethical but also dubious in licensing terms
>
> FWIW http://lucene.apache.org/lucy/ is written in C and is AL'd
>
> - robert
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Using a GPL library with Apache CouchDB
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Sat, 2008-07-19 at 10:57 -0800, Philippe Ombredanne wrote:
> On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
> > After reading your post Sam, it seems clear that we can't use
> > Xapian even if it was allowed by the GPL because this would go against the
>
> > principal of not requiring any GPL code dependencies. What a shame.
>
> My 2 cents:
> a possible approach would be to expose some kind of interface /plugin (that
> has no knowledge of Xapian) such that
> - various index engines can be plugged in.
> - there is a reference implementation available for some index technology
> provided under ASL
> - other projects outside of the ASF can implement and provide a CouchDB
> index plugin for Xapian if they feel like it, under whatever license they
> feel they can or shall use.
>
> So I can see potentially a path to using Xapian with CouchDB, but it would
> involve:
> - technology neutrality of the interface
> - some work done outside of the ASF
>
> > I am still curious to know if the "linking" aspect applies to "import
> xapian".
> IMHO the linking aspect applies to "import xapian" and in general to any
> kind of approach where the Xapian interfaces would have to be known from
> CouchDb ASF provided code for an integration to work.
> I would see establishing some kind of hard linkage and dependency between
> the two technologies as "linking".
> But I tend to consider linking in a technology neutral way, beyond the
> interpretation of what linking means for the FSF or what it means a specific
> programming language, so take my words lightly.
>
> Does this make sense ?
providing it's carefully and honestly done as described, yes
but creating an interface just to get round the GPL is not only
unethical but also dubious in licensing terms
FWIW http://lucene.apache.org/lucy/ is written in C and is AL'd
- robert
RE: Using a GPL library with Apache CouchDB
Posted by Philippe Ombredanne <po...@gmail.com>.
On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
> After reading your post Sam, it seems clear that we can't use
> Xapian even if it was allowed by the GPL because this would go against the
> principal of not requiring any GPL code dependencies. What a shame.
My 2 cents:
a possible approach would be to expose some kind of interface /plugin (that
has no knowledge of Xapian) such that
- various index engines can be plugged in.
- there is a reference implementation available for some index technology
provided under ASL
- other projects outside of the ASF can implement and provide a CouchDB
index plugin for Xapian if they feel like it, under whatever license they
feel they can or shall use.
So I can see potentially a path to using Xapian with CouchDB, but it would
involve:
- technology neutrality of the interface
- some work done outside of the ASF
> I am still curious to know if the "linking" aspect applies to "import
xapian".
IMHO the linking aspect applies to "import xapian" and in general to any
kind of approach where the Xapian interfaces would have to be known from
CouchDb ASF provided code for an integration to work.
I would see establishing some kind of hard linkage and dependency between
the two technologies as "linking".
But I tend to consider linking in a technology neutral way, beyond the
interpretation of what linking means for the FSF or what it means a specific
programming language, so take my words lightly.
Does this make sense ?
--
Cheers
Philippe
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf -
http://eclipse.org/vep - http://labs.jboss.org/drools/ -
http://developer.mozilla.org/en/docs/XULRunner
> -----Original Message-----
> From: Noah Slater [mailto:nslater@apache.org]
> Sent: Friday, July 18, 2008 3:07 PM
> To: legal-discuss@apache.org
> Subject: Re: Using a GPL library with Apache CouchDB
>
>
>
> --
> Noah Slater, http://people.apache.org/~nslater/
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Noah Slater <ns...@apache.org>.
On Sat, Jul 19, 2008 at 12:00:45AM +0100, Noah Slater wrote:
> On last question before I part company... am I correct in thinking that these
> annoying restrictions still apply to CouchDB even though the only thing we
> would be (potentially) doing is "import xapian" in a custom Python
> application.
After reading your post Sam, it seems clear that we can't use Xapian even if it
was allowed by the GPL because this would go against the principal of not
requiring any GPL code dependencies. What a shame.
I am still curious to know if the "linking" aspect applies to "import xapian".
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Noah Slater wrote:
>>
>> The FSF's definition of "linking" seems awfully C* based. The only
>> mention of
>> "dynamic" languages I could find was that of Java, which is different
>> IMO.
>
> That's hair splitting; use, import, include, ld foo.a all serve effectively
> the same end and purpose no matter if this is C, C++, Java, C#, Python,
> Perl, ADA or Lisp.
>
> C under most OS's offers dynamic linkage, of course. We've chosen to
> interpret it identically.
That statement didn't go quite far enough.
There is a distinction between dynamically linking to an interface which
might be implemented by an AL, a GPL, and a commercially licensed library.
In that case, if the ASF assembles software that the -end user- might choose
to deploy with such a GPL library, it's of no concern to us. We are only
concerned about implementing against an only-GPL available interface.
The way my post sounded, it would seem impossible to use an ASF class under
Kaffe's VM or something. That's not what I meant :)
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Noah Slater wrote:
>
> The FSF's definition of "linking" seems awfully C* based. The only mention of
> "dynamic" languages I could find was that of Java, which is different IMO.
That's hair splitting; use, import, include, ld foo.a all serve effectively
the same end and purpose no matter if this is C, C++, Java, C#, Python,
Perl, ADA or Lisp.
C under most OS's offers dynamic linkage, of course. We've chosen to
interpret it identically.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Noah Slater <ns...@apache.org>.
Oh man, what a mess. :(
On last question before I part company... am I correct in thinking that these
annoying restrictions still apply to CouchDB even though the only thing we would
be (potentially) doing is "import xapian" in a custom Python application.
The FSF's definition of "linking" seems awfully C* based. The only mention of
"dynamic" languages I could find was that of Java, which is different IMO.
Thanks for the help,
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jul 18, 2008 at 4:51 PM, Noah Slater <ns...@apache.org> wrote:
> On Fri, Jul 18, 2008 at 08:20:32PM +0100, sebb wrote:
>> What about using Lucene Nutch instead?
>
> Well, I don't want to get into the discussion of what search technology people
> prefer as that is an ongoing debate, and yes Lucene has been mentioned. My
> personal opinion is that Java is a pretty heavy dependency for the core.
>
> From my understanding of the compatibility between the AL2 and the GPL3 is that
> you can base an AL2 licensed work on a GPL3 library without changing licensing.
No. It is my belief that the FSF uses this term in a confusing way.
Essentially the compatibility is one way.
> Is that not the case? If not, what does "compatible" mean?
What it effectively means is that you can combine the work and release
the result under GPL v3. Legally, there is nothing that prevents
anyone from creating such a combination. However the ASF is not the
place for such a combination to be developed.
> Please note, these are not rhetoric questions, I am genuinely confused. :)
More background can be found here:
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
http://intertwingly.net/blog/2007/06/29/GPL-Compatible
http://www.apache.org/legal/ramblings.html#head-62def7ee9e2cb64eb757533133a99da472b1e88a
- Sam Ruby
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jul 18, 2008 at 08:20:32PM +0100, sebb wrote:
> What about using Lucene Nutch instead?
Well, I don't want to get into the discussion of what search technology people
prefer as that is an ongoing debate, and yes Lucene has been mentioned. My
personal opinion is that Java is a pretty heavy dependency for the core.
>From my understanding of the compatibility between the AL2 and the GPL3 is that
you can base an AL2 licensed work on a GPL3 library without changing licensing.
Is that not the case? If not, what does "compatible" mean?
Please note, these are not rhetoric questions, I am genuinely confused. :)
--
Noah Slater, http://people.apache.org/~nslater/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by sebb <se...@gmail.com>.
What about using Lucene Nutch instead?
S///
On 18/07/2008, Henri Yandell <ba...@apache.org> wrote:
> My opinion on both is that the answer is "No, not at Apache". It
> would, by the sound of things so far, make CouchDB GPL.
>
> If the feature is pluggable, and a non-GPL alternative exists, then I
> think we would strongly consider it but probably want a bit more
> discussion. It's sounding from the below though that it would be a
> core feature.
>
> Hen
>
>
> On Fri, Jul 18, 2008 at 11:11 AM, Noah Slater <ns...@apache.org> wrote:
> > Hello,
> >
> > The CouchDB community have been discussing the issues around using an external
> > library and/or bindings for full text database search.
> >
> > A candidate that keeps coming up as a possibility for us is Xapian.
> >
> > Xapian and it's libraries are covered by the GPL 2 or later, which includes the
> > GPL 3 which is "compatible" with the Apache Licence 2.
> >
> > My question is, can CouchDB do any of the following:
> >
> > * Write a full text search component for the core distribution that uses the
> > Xapian libraries that are installed on your system, without directly bundling
> > either Xapian or it's related libraries.
> >
> > * As above but bundling Xapian or the library in the release artifact.
> >
> > Thanks,
> >
> > --
> > Noah Slater, http://people.apache.org/~nslater/
> >
> > ---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and educational
> > only. Statements made on this list are not privileged, do not
> > constitute legal advice, and do not necessarily reflect the opinions
> > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > official ASF policies and documents.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Using a GPL library with Apache CouchDB
Posted by Henri Yandell <ba...@apache.org>.
My opinion on both is that the answer is "No, not at Apache". It
would, by the sound of things so far, make CouchDB GPL.
If the feature is pluggable, and a non-GPL alternative exists, then I
think we would strongly consider it but probably want a bit more
discussion. It's sounding from the below though that it would be a
core feature.
Hen
On Fri, Jul 18, 2008 at 11:11 AM, Noah Slater <ns...@apache.org> wrote:
> Hello,
>
> The CouchDB community have been discussing the issues around using an external
> library and/or bindings for full text database search.
>
> A candidate that keeps coming up as a possibility for us is Xapian.
>
> Xapian and it's libraries are covered by the GPL 2 or later, which includes the
> GPL 3 which is "compatible" with the Apache Licence 2.
>
> My question is, can CouchDB do any of the following:
>
> * Write a full text search component for the core distribution that uses the
> Xapian libraries that are installed on your system, without directly bundling
> either Xapian or it's related libraries.
>
> * As above but bundling Xapian or the library in the release artifact.
>
> Thanks,
>
> --
> Noah Slater, http://people.apache.org/~nslater/
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org