You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "dandiep@apache.org" <da...@apache.org> on 2005/08/03 02:58:21 UTC
ASL Only Distribution Policy [was Apache's LGPL Policy]
Of course I forgot to rename the thread. Please reply here.
dandiep@apache.org wrote:
> Cliff Schmidt wrote:
>
>> KEY POINT (but should maybe be a different thread):
>> Distributing software that is licensed under terms that are not part
>> of the Apache License (whether in isolation or bundled) is currently
>> against ASF policy. It's not a problem with the LGPL; it's a matter
>> of the expectation we have set up with our users. Over the years, our
>> users have come to expect that when they point to http://apache.org,
>> follow a link to an Apache project, and then click download, they are
>> getting software licensed under the Apache License. Of course, they
>> should read the LICENSE file, especially if they are redistributing
>> it, but so far (with few, if any, exceptions), users have been able to
>> rely on the fact that Apache always ships software that that includes
>> terms they are familiar with, which put relatively few restrictions on
>> the personal or commercial redistribution of the software. This is
>> why we don't ship LGPL software in any form at all -- not because
>> there's a trick in the LGPL license, but simply because it would not
>> allow the package to be distributed solely under the terms of the
>> Apache License.
>>
>> NOTE: if you want to raise an issue about the above policy, feel free,
>> but please start a new thread since it is orthogonal to the policy of
>> being able to distribute software that simply requires the LGPL
>> library to be present.
>>
>>
> Consider this raising an issue in a new thread. :-)
>
> I'm confused, can't projects already put non ASL licensed jars in
> their distributions (Sun BCL, CPL, and MPL - see
> http://wiki.apache.org/jakarta/LicenceIssues)?
>
> Then, why is redistributing LGPL jars a problem if "research into the
> impact of distributing ASF products that depend on the presence of
> LGPL-licensed libraries has indicated that the product licensing terms
> are not affected by such a dependency"?
>
> Thanks,
> - Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 2, 2005 8:42:56 PM -0700 Cliff Schmidt <cl...@gmail.com>
wrote:
> Actually -- that is what I used to think before I concocted the
> following use case and assertion, which the FSF agreed to. The short
> version is that Java actually should not have to invoke section 6
> because those requirements aren't needed for a .jar, which allows easy
> separation of program and library. These requirements are there for
> C-style executables, which would be much more difficult to separate
> out the original library -- hence the reverse-engineering terms.
>
> So, again -- the only reason I did not propose an LGPL policy that
> allowed projects to distribute a work that includes an LGPL .jar is
> because of the long-standing ASF policy to only distribute software
> from Apache servers that can be licensed under the terms of the Apache
> license.
Okay, I didn't realize you had broached this with them. So, this places it
back in our court now. Fair enough. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Justin Erenkrantz wrote:
> --On August 4, 2005 9:52:22 AM -0400 Jeffrey Thompson
> <jt...@us.ibm.com> wrote:
>
>> Here's where I lose the reasoning. If I understand the FSF
>> correctly, if I
>> write a program that is designed to be linked to a GPL program, it is a
>> derivative work of that GPL program whether or not I actually do the
>> linking
>> before I distribute my program. So, if my licensee dynamically or
>> statically links the GPL program to mine as part of the normal use of
>> the
>> program, I have obligations under the GPL. Is that still the FSF
>> position?
>>
>> If so, then the only way that I can see that happening is the
>> information
>> that I used on the interfaces to the GPL program is the "work" that I
>> made a
>> derivative of, apparently even if it is a published interface
>> independent of
>> the GPL program at issue. That seems strange to me, but taken at face
>> value, and applying that to this use case, wouldn't any program
>> written to
>> subclass the LGPL java classes also be a derivative work? So, the
>> phrase
>> "This is obviously the case for a Program that contains nothing
>> derivative
>> of any portion of the Library" describes a null set (accepting the FSF
>> position on derivatives).
>
>
> In order to ensure that I understand you correctly, let me try to
> rephrase your statements:
>
> The FSF has previously stated that 'using a library' in a GPLd work
> (but not specifically LGPL) creates a derivative work that must be
> covered by the GPL. But, this apparently differs from what the FSF
> seems to agree on for a LGPL-licensed project in Cliff's use cases.
> However, the definition of a derivative work should not differ
> depending upon the license. Since the GPL is the FSF's principal
> license, it's possible that the FSF might backtrack from their
> position once they realize the implications of this position for the
> GPLd code (i.e. that using it this way does not create a derivative
> work; hence 'falls outside the scope of this license').
>
> Is this a fair restatement?
I think its ok that the derivitive definition varies between licenses.
Thats why we define things. In case of the LPGL we know a program is not
a derivitive when:
""A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library". Such a work, in
isolation, is not a derivative work of the Library, and therefore falls
outside the scope of this License.""
But in the GPL derivitive is:
"A "work based on the Library" means either the Library or any
derivative work under copyright law: that is to say, a work containing
the Library or a portion of it, either verbatim or with modifications
and/or translated straightforwardly into another language."
IANAL, but I'm pretty sure they're completely different definitions. So
yes, if you try to combine the two it doesn't work, but they are meant
to be looked at individually. So is the GPL really relavent to this
discussion?
>> Obviously, I'm missing something in the FSF's reasoning. Their
>> opinion on
>> the use case is the right answer in my view, but I just don't see how
>> they
>> get there.
>
>
> Agreed.
>
>> <DISCLAIMER> I'm not trying to start a religious war, just trying to
>> understand some of the more detailed nuances of the FSF position.
>> </DISCLAIMER>
>
>
> Nope, I understand that. This is why we want discussion on this.
>
> Thanks! -- justin
>
Hooray for firendly discussions! :-)
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> Okay, let's see what we can do about getting clarifications from the
> FSF on these issues.
That would be a waste of time. The FSF's interpretation of copyright
law is irrelevant (and wrong). What matters to us is how they interpret
the license they are willing to give us and our users -- the LGPL.
....Roy
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 08/04/2005 02:49:02 PM:
> --On August 4, 2005 2:03:15 PM -0400 Jeffrey Thompson <jthom@us.ibm.
> com> wrote:
>
> > Actually, I wasn't expecting that the FSF would change its opinion on
the
> > Use Case, but I guess that is possible. I'm just assuming that there
is a
> > reasonable way of reconciling those positions which I am unable
todetermine
> > at this point.
>
> Your earlier email also said:
> > Their opinion on the use case is the right answer in my view, but I
just
> > don't see how they get there.
>
> Since you seem to independently (and through another route?) agree with
the
> use cases, would we be placing ourselves (and our users) at risk if we
relied
> upon these use cases being accurate representations of our rights under
the
> LGPL?
>
> Thanks! -- justin
>
I'd be more comfortable if I knew why the positions were consistent. As
you said earlier, if their opinion on the use case contradicts their
opinion on the GPL, their opinion on the use case might change. But, in
the end, I just don't like not understanding stuff. There is risk in the
unknown.
But, as Roy mentioned, the details of FSF's opinion are less important if
FSF isn't the licensor. Whatever legal risk that there is would be
minimized if the licensor specifically agreed with Apache that Apache's
proposed use fell outside the license.
I'd also be interested in whether Apache has a consensus opinion on when
it is reasonable to pre-req LGPL code. Are there situations which
pre-req'ing the code is improper (from Apache's perspective)? From what
I've seen so far on this topic, its clear that there is no problem in
having Apache code interface with optional LGPL extensions. Is it
generally accepted that making it a firm prereq is a problem?
Jeff
Staff Counsel, IBM Corporation (914)766-1757 (tie)8-826 (fax) -8160
(notes) jthom@ibmus (internet) jthom@us.ibm.com (home) jeff@beff.net
(web) http://www.beff.net/
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 4, 2005 2:03:15 PM -0400 Jeffrey Thompson <jt...@us.ibm.com> wrote:
> Actually, I wasn't expecting that the FSF would change its opinion on the
> Use Case, but I guess that is possible. I'm just assuming that there is a
> reasonable way of reconciling those positions which I am unable to determine
> at this point.
Your earlier email also said:
> Their opinion on the use case is the right answer in my view, but I just
> don't see how they get there.
Since you seem to independently (and through another route?) agree with the
use cases, would we be placing ourselves (and our users) at risk if we relied
upon these use cases being accurate representations of our rights under the
LGPL?
Thanks! -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 08/04/2005 01:46:15 PM:
> --On August 4, 2005 9:52:22 AM -0400 Jeffrey Thompson <jthom@us.ibm.
> com> wrote:
> > Here's where I lose the reasoning. If I understand the FSF correctly,
if I
> > write a program that is designed to be linked to a GPL program, it is
a
> > derivative work of that GPL program whether or not I actually do the
linking
> > before I distribute my program. So, if my licensee dynamically or
> > statically links the GPL program to mine as part of the normal use of
the
> > program, I have obligations under the GPL. Is that still the FSF
position?
> >
> > If so, then the only way that I can see that happening is the
information
> > that I used on the interfaces to the GPL program is the "work" that I
made a
> > derivative of, apparently even if it is a published interface
independent of
> > the GPL program at issue. That seems strange to me, but taken at face
> > value, and applying that to this use case, wouldn't any program
written to
> > subclass the LGPL java classes also be a derivative work? So, the
phrase
> > "This is obviously the case for a Program that contains nothing
derivative
> > of any portion of the Library" describes a null set (accepting the FSF
> > position on derivatives).
>
> In order to ensure that I understand you correctly, let me try to
rephrase
> your statements:
>
> The FSF has previously stated that 'using a library' in a GPLd work (but
not
> specifically LGPL) creates a derivative work that must be covered bythe
GPL.
> But, this apparently differs from what the FSF seems to agree on for a
> LGPL-licensed project in Cliff's use cases. However, the definition of
a
> derivative work should not differ depending upon the license. Since the
GPL
> is the FSF's principal license, it's possible that the FSF might
backtrack
> from their position once they realize the implications of this position
for
> the GPLd code (i.e. that using it this way does not create a derivative
work;
> hence 'falls outside the scope of this license').
>
> Is this a fair restatement?
>
Actually, I wasn't expecting that the FSF would change its opinion on the
Use Case, but I guess that is possible. I'm just assuming that there is a
reasonable way of reconciling those positions which I am unable to
determine at this point.
Jeff
Staff Counsel, IBM Corporation (914)766-1757 (tie)8-826 (fax) -8160
(notes) jthom@ibmus (internet) jthom@us.ibm.com (home) jeff@beff.net
(web) http://www.beff.net/
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 4, 2005 9:52:22 AM -0400 Jeffrey Thompson <jt...@us.ibm.com> wrote:
> As I describe below, I'm fuzzy on a couple of things and maybe this list
> can help.
Okay, let's see what we can do about getting clarifications from the FSF on
these issues.
> Here's where I lose the reasoning. If I understand the FSF correctly, if I
> write a program that is designed to be linked to a GPL program, it is a
> derivative work of that GPL program whether or not I actually do the linking
> before I distribute my program. So, if my licensee dynamically or
> statically links the GPL program to mine as part of the normal use of the
> program, I have obligations under the GPL. Is that still the FSF position?
>
> If so, then the only way that I can see that happening is the information
> that I used on the interfaces to the GPL program is the "work" that I made a
> derivative of, apparently even if it is a published interface independent of
> the GPL program at issue. That seems strange to me, but taken at face
> value, and applying that to this use case, wouldn't any program written to
> subclass the LGPL java classes also be a derivative work? So, the phrase
> "This is obviously the case for a Program that contains nothing derivative
> of any portion of the Library" describes a null set (accepting the FSF
> position on derivatives).
In order to ensure that I understand you correctly, let me try to rephrase
your statements:
The FSF has previously stated that 'using a library' in a GPLd work (but not
specifically LGPL) creates a derivative work that must be covered by the GPL.
But, this apparently differs from what the FSF seems to agree on for a
LGPL-licensed project in Cliff's use cases. However, the definition of a
derivative work should not differ depending upon the license. Since the GPL
is the FSF's principal license, it's possible that the FSF might backtrack
from their position once they realize the implications of this position for
the GPLd code (i.e. that using it this way does not create a derivative work;
hence 'falls outside the scope of this license').
Is this a fair restatement?
> Obviously, I'm missing something in the FSF's reasoning. Their opinion on
> the use case is the right answer in my view, but I just don't see how they
> get there.
Agreed.
> <DISCLAIMER> I'm not trying to start a religious war, just trying to
> understand some of the more detailed nuances of the FSF position.
> </DISCLAIMER>
Nope, I understand that. This is why we want discussion on this.
Thanks! -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 08/03/2005 12:07:48 PM:
> --On August 3, 2005 10:18:41 AM -0400 Jeffrey Thompson
<jt...@us.ibm.com>
> wrote:
>
> > Just a note of caution. The FSF is certainly the author of the
license and
> > their opinions and writings on the meaning of that license are very
> > important. However, at the end of the day, the author of the LGPL
licensed
> > code may have an opinion on what these terms mean. Since the meaning
of
> > these terms are highly "nuanced", to say the least, we would want to
> > consider the opinions of the LGPL software's authors as well.
>
> We had a number of directors indicate that they wanted IBM Legal's
opinion
> before we set this policy in motion. So, would IBM agree with the
> opinions of
> the FSF in the use cases we set out? If not, why not? -- justin
Justin,
As I describe below, I'm fuzzy on a couple of things and maybe this
list can help.
Here's the Use Case:
=USE CASE: a "Program" that is distributed "In Isolation".
=
=Definitions
=- -------------------
="Library":
= as defined in the LGPL, but to be more specific, let's limit it to a
=Java .class or .jar file -- without source (which isn't needed for
=these use cases)
=
="Program":
= similar to "a work that uses the Library" (as defined in the LGPL),
=but in Java terms we are talking specifically about a Java source
=file, .class file, or .jar file that imports, implements, or extends
=portions of the Library, and otherwise, contains no code that is a
=derivative of any part of the Library
=
="In Isolation":
= not as part of a combined work that includes the Library
=
=Assertion
=- --------------
=- -->The Program can be distributed In Isolation without any
restrictions.
=
=This is obviously the case for a Program that contains nothing
=derivative of any portion of the Library and would, therefore, fall
=outside the scope of the LGPL (as pointed out in the first paragraph
=of Section 5).
Here's where I lose the reasoning. If I understand the FSF correctly, if
I write a program that is designed to be linked to a GPL program, it is a
derivative work of that GPL program whether or not I actually do the
linking before I distribute my program. So, if my licensee dynamically or
statically links the GPL program to mine as part of the normal use of the
program, I have obligations under the GPL. Is that still the FSF
position?
If so, then the only way that I can see that happening is the information
that I used on the interfaces to the GPL program is the "work" that I made
a derivative of, apparently even if it is a published interface
independent of the GPL program at issue. That seems strange to me, but
taken at face value, and applying that to this use case, wouldn't any
program written to subclass the LGPL java classes also be a derivative
work? So, the phrase "This is obviously the case for a Program that
contains nothing derivative of any portion of the Library" describes a
null set (accepting the FSF position on derivatives).
=
=Furthermore, even if the Program was considered a derivative work, the
=Program still has no licensing restrictions, if the derivative
=portions include no more than the following (and here is where I am
=interpreting your comments about Section 5's impact on Java):
=
=a) the Library's names (namespaces/classes/methods/properties/etc) and
=method signatures within the Program's source code or .class files, as
=necessary for such importing/implementing/extending,
=
=and/or
=
=b) minor portions (e.g. constant values/string within a Library's Java
=Interface) of the Library that may be copied into the Program's .class
=file as a direct result of the Java compilation process when
=importing, implementing, or extending another Java .class file.
This seems to be based on the exception in paragraph 5 for header file
information and looks to me to be a reasonable application of those
principles to an objected oriented language. So, that is clear. But the
reason that I'm still fuzzy is that paragraph 5 applies to a "work that
uses the library" and that definition requires that the work not be a
derivative of the library. So we're back to my first point, if you accept
the FSF's definition of derivative (writing to the interface), then there
are no "works that use the library".
Obviously, I'm missing something in the FSF's reasoning. Their opinion on
the use case is the right answer in my view, but I just don't see how they
get there.
<DISCLAIMER> I'm not trying to start a religious war, just trying to
understand some of the more detailed nuances of the FSF position.
</DISCLAIMER>
Jeff
Staff Counsel, IBM Corporation (914)766-1757 (tie)8-826 (fax) -8160
(notes) jthom@ibmus (internet) jthom@us.ibm.com (home) jeff@beff.net
(web) http://www.beff.net/
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 3, 2005 10:18:41 AM -0400 Jeffrey Thompson <jt...@us.ibm.com>
wrote:
> Just a note of caution. The FSF is certainly the author of the license and
> their opinions and writings on the meaning of that license are very
> important. However, at the end of the day, the author of the LGPL licensed
> code may have an opinion on what these terms mean. Since the meaning of
> these terms are highly "nuanced", to say the least, we would want to
> consider the opinions of the LGPL software's authors as well.
We had a number of directors indicate that they wanted IBM Legal's opinion
before we set this policy in motion. So, would IBM agree with the opinions of
the FSF in the use cases we set out? If not, why not? -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Cliff Schmidt <cl...@gmail.com> wrote on 08/03/2005 02:13:57 AM:
> On 8/2/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> > So, if I understand correctly, there is no redistribution problem at
all
> > from the legal side of things other than the ASF does not want LGPL
jars
> > distributed??
> >
> > To be clear, both ASF and FSF lawyers agree that:
> > * Importing classes from an LGPL jar does not create a derivitive work
> > or require the work to be licensed under the LGPL
>
> FSF has agreed that importing classes from an LGPL jar does not
> require licensing of the work to be restricted in any way.
>
> > * Including an LGPL jar in a distribution does not create a derivitive
> > work or require the work to be licensed under the LGPL
>
> The FSF would say that, in the case of the distribution being another
> .jar (or .zip or .tgz), section 5 still covers the case.
>
> > * Section 6 is NOT invoked
>
> yep
>
Just a note of caution. The FSF is certainly the author of the license
and their opinions and writings on the meaning of that license are very
important. However, at the end of the day, the author of the LGPL
licensed code may have an opinion on what these terms mean. Since the
meaning of these terms are highly "nuanced", to say the least, we would
want to consider the opinions of the LGPL software's authors as well.
Jeff
Staff Counsel, IBM Corporation (914)766-1757 (tie)8-826 (fax) -8160
(notes) jthom@ibmus (internet) jthom@us.ibm.com (home) jeff@beff.net
(web) http://www.beff.net/
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Cliff Schmidt <cl...@gmail.com>.
On 8/2/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> So, if I understand correctly, there is no redistribution problem at all
> from the legal side of things other than the ASF does not want LGPL jars
> distributed??
>
> To be clear, both ASF and FSF lawyers agree that:
> * Importing classes from an LGPL jar does not create a derivitive work
> or require the work to be licensed under the LGPL
FSF has agreed that importing classes from an LGPL jar does not
require licensing of the work to be restricted in any way.
> * Including an LGPL jar in a distribution does not create a derivitive
> work or require the work to be licensed under the LGPL
The FSF would say that, in the case of the distribution being another
.jar (or .zip or .tgz), section 5 still covers the case.
> * Section 6 is NOT invoked
yep
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Cliff Schmidt <cl...@gmail.com>.
On 8/3/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> --On August 3, 2005 12:39:31 AM -0400 "Noel J. Bergman" <no...@devtech.com>
> wrote:
>
> > Cliff Schmidt wrote:
> >> So, again -- the only reason I did not propose an LGPL policy that
> >> allowed projects to distribute a work that includes an LGPL .jar is
> >> because of the long-standing ASF policy to only distribute software
> >> from Apache servers that can be licensed under the terms of the Apache
> >> license.
> >
> > Said policy does not and never has existed beyond the bounds of discussion.
> > If it did, few of our Java servers would be distributable, since many binary
> > distributions include dependencies that are not under the Apache license.
>
> You are conflating two issues here.
>
> If the license terms are under the precise language of the AL doesn't matter
> to distribution. The question is whether or not the said license places more
> restrictions than the AL does.
>
> Therefore, if a user follows the terms of the AL, then they also follow all
> the terms of the bundled code that we ship. And, that's certainly not the
> case for the LGPL as it may enforce terms that they find unacceptable (i.e.
> any changes must be made public; and you must permit reverse engineering,
> etc.).
>
> If any ASF project is shipping dependencies that are more restrictive than the
> AL, then they need to pull it. I don't know how you can say that hasn't been
> our policy - we've been very clear about that for a while. -- justin
That is exactly my understanding as well -- sorry if I wasn't clear
enough above.
Cliff
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 3, 2005 12:39:31 AM -0400 "Noel J. Bergman" <no...@devtech.com>
wrote:
> Cliff Schmidt wrote:
>> So, again -- the only reason I did not propose an LGPL policy that
>> allowed projects to distribute a work that includes an LGPL .jar is
>> because of the long-standing ASF policy to only distribute software
>> from Apache servers that can be licensed under the terms of the Apache
>> license.
>
> Said policy does not and never has existed beyond the bounds of discussion.
> If it did, few of our Java servers would be distributable, since many binary
> distributions include dependencies that are not under the Apache license.
You are conflating two issues here.
If the license terms are under the precise language of the AL doesn't matter
to distribution. The question is whether or not the said license places more
restrictions than the AL does.
Therefore, if a user follows the terms of the AL, then they also follow all
the terms of the bundled code that we ship. And, that's certainly not the
case for the LGPL as it may enforce terms that they find unacceptable (i.e.
any changes must be made public; and you must permit reverse engineering,
etc.).
If any ASF project is shipping dependencies that are more restrictive than the
AL, then they need to pull it. I don't know how you can say that hasn't been
our policy - we've been very clear about that for a while. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Cliff Schmidt wrote:
>So, again -- the only reason I did not propose an LGPL policy that
>allowed projects to distribute a work that includes an LGPL .jar is
>because of the long-standing ASF policy to only distribute software
>from Apache servers that can be licensed under the terms of the Apache
>license.
Said policy does not and never has existed beyond the bounds of discussion.
If it did, few of our Java servers would be distributable, since many binary
distributions include dependencies that are not under the Apache license.
--- Noel
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Cliff Schmidt wrote:
>On 8/2/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>
>
>>No. When the LGPL code and AL code are distributed together, the AL code is
>>subject to additional terms inside of the LGPL - namely Section 6 - which
>>means that we have to permit modification and reverse engineering on our code.
>>Our position is that condition is not permissable to pass along to our
>>developers and users.
>>
>>Keeping them separate triggers only Section 5 ("outside the scope of this
>>license").
>>
>>
>
>Actually -- that is what I used to think before I concocted the
>following use case and assertion, which the FSF agreed to. The short
>version is that Java actually should not have to invoke section 6
>because those requirements aren't needed for a .jar, which allows easy
>separation of program and library. These requirements are there for
>C-style executables, which would be much more difficult to separate
>out the original library -- hence the reverse-engineering terms.
>
>So, again -- the only reason I did not propose an LGPL policy that
>allowed projects to distribute a work that includes an LGPL .jar is
>because of the long-standing ASF policy to only distribute software
>from Apache servers that can be licensed under the terms of the Apache
>license.
>
>Note that MPL executables are specifically allowed to be licensed
>under other terms as long as the license includes a few provisions
>that are covered in the Apache License. This MPL distribution policy
>has never been formalized to my knowledge, but I am hoping to do that
>in parallel with the LGPL policy.
>
>Cliff
>
>and here's the second use case and assertion, to which the FSF also
>agreed (note that reference to use case #1 is the same use case sent
>at the beginning of the "Apache's LGPL Policy" thread):
>
>
>USE CASE #2: a "Program" and "Library" are merely aggregated inside a
>.jar/.tgz/.zip and distributed
>
>Definitions (same as last time, but copied here for convenience)
>-------------------
>"Library":
> as defined in the LGPL, but to be more specific, let's limit it to a
>Java .class or .jar file -- without source (which isn't needed for
>these use cases)
>
>"Program":
> similar to "a work that uses the Library" (as defined in the LGPL),
>but in Java terms we are talking specifically about a Java source
>file, .class file, or .jar file that imports, implements, or extends
>portions of the Library, and otherwise, contains no code that is a
>derivative of any part of the Library
>
>Assertion
>--------------
>-->Distribution of the Library and Program as an aggregation inside a
>.jar/.tgz/.zip does not bring the Program under the scope of the LGPL,
>but does require compliance with the terms of sections 4 for the
>redistribution of the Library.
>
>I'm primarily basing this assertion on the last paragraph of section
>2, which I believe should apply whether the Library is distributed
>modified or verbatim:
>
>"In addition, mere aggregation of another work not based on the
>Library with the Library (or with a work based on the Library) on a
>volume of a storage or distribution medium does not bring the other
>work under the scope of this License."
>
>I'm suggesting that a .jar/.tgz/.zip are distribution mediums, just as
>a cd-rom is. They are a means of packaging together multiple software
>components into the convenience of one download that is easily
>divisible. As long as the license terms are met for each included
>component, distributing them together in a .jar/.tgz/.zip should not
>cause any new terms to apply.
>
>If the Program of Use Case #1 could be distributed in isolation
>without any restrictions, the mere aggregation of the same Program
>with the Library in a single distribution medium should not put
>restrictions on the Program.
>
>
So, if I understand correctly, there is no redistribution problem at all
from the legal side of things other than the ASF does not want LGPL jars
distributed??
To be clear, both ASF and FSF lawyers agree that:
* Importing classes from an LGPL jar does not create a derivitive work
or require the work to be licensed under the LGPL
* Including an LGPL jar in a distribution does not create a derivitive
work or require the work to be licensed under the LGPL
* Section 6 is NOT invoked
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Dan Diephouse <da...@apache.org>.
Cliff Schmidt wrote:
>Actually -- that is what I used to think before I concocted the
>following use case and assertion, which the FSF agreed to. The short
>version is that Java actually should not have to invoke section 6
>because those requirements aren't needed for a .jar, which allows easy
>separation of program and library. These requirements are there for
>C-style executables, which would be much more difficult to separate
>out the original library -- hence the reverse-engineering terms.
>
>So, again -- the only reason I did not propose an LGPL policy that
>allowed projects to distribute a work that includes an LGPL .jar is
>because of the long-standing ASF policy to only distribute software
>from Apache servers that can be licensed under the terms of the Apache
>license.
>
Since you've determined that its legally OK and doesn't affect the ASL
licensed software, how do we change the policy? Or if there actually is
no policy, can we get an official OK from the board? Is there anything
I can do?
Thanks,
- Dan
--
Dan Diephouse
http://netzooid.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Cliff Schmidt <cl...@gmail.com>.
On 8/2/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> No. When the LGPL code and AL code are distributed together, the AL code is
> subject to additional terms inside of the LGPL - namely Section 6 - which
> means that we have to permit modification and reverse engineering on our code.
> Our position is that condition is not permissable to pass along to our
> developers and users.
>
> Keeping them separate triggers only Section 5 ("outside the scope of this
> license").
Actually -- that is what I used to think before I concocted the
following use case and assertion, which the FSF agreed to. The short
version is that Java actually should not have to invoke section 6
because those requirements aren't needed for a .jar, which allows easy
separation of program and library. These requirements are there for
C-style executables, which would be much more difficult to separate
out the original library -- hence the reverse-engineering terms.
So, again -- the only reason I did not propose an LGPL policy that
allowed projects to distribute a work that includes an LGPL .jar is
because of the long-standing ASF policy to only distribute software
from Apache servers that can be licensed under the terms of the Apache
license.
Note that MPL executables are specifically allowed to be licensed
under other terms as long as the license includes a few provisions
that are covered in the Apache License. This MPL distribution policy
has never been formalized to my knowledge, but I am hoping to do that
in parallel with the LGPL policy.
Cliff
and here's the second use case and assertion, to which the FSF also
agreed (note that reference to use case #1 is the same use case sent
at the beginning of the "Apache's LGPL Policy" thread):
USE CASE #2: a "Program" and "Library" are merely aggregated inside a
.jar/.tgz/.zip and distributed
Definitions (same as last time, but copied here for convenience)
-------------------
"Library":
as defined in the LGPL, but to be more specific, let's limit it to a
Java .class or .jar file -- without source (which isn't needed for
these use cases)
"Program":
similar to "a work that uses the Library" (as defined in the LGPL),
but in Java terms we are talking specifically about a Java source
file, .class file, or .jar file that imports, implements, or extends
portions of the Library, and otherwise, contains no code that is a
derivative of any part of the Library
Assertion
--------------
-->Distribution of the Library and Program as an aggregation inside a
.jar/.tgz/.zip does not bring the Program under the scope of the LGPL,
but does require compliance with the terms of sections 4 for the
redistribution of the Library.
I'm primarily basing this assertion on the last paragraph of section
2, which I believe should apply whether the Library is distributed
modified or verbatim:
"In addition, mere aggregation of another work not based on the
Library with the Library (or with a work based on the Library) on a
volume of a storage or distribution medium does not bring the other
work under the scope of this License."
I'm suggesting that a .jar/.tgz/.zip are distribution mediums, just as
a cd-rom is. They are a means of packaging together multiple software
components into the convenience of one download that is easily
divisible. As long as the license terms are met for each included
component, distributing them together in a .jar/.tgz/.zip should not
cause any new terms to apply.
If the Program of Use Case #1 could be distributed in isolation
without any restrictions, the mere aggregation of the same Program
with the Library in a single distribution medium should not put
restrictions on the Program.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Aug 03, 2005 at 11:19:38AM +1000, Brett Porter wrote:
> justin wrote:
>
> >As I understand it, distributing them *together* means that the *entire* work
> >(i.e. our ALv2-licensed code) falls under the LGPL. That's the flip side of
> >the use case discussed by Cliff with the FSF.
> >
> >It's only okay if they are distributed separately ("In Isolation"). -- justin
> >
> >
> I don't quite understand how this can be the case.
>
> I thought it meant that the distribution is partially ASL and partially
> LGPL, and this is unacceptable to the ASF. The library retains its LGPL
> standing, and the rest of the code retains its ASL standing. The only
> way this is any different to other BSD-like licenses is that they don't
> enforce any additional restrictions that the ASL doesn't so businesses
> can still feel safe downloading the distribution.
>
> Is this correct?
No. When the LGPL code and AL code are distributed together, the AL code is
subject to additional terms inside of the LGPL - namely Section 6 - which
means that we have to permit modification and reverse engineering on our code.
Our position is that condition is not permissable to pass along to our
developers and users.
Keeping them separate triggers only Section 5 ("outside the scope of this
license").
HTH. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Brett Porter <br...@apache.org>.
justin wrote:
>As I understand it, distributing them *together* means that the *entire* work
>(i.e. our ALv2-licensed code) falls under the LGPL. That's the flip side of
>the use case discussed by Cliff with the FSF.
>
>It's only okay if they are distributed separately ("In Isolation"). -- justin
>
>
I don't quite understand how this can be the case.
I thought it meant that the distribution is partially ASL and partially
LGPL, and this is unacceptable to the ASF. The library retains its LGPL
standing, and the rest of the code retains its ASL standing. The only
way this is any different to other BSD-like licenses is that they don't
enforce any additional restrictions that the ASL doesn't so businesses
can still feel safe downloading the distribution.
Is this correct?
Thanks,
Brett
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by "dandiep@apache.org" <da...@apache.org>.
jar -cf lpgl-lib-src.jar lgpl_src; cp lgpl-lib-src.jar distribution;
I still don't see why that stops us from putting lgpl jars in the
distribution.
- Dan
Davanum Srinivas wrote:
>Dan,
>
>we'd need to make source code available if we ship lgpl jars.
>
>-- dims
>
>On 8/2/05, dandiep@apache.org <da...@apache.org> wrote:
>
>
>>Of course I forgot to rename the thread. Please reply here.
>>
>>dandiep@apache.org wrote:
>>
>>
>>
>>>Cliff Schmidt wrote:
>>>
>>>
>>>
>>>>KEY POINT (but should maybe be a different thread):
>>>>Distributing software that is licensed under terms that are not part
>>>>of the Apache License (whether in isolation or bundled) is currently
>>>>against ASF policy. It's not a problem with the LGPL; it's a matter
>>>>of the expectation we have set up with our users. Over the years, our
>>>>users have come to expect that when they point to http://apache.org,
>>>>follow a link to an Apache project, and then click download, they are
>>>>getting software licensed under the Apache License. Of course, they
>>>>should read the LICENSE file, especially if they are redistributing
>>>>it, but so far (with few, if any, exceptions), users have been able to
>>>>rely on the fact that Apache always ships software that that includes
>>>>terms they are familiar with, which put relatively few restrictions on
>>>>the personal or commercial redistribution of the software. This is
>>>>why we don't ship LGPL software in any form at all -- not because
>>>>there's a trick in the LGPL license, but simply because it would not
>>>>allow the package to be distributed solely under the terms of the
>>>>Apache License.
>>>>
>>>>NOTE: if you want to raise an issue about the above policy, feel free,
>>>>but please start a new thread since it is orthogonal to the policy of
>>>>being able to distribute software that simply requires the LGPL
>>>>library to be present.
>>>>
>>>>
>>>>
>>>>
>>>Consider this raising an issue in a new thread. :-)
>>>
>>>I'm confused, can't projects already put non ASL licensed jars in
>>>their distributions (Sun BCL, CPL, and MPL - see
>>>http://wiki.apache.org/jakarta/LicenceIssues)?
>>>
>>>Then, why is redistributing LGPL jars a problem if "research into the
>>>impact of distributing ASF products that depend on the presence of
>>>LGPL-licensed libraries has indicated that the product licensing terms
>>>are not affected by such a dependency"?
>>>
>>>Thanks,
>>>- Dan
>>>
>>>
>>--
>>Dan Diephouse
>>Envoi Solutions LLC
>>http://netzooid.com
>>
>>
>>---------------------------------------------------------------------
>>DISCLAIMER: Discussions on this list are informational and educational
>>only, are not privileged and do not constitute legal advice.
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
>>
>
>
>
>
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Posted by Davanum Srinivas <da...@gmail.com>.
Dan,
we'd need to make source code available if we ship lgpl jars.
-- dims
On 8/2/05, dandiep@apache.org <da...@apache.org> wrote:
> Of course I forgot to rename the thread. Please reply here.
>
> dandiep@apache.org wrote:
>
> > Cliff Schmidt wrote:
> >
> >> KEY POINT (but should maybe be a different thread):
> >> Distributing software that is licensed under terms that are not part
> >> of the Apache License (whether in isolation or bundled) is currently
> >> against ASF policy. It's not a problem with the LGPL; it's a matter
> >> of the expectation we have set up with our users. Over the years, our
> >> users have come to expect that when they point to http://apache.org,
> >> follow a link to an Apache project, and then click download, they are
> >> getting software licensed under the Apache License. Of course, they
> >> should read the LICENSE file, especially if they are redistributing
> >> it, but so far (with few, if any, exceptions), users have been able to
> >> rely on the fact that Apache always ships software that that includes
> >> terms they are familiar with, which put relatively few restrictions on
> >> the personal or commercial redistribution of the software. This is
> >> why we don't ship LGPL software in any form at all -- not because
> >> there's a trick in the LGPL license, but simply because it would not
> >> allow the package to be distributed solely under the terms of the
> >> Apache License.
> >>
> >> NOTE: if you want to raise an issue about the above policy, feel free,
> >> but please start a new thread since it is orthogonal to the policy of
> >> being able to distribute software that simply requires the LGPL
> >> library to be present.
> >>
> >>
> > Consider this raising an issue in a new thread. :-)
> >
> > I'm confused, can't projects already put non ASL licensed jars in
> > their distributions (Sun BCL, CPL, and MPL - see
> > http://wiki.apache.org/jakarta/LicenceIssues)?
> >
> > Then, why is redistributing LGPL jars a problem if "research into the
> > impact of distributing ASF products that depend on the presence of
> > LGPL-licensed libraries has indicated that the product licensing terms
> > are not affected by such a dependency"?
> >
> > Thanks,
> > - Dan
>
>
> --
> Dan Diephouse
> Envoi Solutions LLC
> http://netzooid.com
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org