You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Robert Burrell Donkin <rd...@apache.org> on 2008/03/11 23:30:49 UTC
Re: fair use (was Re: What licenses in category X satisfy
criterion #2?)
On Wed, 2008-03-05 at 07:37 -0800, Joe Schaefer wrote:
> --- Ralph Goers <Ra...@dslextreme.com> wrote:
>
> > Criteria #2 refers to licenses like the GPL
> > which says in part
> >
> > > The "Program", below,
> > > refers to any such program or work, and a "work
> > > based on the Program"
> > > means either the Program or any derivative work
> > > under copyright law:
> > > that is to say, a work containing the Program or a
> > > portion of it,
> > > either verbatim or with modifications and/or
> > > translated into another
> > > language.
>
> > So any program which uses a library licensed under
> > the GPL must also be
> > licensed under the GPL as they would be considered
> > to be derivative
> > works.
>
> I will repeat my statement that a license
> is not the arbiter of what is or is not a derivative
> work. The question to me is whether or not writing
> some glue code to interface with some 3rd party
> GPL'd code qualifies as fair use, and is therefore
> not considered by the courts as a derivative work.
that depends on what you mean by derivative work :-)
AIUI the GPL 2.0 includes a redefinition of the term. if you accept the
license, the FSF claims that you agree to play by their rules. this
linking scenario is definitely what the FSF had in mind when they drew
up the GPL and (in the past) they have been aggressive in enforcing
these provisions. i don't know of anyone who's claimed that linking is
fair use of the GPL and won in court.
AIUI when applying fair use, the process matters. it is acceptable under
US copyright law to reverse engineer an interface for compatibility.
however, breaching the terms of the GPL by downloading the source and
writing and then linking against it is not typical reverse engineering.
it may well fall outside fair use.
- robert
Re: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Ralph Goers <Ra...@dslextreme.com> wrote:
>
>
> Joe Schaefer wrote:
> >
> > Thanks Justin, that's what I was looking for.
> > Staying away from GPL because the owners of a work
> > want you to is a perfectly fine policy position
> > to take. But in the Hibernate case, they are
> > granting us an interpretation of LGPL that is
> > incredibly favorable to the ASF, and simply
> > ignoring that for policy reasons alone
> > doesn't make much sense to me.
> >
> >
> Hibernate's interpretation seems to be slightly
> different than the
> FSF's. They seem to be saying that Hibernate can be
> used by code with
> any license, even one which prohibits reverse
> engineering. The FSF's
> position seems to be different than that. Frankly,
> under these
> circumstances I'm not sure what the right answer is.
Maybe we could handle this situation with proper
labeling. We could say something along the lines
that while the FSF's interpretation of the LGPL
places conditions on artifacts compiled against
Hiberate, the Hibernate community has waived those
conditions.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion
#2?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>
> Thanks Justin, that's what I was looking for.
> Staying away from GPL because the owners of a work
> want you to is a perfectly fine policy position
> to take. But in the Hibernate case, they are
> granting us an interpretation of LGPL that is
> incredibly favorable to the ASF, and simply
> ignoring that for policy reasons alone
> doesn't make much sense to me.
>
>
Hibernate's interpretation seems to be slightly different than the
FSF's. They seem to be saying that Hibernate can be used by code with
any license, even one which prohibits reverse engineering. The FSF's
position seems to be different than that. Frankly, under these
circumstances I'm not sure what the right answer is.
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> Back to what you started off with:
> ---
> The question to me is whether or not writing
> some glue code to interface with some 3rd party
> GPL'd code qualifies as fair use, and is therefore
> not considered by the courts as a derivative work.
> ---
>
> So, while the license or even the underlying
> copyright law may or may
> not be clear, many GPL authors are quite clear that
> they view any such
> 'glue' as a derived work. As such, I sort of doubt
> we would go
> against their express desires - even if we could
> legally do so. --
> justin
Thanks Justin, that's what I was looking for.
Staying away from GPL because the owners of a work
want you to is a perfectly fine policy position
to take. But in the Hibernate case, they are
granting us an interpretation of LGPL that is
incredibly favorable to the ASF, and simply
ignoring that for policy reasons alone
doesn't make much sense to me.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Joe Schaefer wrote:
> Justin Erenkrantz wrote:
> > GregKH says in http://www.kroah.com/log/linux/ols_2006_keynote.html
> > "Closed source Linux modules are illegal."
> Thanks. I don't think the kernel analogy holds tight,
> because httpd isn't GPL.
Linux explicitly declared the ABI to be a licensing firewall, therefore
httpd need not be GPL. But kernel modules don't have the same option.
--- 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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, Mar 11, 2008 at 4:01 PM, Joe Schaefer
> <jo...@yahoo.com> wrote:
> > But I did not say "linking", which is a
> relationship
> > between two binary files, I said "using". In C,
> > there is a concept known as loadable modules. It
> > is my opinion that a closed source distributor of
> > loadable modules for httpd may package some GPL'd
> > modules into their distribution, and as long as
> > they honor the terms of the GPL on those modules,
> > they need not do so on the others. Even if those
> > other proprietary modules make optional calls
> into
> > the GPL modules' interfaces.
>
> At the very least, this is at odds with the
> perspective of many people
> who release GPL software. Simply invoking any GPL
> code (ie your
> 'using') is enough that they intend that you release
> all of your code
> as GPL. GregKH says in
> http://www.kroah.com/log/linux/ols_2006_keynote.html
>
> "Closed source Linux modules are illegal."
>
> (Search for: "So, here's the simple answer to this
> issue:"...)
Thanks. I don't think the kernel analogy holds tight,
because httpd isn't GPL. In the case I'm considering,
the proprietary module author is just pulling in a
symbol and recasting it. I don't think any GPL'd
object files would be generated by such an act.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Mar 11, 2008 at 4:01 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> But I did not say "linking", which is a relationship
> between two binary files, I said "using". In C,
> there is a concept known as loadable modules. It
> is my opinion that a closed source distributor of
> loadable modules for httpd may package some GPL'd
> modules into their distribution, and as long as
> they honor the terms of the GPL on those modules,
> they need not do so on the others. Even if those
> other proprietary modules make optional calls into
> the GPL modules' interfaces.
At the very least, this is at odds with the perspective of many people
who release GPL software. Simply invoking any GPL code (ie your
'using') is enough that they intend that you release all of your code
as GPL. GregKH says in
http://www.kroah.com/log/linux/ols_2006_keynote.html
"Closed source Linux modules are illegal."
(Search for: "So, here's the simple answer to this issue:"...)
Back to what you started off with:
---
The question to me is whether or not writing
some glue code to interface with some 3rd party
GPL'd code qualifies as fair use, and is therefore
not considered by the courts as a derivative work.
---
So, while the license or even the underlying copyright law may or may
not be clear, many GPL authors are quite clear that they view any such
'glue' as a derived work. As such, I sort of doubt we would go
against their express desires - even if we could legally do so. --
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Henri Yandell <ba...@apache.org> wrote:
> You could improve the algorithm approach to cover
> these; talk about
> compiling vs not compiling,
That wouldn't resolve anything, since there are
plenty of perl modules which are compiled by a
C compiler.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Henri Yandell <ba...@apache.org>.
On Fri, Mar 14, 2008 at 7:52 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> --- Joe Schaefer <jo...@yahoo.com> wrote:
>
> >
> > --- Robert Burrell Donkin <rd...@apache.org>
> > wrote:
> >
> > > On Thu, 2008-03-13 at 10:07 -0700, Henri Yandell
> > > wrote:
> > >
> > > <snip>
> > >
> > > > More important right now would be the issues of
> > > > what the FSF's
> > > > non-compiled/dynamic-linked stance is,
> > >
> > > +1
> > >
> > > even when we've disagreed with the FSF's
> > > interpretation we've respect
> > > the spirit and intention of their licenses (as
> > > expressed by the FSF).
> > > IMO this approach should be continued.
> >
> > I just dug this up:
> >
> >
> http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
> >
> > It directly conflicts with what I said about
> > the situation for spamassassin. According
> > to that url, if spamassassin acquired a GPL
> > dependency, it would have to license everything
> > under the GPL. (The FSF apparently believes
> > copyright extends to actual processes, not
> > just files on the filesystem).
>
> FWIW, here's what the US Copyright Act says about
> computer programs:
>
> § 117. Limitations on exclusive rights: Computer
> programs
>
> (a) Making of Additional Copy or Adaptation by Owner
>
> of Copy. — Notwithstanding the provisions of section
>
> 106, it is not an infringement for the owner of a
> copy of a computer program to make or authorize the
> making of another copy or adaptation of that
> computer
> program provided:
>
> (1) that such a new copy or adaptation is created as
>
> an essential step in the utilization of the computer
>
> program in conjunction with a machine and that it is
>
> used in no other manner, or
>
> [...]
>
> To me, that seems to say that copying the bits of a
> file from the filesystem to into main memory isn't
> infringing copyright, so I don't understand the FSF's
> position here. Can anyone here enlighten me about it?
I suspect they're grappling with the same kind of grey area that we are.
They want to allow environmental type applications - that way GPL on
Win32 is good, a GPL Rebol script is good etc. At the same time, they
want the use of code libraries to be considered linking. In this case,
dynamic linking.
This definitely fits how we should look at it - judge the intent
rather than trying to pick holes in the license. So bash scripts would
be fine as it's an interpreter and they want people to use it, a GPL
Perl module would not be fine as it's a library. Same for the standard
JDK modules that come with the Java interpreter. If you used Perl
under the GPL rahter than Artistic license, all your code would need
to be GPL. Ditto if you run code on top of OpenJDK with a pure GPL
license, your code would be GPL.
=-=-=
As I'm not immune - here's another hole to pick:
There seems to be a bit of a big contradiction in the FAQ item after
the one you link to.
Things distributed with the compiler are considered System Libraries
under GPL and LGPL. I don't know about you, but the standard Java
classes fit that description very well to me. I get the Java compiler,
and a bunch of libraries. That would imply that OpenJDK-SE does not
need the Classpath exception. Which also means that not having the
classpath exception for OpenJDK-ME isn't protecting anyone.
The "Interpreter's modules pass GPL", and the "System Libraries do not
pass GPL" entries seem to contradict each other when the interpreted
language uses a separate compiler to create its variant of object
code.
=-=-=
We could spend ages digging into such things. End of the day: Bash
scripts => clean. Use of a perl module or Java library => messy.
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Ralph Goers <Ra...@dslextreme.com> wrote:
> Joe Schaefer wrote:
> > But following the FSF's position, the conditions
> > of section 6 are still being placed (indirectly)
> > on the bridge code we write, so we need to be
> > careful in how we represent the licensing
> > on those bits.
> >
> That is absolutely correct.
It's a very tricky situation. I still think
the bridge code, as source code, is itself
not a derivative work, and thus we can place the
Apache license on those source code files.
But we do have to notify users that the chunks
of code we're releasing which depends on LGPL
stuff has conditions attached to it which are
not spelled out in our license. I'm not sure
what the best way of doing that is: but I don't
think it's as simple as just not distributing
the LGPL code.
> >
> > So lets return to the Subject of this thread,
> > because it may turn out that I am misparsing
> > what is written in the draft. Here's the
> > excerpt in question:
> >
> > YOU MAY include code within the Apache product
> > necessary to achieve compatibility with a
> > prohibited
> > work through the use of API calls, "bridge
> > code", or
> > protocols, provided that the compatibility code
> > was
> > contributed under a CLA. However, any such code
> > used
> > for compatibility with a third-party work that
> > is
> > ^^^^
> > ^^
> > Which noun does "that" refer to here? Does it
> > refer
> > to "such code" or does it refer to "third-party
> > work"?
> >
> > licensed under terms that violate criterion #2
> > ("must
> > not place restrictions on the distribution of
> > independent works that simply use or contain the
> > covered work."), such as the GPL, requires
> > review and
> > explicit approval of both the PMC chair and the
> > Legal Affairs officer.
> >
> >
> I'm pretty sure that "that" refers to the
> third-party work, not the
> bridge code.
That's the way I've been reading it, but I can see
how it's possible to read it the other way as well.
> It wouldn't be logical for us to create
> bridge code that
> violates criterion #2.
I still don't like the wording of criterion #2,
especially when we equate use with dependence,
but I don't yet have anything to offer in the
way of replacement text.
> I would also assume that the
> bridge code in question would
> reside at Apache so it would be
> licensed under the Apache license.
That's certainly one of the things the legal
committee needs to have an answer for. If
that *is* the answer, then how do we
communicate the section 6 requirements to users?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion
#2?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>>> I don't like that prospect, personally, but
>>> if the ultimate
>>> answer is to make GPL dependencies verboten,
>>> I guess that's ok.
>>>
>>>
>>>
>> That is the major difference between the GPL and
>> LGPL. With the LGPL you can write bridge code,
>>
>
> But following the FSF's position, the conditions of
> section 6 are still being placed (indirectly) on
> the bridge code we write, so we need to be careful
> in how we represent the licensing on those bits.
>
>
That is absolutely correct.
>> with GPL you cannot. The only
>> way to really get
>> around that is if the API you are writing to came
>> first and was non-GPL
>> and then someone creates an implementation under a
>> GPL license. For
>> example, if JBoss AS was under GPL I doubt anyone
>> writing applications
>> that strictly conform to J2EE would care.
>>
>
> So lets return to the Subject of this thread,
> because it may turn out that I am misparsing
> what is written in the draft. Here's the
> excerpt in question:
>
> YOU MAY include code within the Apache product
> necessary to achieve compatibility with a prohibited
>
> work through the use of API calls, "bridge code", or
>
> protocols, provided that the compatibility code was
> contributed under a CLA. However, any such code used
>
> for compatibility with a third-party work that is
> ^^^^
> ^^
> Which noun does "that" refer to here? Does it refer
> to "such code" or does it refer to "third-party work"?
>
> licensed under terms that violate criterion #2
> ("must
> not place restrictions on the distribution of
> independent works that simply use or contain the
> covered work."), such as the GPL, requires review
> and
> explicit approval of both the PMC chair and the
> Legal
> Affairs officer.
>
>
I'm pretty sure that "that" refers to the third-party work, not the
bridge code. It wouldn't be logical for us to create bridge code that
violates criterion #2. I would also assume that the bridge code in
question would reside at Apache so it would be licensed under the Apache
license.
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Ralph Goers <Ra...@dslextreme.com> wrote:
>
> Joe Schaefer wrote:
> >
> >
> > Ah, it' not about finding loopholes Sam, it's
> > about
> > understanding the language in the current draft.
> > The draft talks about writing bridge code to
> > category
> > X works as something that is OK for our projects
> > to do. If they do write bridge code to GPL'd
> > works, then it sounds like there's going to be
> > an awful lot of GPL licensed software in our
> > repository if we accept the FSF's position.
Let me clarify that I don't wish for the ASF to
dispute the FSF's position, just to understand
the consequences of their interpretation so we
can communicate it more effectively in our policy.
If they consider constructing a process from files
as preparing a derivative work of those files, and
they believe that is not something which falls
under the exemptions written into the US law, then
at least we can reason about the consequences of
that position.
> > I don't like that prospect, personally, but
> > if the ultimate
> > answer is to make GPL dependencies verboten,
> > I guess that's ok.
> >
> >
> That is the major difference between the GPL and
> LGPL. With the LGPL you can write bridge code,
But following the FSF's position, the conditions of
section 6 are still being placed (indirectly) on
the bridge code we write, so we need to be careful
in how we represent the licensing on those bits.
> with GPL you cannot. The only
> way to really get
> around that is if the API you are writing to came
> first and was non-GPL
> and then someone creates an implementation under a
> GPL license. For
> example, if JBoss AS was under GPL I doubt anyone
> writing applications
> that strictly conform to J2EE would care.
So lets return to the Subject of this thread,
because it may turn out that I am misparsing
what is written in the draft. Here's the
excerpt in question:
YOU MAY include code within the Apache product
necessary to achieve compatibility with a prohibited
work through the use of API calls, "bridge code", or
protocols, provided that the compatibility code was
contributed under a CLA. However, any such code used
for compatibility with a third-party work that is
^^^^
^^
Which noun does "that" refer to here? Does it refer
to "such code" or does it refer to "third-party work"?
licensed under terms that violate criterion #2
("must
not place restrictions on the distribution of
independent works that simply use or contain the
covered work."), such as the GPL, requires review
and
explicit approval of both the PMC chair and the
Legal
Affairs officer.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion
#2?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>
>
> Ah, it' not about finding loopholes Sam, it's about
> understanding the language in the current draft.
> The draft talks about writing bridge code to category
> X works as something that is OK for our projects to
> do. If they do write brigde code to GPL'd works,
> then it sounds like there's going to be an awful lot
> of GPL licensed software in our repository if we
> accept the FSF's position. I don't like that
> prospect, personally, but if the ultimate
> answer is to make GPL dependencies verboten,
> I guess that's ok.
>
>
That is the major difference between the GPL and LGPL. With the LGPL you
can write bridge code, with GPL you cannot. The only way to really get
around that is if the API you are writing to came first and was non-GPL
and then someone creates an implementation under a GPL license. For
example, if JBoss AS was under GPL I doubt anyone writing applications
that strictly conform to J2EE would care.
Ralkph
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Mar 15, 2008 at 12:37 AM, Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
> > Whether or not their views of derived works will
> > hold up in a court of
> > law is something I'm sure the SFLC would love to
> > be able to test in
> > court. Again, I don't care - at the moment - for
> > Apache to be that
> > guinea pig. =) -- justin
>
> I want to echo that last statement more strongly.
> The ASF is all
> about voluntary contributions, and not about trying
> to find loopholes
> that let us make use of other people's property in
> ways that they
> don't wish for it to be used.
Ah, it' not about finding loopholes Sam, it's about
understanding the language in the current draft.
The draft talks about writing bridge code to category
X works as something that is OK for our projects to
do. If they do write brigde code to GPL'd works,
then it sounds like there's going to be an awful lot
of GPL licensed software in our repository if we
accept the FSF's position. I don't like that
prospect, personally, but if the ultimate
answer is to make GPL dependencies verboten,
I guess that's ok.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Mar 15, 2008 at 12:37 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Fri, Mar 14, 2008 at 7:52 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> > To me, that seems to say that copying the bits of a
> > file from the filesystem to into main memory isn't
> > infringing copyright, so I don't understand the FSF's
> > position here. Can anyone here enlighten me about it?
>
> FWIW, I pointed this thread out to folks from SFLC and they were
> boggled that there's even a question here as they fully intend that
> GPL applies to anything that uses it no matter the technique. They
> bristled at the word 'viral', but it's not an entirely off-base
> metaphor - if GPL enters the running code in any manner, the
> FSF/SFLC's position is that the entire program must be GPLed unless
> there is a written exception. Linux contains a written exception[1]
> permitting "user-space" programs to be non-GPLd - without that
> exception, FSF/SFLC's position would be that *all* code running under
> Linux would have to be released under the GPL. Note that this
> exception, as discussed before, doesn't apply to Linux kernel modules
> - hence their position is that all kernel modules must be GPL'd.
>
> Whether or not their views of derived works will hold up in a court of
> law is something I'm sure the SFLC would love to be able to test in
> court. Again, I don't care - at the moment - for Apache to be that
> guinea pig. =) -- justin
I want to echo that last statement more strongly. The ASF is all
about voluntary contributions, and not about trying to find loopholes
that let us make use of other people's property in ways that they
don't wish for it to be used.
Besides, even if we were to 'win', the net effect would be to increase
the burden on OUR licensees as those that wished to respect the FSF's
expresses wishes would have to be even more vigilant about reviewing
our products before they could make use of them.
I do *not* support the ASF pursuing this.
- 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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Mar 14, 2008 at 7:52 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> To me, that seems to say that copying the bits of a
> file from the filesystem to into main memory isn't
> infringing copyright, so I don't understand the FSF's
> position here. Can anyone here enlighten me about it?
FWIW, I pointed this thread out to folks from SFLC and they were
boggled that there's even a question here as they fully intend that
GPL applies to anything that uses it no matter the technique. They
bristled at the word 'viral', but it's not an entirely off-base
metaphor - if GPL enters the running code in any manner, the
FSF/SFLC's position is that the entire program must be GPLed unless
there is a written exception. Linux contains a written exception[1]
permitting "user-space" programs to be non-GPLd - without that
exception, FSF/SFLC's position would be that *all* code running under
Linux would have to be released under the GPL. Note that this
exception, as discussed before, doesn't apply to Linux kernel modules
- hence their position is that all kernel modules must be GPL'd.
Whether or not their views of derived works will hold up in a court of
law is something I'm sure the SFLC would love to be able to test in
court. Again, I don't care - at the moment - for Apache to be that
guinea pig. =) -- justin
1. From COPYING:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Joe Schaefer <jo...@yahoo.com> wrote:
>
> --- Robert Burrell Donkin <rd...@apache.org>
> wrote:
>
> > On Thu, 2008-03-13 at 10:07 -0700, Henri Yandell
> > wrote:
> >
> > <snip>
> >
> > > More important right now would be the issues of
> > > what the FSF's
> > > non-compiled/dynamic-linked stance is,
> >
> > +1
> >
> > even when we've disagreed with the FSF's
> > interpretation we've respect
> > the spirit and intention of their licenses (as
> > expressed by the FSF).
> > IMO this approach should be continued.
>
> I just dug this up:
>
>
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
>
> It directly conflicts with what I said about
> the situation for spamassassin. According
> to that url, if spamassassin acquired a GPL
> dependency, it would have to license everything
> under the GPL. (The FSF apparently believes
> copyright extends to actual processes, not
> just files on the filesystem).
FWIW, here's what the US Copyright Act says about
computer programs:
§ 117. Limitations on exclusive rights: Computer
programs
(a) Making of Additional Copy or Adaptation by Owner
of Copy. Notwithstanding the provisions of section
106, it is not an infringement for the owner of a
copy of a computer program to make or authorize the
making of another copy or adaptation of that
computer
program provided:
(1) that such a new copy or adaptation is created as
an essential step in the utilization of the computer
program in conjunction with a machine and that it is
used in no other manner, or
[...]
To me, that seems to say that copying the bits of a
file from the filesystem to into main memory isn't
infringing copyright, so I don't understand the FSF's
position here. Can anyone here enlighten me about it?
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Robert Burrell Donkin <rd...@apache.org> wrote:
> On Thu, 2008-03-13 at 10:07 -0700, Henri Yandell
> wrote:
>
> <snip>
>
> > More important right now would be the issues of
> what the FSF's
> > non-compiled/dynamic-linked stance is,
>
> +1
>
> even when we've disagreed with the FSF's
> interpretation we've respect
> the spirit and intention of their licenses (as
> expressed by the FSF).
> IMO this approach should be continued.
I just dug this up:
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
It directly conflicts with what I said about
the situation for spamassassin. According
to that url, if spamassassin acquired a GPL
dependency, it would have to license everything
under the GPL. (The FSF apparently believes
copyright extends to actual processes, not
just files on the filesystem).
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy
criterion #2?)
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Thu, 2008-03-13 at 10:07 -0700, Henri Yandell wrote:
<snip>
> More important right now would be the issues of what the FSF's
> non-compiled/dynamic-linked stance is,
+1
even when we've disagreed with the FSF's interpretation we've respect
the spirit and intention of their licenses (as expressed by the FSF).
IMO this approach should be continued.
- robert
Re: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Mar 13, 2008 at 3:37 PM, Henri Yandell <ba...@apache.org> wrote:
> On Thu, Mar 13, 2008 at 2:34 PM, Matthieu Riou <ma...@offthelip.org>
> wrote:
>
> >
> > Then I have a use case. Actually two. The Buildr podling is a Ruby
> project,
> > it's a Java build tool so it needs a Java runtime to compile and run
> tests
> > for example. Using the java and javac commands is too slow. So it's
> using
> > two different options:
> >
> > A module called RJB (Ruby Java Bridge) that relies on JNI and is LGPL
> > licensed.
> > JRuby which lets you pick your license: GPL, LGPL or CPL.
> > The way we've handled this for now is to consider 1) optional (as you
> can
> > rely on 2)) and 2) environmental, just like the ruby runtime is
> considered
> > environmental. Or the JDK itself for that matter. Note that we don't
> even
> > need to ship 1) because Ruby has its own package manager that takes care
> of
> > checking your dependencies and installing them for you.
> >
> > Now the questions would be:
> >
> > Is 1) really kosher? We don't ship anything and still it's optional but
> the
> > other options is CPL at best.
>
> Using our draft-policy, CPL is considered more acceptable than LGPL.
> If Option 2 is a problem, then our use of JUnit is a big problem and
> we've a lot of deleting to do. So I think JRuby usage is fine.
>
> The RJB option - it seems like another Hibernate type option. Could
> you add it to the OpenLegalQuestions page as another LGPL use case?
>
Done.
Thanks!
>
> > Could we ship a release already pre-bundled with JRuby, which contains
> both
> > binaries and scripts as source files?
>
> That would be an open question to add to the OpenLegalQuestions page.
> Good use case. It's blocked by needing to have the discussion on CPL
> source redistribution. Given the various other conversations -
> probably one to hold off right now.
>
> > We've also had some fun thinking whether monkey patching 2) could be
> > considered as modification of the original source. We've saved some
> brain
> > power by doing without monkey patching ;-)
>
> Yep, that would be a fun use case. I think it'd probably end up much
> like the CDDL binary question the other day - the intent is that our
> monkey patches are under the original license and we'd have to make
> sure we were happy with it for that use case.
>
> 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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Mar 13, 2008 at 2:34 PM, Matthieu Riou <ma...@offthelip.org> wrote:
>
> Then I have a use case. Actually two. The Buildr podling is a Ruby project,
> it's a Java build tool so it needs a Java runtime to compile and run tests
> for example. Using the java and javac commands is too slow. So it's using
> two different options:
>
> A module called RJB (Ruby Java Bridge) that relies on JNI and is LGPL
> licensed.
> JRuby which lets you pick your license: GPL, LGPL or CPL.
> The way we've handled this for now is to consider 1) optional (as you can
> rely on 2)) and 2) environmental, just like the ruby runtime is considered
> environmental. Or the JDK itself for that matter. Note that we don't even
> need to ship 1) because Ruby has its own package manager that takes care of
> checking your dependencies and installing them for you.
>
> Now the questions would be:
>
> Is 1) really kosher? We don't ship anything and still it's optional but the
> other options is CPL at best.
Using our draft-policy, CPL is considered more acceptable than LGPL.
If Option 2 is a problem, then our use of JUnit is a big problem and
we've a lot of deleting to do. So I think JRuby usage is fine.
The RJB option - it seems like another Hibernate type option. Could
you add it to the OpenLegalQuestions page as another LGPL use case?
> Could we ship a release already pre-bundled with JRuby, which contains both
> binaries and scripts as source files?
That would be an open question to add to the OpenLegalQuestions page.
Good use case. It's blocked by needing to have the discussion on CPL
source redistribution. Given the various other conversations -
probably one to hold off right now.
> We've also had some fun thinking whether monkey patching 2) could be
> considered as modification of the original source. We've saved some brain
> power by doing without monkey patching ;-)
Yep, that would be a fun use case. I think it'd probably end up much
like the CDDL binary question the other day - the intent is that our
monkey patches are under the original license and we'd have to make
sure we were happy with it for that use case.
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Mar 13, 2008 at 10:07 AM, Henri Yandell <ba...@apache.org> wrote:
> On Thu, Mar 13, 2008 at 7:41 AM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> >
> > On Wed, Mar 12, 2008 at 8:13 PM, Joe Schaefer <jo...@yahoo.com>
> > wrote:
> >
> >
> > >
> > >
> > > --- Joe Schaefer <jo...@yahoo.com> wrote:
> > >
> > >
> > > > Because I'm trying to give you folks the perspective
> > > > of a perl hacker on licensing. We don't ever have
> > > > these lofty debates on module licensing, because we
> > > > let perl do all the actual binding for us.
> > >
> > > Let me say some more words about the situation for
> > > perl, because I think it will reinforce Sam's point
> > > that no algorithic approach will work out fairly
> > > for everyone at the ASF.
> > >
> > > Spamassassin is an ASF project that some closed source
> > >
> > > providers base their work on. Spamassassin also
> > > depends on lots of 3rd party perl modules. Were one
> > > of those modules ever to be relicensed under the GPL,
> > > it is my opinion that no material impact would happen
> > > to the spamassassin community if they kept right on
> > > using it. The reason I say that is that in perl,
> > > module boundaries are generally license boundaries,
> > > because the modules themselves are independent works.
> > > Use of such modules, in the sense of writing
> > > compatibility code, does not constitute producing
> > > derivative works of them. All a closed source
> > > provider
> > > would have to do is honor the terms on the GPL module,
> > > and they could continue producing closed source
> > > solutions based on spamassassin.
> > >
> > > Were the policy to forbid spamassassin from using
> > > 3rd party GPL'd modules, it would only be for the
> > > reason that we trying to protect the brand, IMO.
> > > It would not serve the actual spamassassin
> > > community in the least if they had to reimplement
> > > the module themselves.
> >
> > FWIW this observation also applies to most dynamic languages. I can
> write
> > Ruby code using a given library just by looking at the documentation and
> > never even touch the library code until runtime. Because of duck typing
> the
> > used library can be switched at anytime (even runtime). So I'd be
> interested
> > in knowing what the FSF would call "linking" in that case.
>
> Somewhat agreed.
>
> You could improve the algorithm approach to cover these; talk about
> compiling vs not compiling, but I'm in agreement that the algorithm
> should not be policy - personally I think it should be legal-pmc
> guideline and built up by a case history.
>
> More important right now would be the issues of what the FSF's
> non-compiled/dynamic-linked stance is, and what our policy is with
> regards to what you call the Apache brand. Should people downloading
> an Apache project expect it to be largely permissive, by that
> finger-in-the-air determination of whether a product is/contains GPL,
> or just works on top of GPL.
>
> There are GPL modules in Perl and Ruby land, so I'm sure the subject
> will come up on here at some point with an actual use case.
>
Then I have a use case. Actually two. The Buildr podling is a Ruby project,
it's a Java build tool so it needs a Java runtime to compile and run tests
for example. Using the java and javac commands is too slow. So it's using
two different options:
1. A module called RJB (Ruby Java Bridge) that relies on JNI and is
LGPL licensed.
2. JRuby which lets you pick your license: GPL, LGPL or CPL.
The way we've handled this for now is to consider 1) optional (as you can
rely on 2)) and 2) environmental, just like the ruby runtime is considered
environmental. Or the JDK itself for that matter. Note that we don't even
need to ship 1) because Ruby has its own package manager that takes care of
checking your dependencies and installing them for you.
Now the questions would be:
- Is 1) really kosher? We don't ship anything and still it's optional
but the other options is CPL at best.
- Could we ship a release already pre-bundled with JRuby, which
contains both binaries and scripts as source files?
We've also had some fun thinking whether monkey patching 2) could be
considered as modification of the original source. We've saved some brain
power by doing without monkey patching ;-)
Cheers,
Matthieu
> 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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Mar 13, 2008 at 7:41 AM, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Wed, Mar 12, 2008 at 8:13 PM, Joe Schaefer <jo...@yahoo.com>
> wrote:
>
>
> >
> >
> > --- Joe Schaefer <jo...@yahoo.com> wrote:
> >
> >
> > > Because I'm trying to give you folks the perspective
> > > of a perl hacker on licensing. We don't ever have
> > > these lofty debates on module licensing, because we
> > > let perl do all the actual binding for us.
> >
> > Let me say some more words about the situation for
> > perl, because I think it will reinforce Sam's point
> > that no algorithic approach will work out fairly
> > for everyone at the ASF.
> >
> > Spamassassin is an ASF project that some closed source
> >
> > providers base their work on. Spamassassin also
> > depends on lots of 3rd party perl modules. Were one
> > of those modules ever to be relicensed under the GPL,
> > it is my opinion that no material impact would happen
> > to the spamassassin community if they kept right on
> > using it. The reason I say that is that in perl,
> > module boundaries are generally license boundaries,
> > because the modules themselves are independent works.
> > Use of such modules, in the sense of writing
> > compatibility code, does not constitute producing
> > derivative works of them. All a closed source
> > provider
> > would have to do is honor the terms on the GPL module,
> > and they could continue producing closed source
> > solutions based on spamassassin.
> >
> > Were the policy to forbid spamassassin from using
> > 3rd party GPL'd modules, it would only be for the
> > reason that we trying to protect the brand, IMO.
> > It would not serve the actual spamassassin
> > community in the least if they had to reimplement
> > the module themselves.
>
> FWIW this observation also applies to most dynamic languages. I can write
> Ruby code using a given library just by looking at the documentation and
> never even touch the library code until runtime. Because of duck typing the
> used library can be switched at anytime (even runtime). So I'd be interested
> in knowing what the FSF would call "linking" in that case.
Somewhat agreed.
You could improve the algorithm approach to cover these; talk about
compiling vs not compiling, but I'm in agreement that the algorithm
should not be policy - personally I think it should be legal-pmc
guideline and built up by a case history.
More important right now would be the issues of what the FSF's
non-compiled/dynamic-linked stance is, and what our policy is with
regards to what you call the Apache brand. Should people downloading
an Apache project expect it to be largely permissive, by that
finger-in-the-air determination of whether a product is/contains GPL,
or just works on top of GPL.
There are GPL modules in Perl and Ruby land, so I'm sure the subject
will come up on here at some point with an actual use case.
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Mar 12, 2008 at 8:13 PM, Joe Schaefer <jo...@yahoo.com>
wrote:
>
> --- Joe Schaefer <jo...@yahoo.com> wrote:
>
>
> > Because I'm trying to give you folks the perspective
> > of a perl hacker on licensing. We don't ever have
> > these lofty debates on module licensing, because we
> > let perl do all the actual binding for us.
>
> Let me say some more words about the situation for
> perl, because I think it will reinforce Sam's point
> that no algorithic approach will work out fairly
> for everyone at the ASF.
>
> Spamassassin is an ASF project that some closed source
>
> providers base their work on. Spamassassin also
> depends on lots of 3rd party perl modules. Were one
> of those modules ever to be relicensed under the GPL,
> it is my opinion that no material impact would happen
> to the spamassassin community if they kept right on
> using it. The reason I say that is that in perl,
> module boundaries are generally license boundaries,
> because the modules themselves are independent works.
> Use of such modules, in the sense of writing
> compatibility code, does not constitute producing
> derivative works of them. All a closed source
> provider
> would have to do is honor the terms on the GPL module,
> and they could continue producing closed source
> solutions based on spamassassin.
>
> Were the policy to forbid spamassassin from using
> 3rd party GPL'd modules, it would only be for the
> reason that we trying to protect the brand, IMO.
> It would not serve the actual spamassassin
> community in the least if they had to reimplement
> the module themselves.
>
>
FWIW this observation also applies to most dynamic languages. I can write
Ruby code using a given library just by looking at the documentation and
never even touch the library code until runtime. Because of duck typing the
used library can be switched at anytime (even runtime). So I'd be interested
in knowing what the FSF would call "linking" in that case.
Cheers,
Matthieu
>
>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
> ---------------------------------------------------------------------
> 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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Joe Schaefer <jo...@yahoo.com> wrote:
> Because I'm trying to give you folks the perspective
> of a perl hacker on licensing. We don't ever have
> these lofty debates on module licensing, because we
> let perl do all the actual binding for us.
Let me say some more words about the situation for
perl, because I think it will reinforce Sam's point
that no algorithic approach will work out fairly
for everyone at the ASF.
Spamassassin is an ASF project that some closed source
providers base their work on. Spamassassin also
depends on lots of 3rd party perl modules. Were one
of those modules ever to be relicensed under the GPL,
it is my opinion that no material impact would happen
to the spamassassin community if they kept right on
using it. The reason I say that is that in perl,
module boundaries are generally license boundaries,
because the modules themselves are independent works.
Use of such modules, in the sense of writing
compatibility code, does not constitute producing
derivative works of them. All a closed source
provider
would have to do is honor the terms on the GPL module,
and they could continue producing closed source
solutions based on spamassassin.
Were the policy to forbid spamassassin from using
3rd party GPL'd modules, it would only be for the
reason that we trying to protect the brand, IMO.
It would not serve the actual spamassassin
community in the least if they had to reimplement
the module themselves.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Ralph Goers <Ra...@dslextreme.com> wrote:
> I'm having trouble understanding why you keep
> replying with your own
> opinion to everyone that gives a response you don't
> like.
Because I'm trying to give you folks the perspective
of a perl hacker on licensing. We don't ever have
these lofty debates on module licensing, because we
let perl do all the actual binding for us. To
the extent that java works like perl does, I can
understand the perspective of Hibernate rather well.
To the extent that it doesn't, I can see the FSF's
position as a rational one.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
---------------------------------------------------------------------
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: fair use (was Re: What licenses in category X satisfy criterion
#2?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joe Schaefer wrote:
>
>> that depends on what you mean by derivative work :-)
>>
>> AIUI the GPL 2.0 includes a redefinition of the
>> term. if you accept the
>> license, the FSF claims that you agree to play by
>> their rules. this
>> linking scenario is definitely what the FSF had in
>> mind when they drew
>> up the GPL and (in the past) they have been
>> aggressive in enforcing
>> these provisions.
>>
>
> But I did not say "linking", which is a relationship
> between two binary files, I said "using". In C,
> there is a concept known as loadable modules. It
> is my opinion that a closed source distributor of
> loadable modules for httpd may package some GPL'd
> modules into their distribution, and as long as
> they honor the terms of the GPL on those modules,
> they need not do so on the others. Even if those
> other proprietary modules make optional calls into
> the GPL modules' interfaces.
>
>
I'm having trouble understanding why you keep replying with your own
opinion to everyone that gives a response you don't like. I sent you the
link to the FSF page where they explicitly state that they see no
difference between C and Java when it comes to linking. Here it is
again. http://www.fsf.org/licensing/licenses/lgpl-java.html.
How much more explicit could this be? "When the application is compiled,
function signatures are checked against the library, creating a link."
Now you can choose to believe that this is a bunch of hooey. I choose to
believe that if you don't adhere to this they are going to sue you.
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: fair use (was Re: What licenses in category X satisfy criterion #2?)
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Robert Burrell Donkin <rd...@apache.org> wrote:
>
> On Wed, 2008-03-05 at 07:37 -0800, Joe Schaefer
> wrote:
> > --- Ralph Goers <Ra...@dslextreme.com>
> wrote:
> >
> > > Criteria #2 refers to licenses like the GPL
> > > which says in part
> > >
> > > > The "Program", below,
> > > > refers to any such program or work, and a
> > > > "work based on the Program"
> > > > means either the Program or any derivative
> > > > work under copyright law:
> > > > that is to say, a work containing the Program
> > > > or a portion of it,
> > > > either verbatim or with modifications and/or
> > > > translated into another
> > > > language.
> >
> > > So any program which uses a library licensed
> > > under the GPL must also be
> > > licensed under the GPL as they would be
> > > considered to be derivative
> > > works.
> >
> > I will repeat my statement that a license
> > is not the arbiter of what is or is not a
> > derivative work. The question to me is
> > whether or not writing
> > some glue code to interface with some 3rd party
> > GPL'd code qualifies as fair use, and is therefore
> > not considered by the courts as a derivative work.
>
> that depends on what you mean by derivative work :-)
>
> AIUI the GPL 2.0 includes a redefinition of the
> term. if you accept the
> license, the FSF claims that you agree to play by
> their rules. this
> linking scenario is definitely what the FSF had in
> mind when they drew
> up the GPL and (in the past) they have been
> aggressive in enforcing
> these provisions.
But I did not say "linking", which is a relationship
between two binary files, I said "using". In C,
there is a concept known as loadable modules. It
is my opinion that a closed source distributor of
loadable modules for httpd may package some GPL'd
modules into their distribution, and as long as
they honor the terms of the GPL on those modules,
they need not do so on the others. Even if those
other proprietary modules make optional calls into
the GPL modules' interfaces.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
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