You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Leo Simons <ma...@leosimons.com> on 2005/05/14 10:57:49 UTC
Questions about the Classpath license exception
Hi classpath developers!
(Harmony people: replies only on the classpath mailing list please, this has
in reality only little to do with harmony.)
"Oh no, not all that licensing crap again!"
As part of the ongoing investigation whether the new Apache Harmony project
can legally use GNU Classpath and what the licensing implications of that
should be, one of Apache's resident license experts inlined some comments
into the classpath exception wording:
Linking this library (scope?) statically or dynamically with
other modules (define?) is making a combined work based on this
library. Thus, the terms and conditions of the GNU General
Public License cover the whole combination. (I.e., this work
and anything you combine with it cannot be copied, redistributed,
or made into derivative works except under the terms of the GPL).
As a special exception (on what?), the copyright holders (who?)
of this library (encompassing what?) give you permission to
link (how?) this (what?) library with independent modules (defined
later) to produce an executable (what's that?), regardless of
the license terms of these independent modules (license as
received or license for redistribution?), and to copy and
distribute (a small fraction of the rights under copyright law,
not to mention patents) the resulting executable (but what about
the source libraries?) under terms of your choice, provided that
you also meet, for each linked independent module, the terms and
conditions of the license of that module. An independent module
is a module which is not derived from or based on (define?) this
library. If you modify this library, you may extend this exception
to your version of the library, but you are not obligated to do so.
If you do not wish to do so, delete this exception statement from
your version (which is the same as dual-licensing with GPL).
That's a lot of comments and question marks! The gist of this is that the
combination of GPL + this exception has many legal holes at a glance. From
what I understand (not a lot, IANAL), that is because various things in the
statement are not fully defined.
The first thing we would like to do is get rid of all those question marks.
It's probably not productive to go through all of them. One suggestion I'd
like to pass on is that you guys write up a list of the goals to be achieved
with the GPL+exception construct (ideally in the form of a web page, since
links are easy to pass around :-)) and some of the ASF people take a look at
that and take a stab at a proposal for a different kind of wording which
would be deemed to be compatible with those goals, Apache's goals with
Harmony, and the Apache License, if that's possible. We can then make the
three texts (the classpath exception, the goals to be achieved with the
exception, an alternative proposal) subject of a discussion, perhaps via
concall.
Sound like a plan? Mark, I think you've got my cell if you want a
high-bandwidth chat :-)
Cheers,
Leo
Re: Questions about the Classpath license exception
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 14, 2005, at 7:39 PM, Davanum Srinivas wrote:
> Leo
> We can use the con call next week as the forum.
>
Yes please - we have an ongoing conversation with the FSF on
licensing issues, and we can just add this to the list.
> Folks,
> Just to summarize *Ideally* what we would like, here's a list:
>
> - We don't want to modify any classpath code. If we need changes, we
> can work with classpath folks.
Yes. Or "We will not modify classpath code here..."
(And I'll add that any donation I solicit will be of the sort that
GNU Classpath could use it if they so chose.)
> - We don't want to add classpath sources to our tree. this will avoid
> local changes.
"We will not add classpath code... " :)
> - We want to add classpath jar snapshots to our CVS/SVN (preferable).
I don't. I'd rather stay away from that and just use maven snapshots
for now. Keeps us away from more license issues, and gets rid of the
a) maintenance overhead and b) size of update when going over slow
pipes.
> - We want to add classpath jar to our installer to distribute a
> working JVM/JRE in a single download.
We will certainly need to add the class library jar, and I'm not
trying to make anyone angry here, but it's *way* too early to know
what that will be.
> - We want to enable a commercial product to be able to sublicense the
> complete JVM/JRE.
Yes
geir
>
> Thanks,
> dims
>
> On 5/14/05, Leo Simons <ma...@leosimons.com> wrote:
>
>> Hi classpath developers!
>>
>> (Harmony people: replies only on the classpath mailing list
>> please, this has
>> in reality only little to do with harmony.)
>>
>> "Oh no, not all that licensing crap again!"
>>
>> As part of the ongoing investigation whether the new Apache
>> Harmony project
>> can legally use GNU Classpath and what the licensing implications
>> of that
>> should be, one of Apache's resident license experts inlined some
>> comments
>> into the classpath exception wording:
>>
>> Linking this library (scope?) statically or dynamically with
>> other modules (define?) is making a combined work based on this
>> library. Thus, the terms and conditions of the GNU General
>> Public License cover the whole combination. (I.e., this work
>> and anything you combine with it cannot be copied, redistributed,
>> or made into derivative works except under the terms of the GPL).
>>
>> As a special exception (on what?), the copyright holders (who?)
>> of this library (encompassing what?) give you permission to
>> link (how?) this (what?) library with independent modules (defined
>> later) to produce an executable (what's that?), regardless of
>> the license terms of these independent modules (license as
>> received or license for redistribution?), and to copy and
>> distribute (a small fraction of the rights under copyright law,
>> not to mention patents) the resulting executable (but what about
>> the source libraries?) under terms of your choice, provided that
>> you also meet, for each linked independent module, the terms and
>> conditions of the license of that module. An independent module
>> is a module which is not derived from or based on (define?) this
>> library. If you modify this library, you may extend this exception
>> to your version of the library, but you are not obligated to do
>> so.
>> If you do not wish to do so, delete this exception statement from
>> your version (which is the same as dual-licensing with GPL).
>>
>> That's a lot of comments and question marks! The gist of this is
>> that the
>> combination of GPL + this exception has many legal holes at a
>> glance. From
>> what I understand (not a lot, IANAL), that is because various
>> things in the
>> statement are not fully defined.
>>
>> The first thing we would like to do is get rid of all those
>> question marks.
>> It's probably not productive to go through all of them. One
>> suggestion I'd
>> like to pass on is that you guys write up a list of the goals to
>> be achieved
>> with the GPL+exception construct (ideally in the form of a web
>> page, since
>> links are easy to pass around :-)) and some of the ASF people take
>> a look at
>> that and take a stab at a proposal for a different kind of wording
>> which
>> would be deemed to be compatible with those goals, Apache's goals
>> with
>> Harmony, and the Apache License, if that's possible. We can then
>> make the
>> three texts (the classpath exception, the goals to be achieved
>> with the
>> exception, an alternative proposal) subject of a discussion,
>> perhaps via
>> concall.
>>
>> Sound like a plan? Mark, I think you've got my cell if you want a
>> high-bandwidth chat :-)
>>
>> Cheers,
>>
>> Leo
>>
>>
>>
>>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Questions about the Classpath license exception
Posted by ac...@apache.org.
I agree with what you mean but don't like your wording. I may
personally love to help fix the occassional nit in classpath if its in
the way of harmony and will very cooperatively contribute it to
classpath. If I don't feel qualified to do it or thing others may be
better suited I'll kindly send them useful information about the problem
I'm experiencing and if possible help solve it. however that is best
done directly in the context of the classpath project itself,
maintaining its integrity! :-)
-andy
Davanum Srinivas wrote:
> Leo
> We can use the con call next week as the forum.
>
> Folks,
> Just to summarize *Ideally* what we would like, here's a list:
>
> - We don't want to modify any classpath code. If we need changes, we
> can work with classpath folks.
> - We don't want to add classpath sources to our tree. this will avoid
> local changes.
> - We want to add classpath jar snapshots to our CVS/SVN (preferable).
> - We want to add classpath jar to our installer to distribute a
> working JVM/JRE in a single download.
> - We want to enable a commercial product to be able to sublicense the
> complete JVM/JRE.
>
> Thanks,
> dims
>
> On 5/14/05, Leo Simons <ma...@leosimons.com> wrote:
>
>>Hi classpath developers!
>>
>>(Harmony people: replies only on the classpath mailing list please, this has
>>in reality only little to do with harmony.)
>>
>>"Oh no, not all that licensing crap again!"
>>
>>As part of the ongoing investigation whether the new Apache Harmony project
>>can legally use GNU Classpath and what the licensing implications of that
>>should be, one of Apache's resident license experts inlined some comments
>>into the classpath exception wording:
>>
>> Linking this library (scope?) statically or dynamically with
>> other modules (define?) is making a combined work based on this
>> library. Thus, the terms and conditions of the GNU General
>> Public License cover the whole combination. (I.e., this work
>> and anything you combine with it cannot be copied, redistributed,
>> or made into derivative works except under the terms of the GPL).
>>
>> As a special exception (on what?), the copyright holders (who?)
>> of this library (encompassing what?) give you permission to
>> link (how?) this (what?) library with independent modules (defined
>> later) to produce an executable (what's that?), regardless of
>> the license terms of these independent modules (license as
>> received or license for redistribution?), and to copy and
>> distribute (a small fraction of the rights under copyright law,
>> not to mention patents) the resulting executable (but what about
>> the source libraries?) under terms of your choice, provided that
>> you also meet, for each linked independent module, the terms and
>> conditions of the license of that module. An independent module
>> is a module which is not derived from or based on (define?) this
>> library. If you modify this library, you may extend this exception
>> to your version of the library, but you are not obligated to do so.
>> If you do not wish to do so, delete this exception statement from
>> your version (which is the same as dual-licensing with GPL).
>>
>>That's a lot of comments and question marks! The gist of this is that the
>>combination of GPL + this exception has many legal holes at a glance. From
>>what I understand (not a lot, IANAL), that is because various things in the
>>statement are not fully defined.
>>
>>The first thing we would like to do is get rid of all those question marks.
>>It's probably not productive to go through all of them. One suggestion I'd
>>like to pass on is that you guys write up a list of the goals to be achieved
>>with the GPL+exception construct (ideally in the form of a web page, since
>>links are easy to pass around :-)) and some of the ASF people take a look at
>>that and take a stab at a proposal for a different kind of wording which
>>would be deemed to be compatible with those goals, Apache's goals with
>>Harmony, and the Apache License, if that's possible. We can then make the
>>three texts (the classpath exception, the goals to be achieved with the
>>exception, an alternative proposal) subject of a discussion, perhaps via
>>concall.
>>
>>Sound like a plan? Mark, I think you've got my cell if you want a
>>high-bandwidth chat :-)
>>
>>Cheers,
>>
>>Leo
>>
>>
>>
>
>
>
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
Re: Questions about the Classpath license exception
Posted by FaeLLe <mr...@gmail.com>.
On 5/15/05, Mark Brooks <jm...@hotmail.com> wrote:
>
> >To be clear, so as no-one feels they've been misled in the future, this
> is
> >not what we'd like in the best of all possible worlds. In that world,
> >classpath would be relicensed under the AL, or a compatible licence.
> >
> >What's listed above is a position we can live with.
> >
> >Cheers,
> >
> >Ben.
>
> Respectfully, perhaps the mistake is not going ahead and developing a
> class
> library specifically for this project.
The work load involved is too mammoth and we would be in a running race to
stay at par......
I realize that is a lot of work, but perhaps it would be better to do that
> work than to use code from another project that has different aims and
> goals
> and an incompatible license.
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on how to
> get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Questions about the Classpath license exception
Posted by Sven de Marothy <sv...@physto.se>.
On Sun, 2005-05-15 at 12:59 -0400, Mark Brooks wrote:
> Respectfully, perhaps the mistake is not going ahead and developing a class
> library specifically for this project.
>
> I realize that is a lot of work, but perhaps it would be better to do that
> work than to use code from another project that has different aims and goals
> and an incompatible license.
If you're going to propsose something like this, you need to motivate
the 'why' better. Tell me, which aims and goals are different?
We aim to implement J2SE 5. We aim for TCK compatibility (which is why
Dalbor is in the process of getting TCK access). Classpath does however
not aim for a complete stack. That is beyond the scope of a class
library.
Noone (including Leo) has said the license is incompatible. The
objections raised so far have concerned the wording. The Classpath folks
have been aware of these problems. This is something which is being
worked on to fix.
Supposedly, the Harmony project is about *harmonizing* the efforts of
the existing Free Java community and Apache.
/Sven
Re: Questions about the Classpath license exception
Posted by Stefano Mazzocchi <st...@apache.org>.
acoliver@apache.org wrote:
> That's a bit knee jerk. Far more value could be found from working
> together. We have more in common than not. If we learn to compromise
> and work together, the gains will be tremendous. Seperately we're all a
> bunch of qubbling groups who produce pieces of Java that are interesting
> and maybe even useful, but are not really as much of a force to be
> reckoned with.
>
> While the Free Software Foundation and its allies have produced
> tremendous works, the Apache Software Foundation has made the greatest
> progress in freeing Java. This was done through persistence and
> compromise often over the objections of hard-headed people like me who
> like to knee-jerk too.
>
> The Free Software Foundation is the force which allows us to have Linux
> or Gnu/Linux today among many others. Apache gave us the Apache Web
> Server and countless other libraries. The FSF gives us GCJ, Apache
> gives us countless Java libraries, frameworks and toolkits that are
> developed in line with our shared ethos.
>
> However, we do these things apart and do our own part to negotiate for
> the freedom of Java. Its time to take a much larger step and work
> together, find commonality and keep cool heads.
>
> Calls to give up and go our own way are frankly unhelpful and very
> early. A free and open Java is at our grasp through combined talent.
>
> Personally, I have temendous respect for the abillities and talents of
> both groups and look forward to them working together to produce a free
> high performance production-ready Java.
Amen.
We are more similar than we are different. Let's respect the differences
as cultural values, but let's walk together toward the common goal.
--
Stefano.
Re: Questions about the Classpath license exception
Posted by ac...@apache.org.
That's a bit knee jerk. Far more value could be found from working
together. We have more in common than not. If we learn to compromise
and work together, the gains will be tremendous. Seperately we're all a
bunch of qubbling groups who produce pieces of Java that are interesting
and maybe even useful, but are not really as much of a force to be
reckoned with.
While the Free Software Foundation and its allies have produced
tremendous works, the Apache Software Foundation has made the greatest
progress in freeing Java. This was done through persistence and
compromise often over the objections of hard-headed people like me who
like to knee-jerk too.
The Free Software Foundation is the force which allows us to have Linux
or Gnu/Linux today among many others. Apache gave us the Apache Web
Server and countless other libraries. The FSF gives us GCJ, Apache
gives us countless Java libraries, frameworks and toolkits that are
developed in line with our shared ethos.
However, we do these things apart and do our own part to negotiate for
the freedom of Java. Its time to take a much larger step and work
together, find commonality and keep cool heads.
Calls to give up and go our own way are frankly unhelpful and very
early. A free and open Java is at our grasp through combined talent.
Personally, I have temendous respect for the abillities and talents of
both groups and look forward to them working together to produce a free
high performance production-ready Java.
-Andy
Mark Brooks wrote:
>> To be clear, so as no-one feels they've been misled in the future,
>> this is not what we'd like in the best of all possible worlds. In that
>> world, classpath would be relicensed under the AL, or a compatible
>> licence.
>>
>> What's listed above is a position we can live with.
>>
>> Cheers,
>>
>> Ben.
>
>
> Respectfully, perhaps the mistake is not going ahead and developing a
> class library specifically for this project.
>
> I realize that is a lot of work, but perhaps it would be better to do
> that work than to use code from another project that has different aims
> and goals and an incompatible license.
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on how
> to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
Re: Questions about the Classpath license exception
Posted by Mark Brooks <jm...@hotmail.com>.
>To be clear, so as no-one feels they've been misled in the future, this is
>not what we'd like in the best of all possible worlds. In that world,
>classpath would be relicensed under the AL, or a compatible licence.
>
>What's listed above is a position we can live with.
>
>Cheers,
>
>Ben.
Respectfully, perhaps the mistake is not going ahead and developing a class
library specifically for this project.
I realize that is a lot of work, but perhaps it would be better to do that
work than to use code from another project that has different aims and goals
and an incompatible license.
_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
Re: Questions about the Classpath license exception
Posted by Ben Laurie <be...@algroup.co.uk>.
Davanum Srinivas wrote:
> Leo
> We can use the con call next week as the forum.
>
> Folks,
> Just to summarize *Ideally* what we would like, here's a list:
>
> - We don't want to modify any classpath code. If we need changes, we
> can work with classpath folks.
> - We don't want to add classpath sources to our tree. this will avoid
> local changes.
> - We want to add classpath jar snapshots to our CVS/SVN (preferable).
> - We want to add classpath jar to our installer to distribute a
> working JVM/JRE in a single download.
> - We want to enable a commercial product to be able to sublicense the
> complete JVM/JRE.
To be clear, so as no-one feels they've been misled in the future, this
is not what we'd like in the best of all possible worlds. In that world,
classpath would be relicensed under the AL, or a compatible licence.
What's listed above is a position we can live with.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Questions about the Classpath license exception
Posted by Leo Simons <ma...@leosimons.com>.
> On 5/14/05, Leo Simons <ma...@leosimons.com> wrote:
>> (Harmony people: replies only on the classpath mailing list please, this has
>> in reality only little to do with harmony.)
I really hate crossposts. Oh well.
On 15-05-2005 01:39, "Davanum Srinivas" <da...@gmail.com> wrote:
> We can use the con call next week as the forum.
I doubt that's going to be very productive. I want stuff on paper (well,
written words) to e-mail to various people and get feedback on. Otherwise we
get stuck in vagueness.
> Just to summarize *Ideally* what we would like, here's a list:
I think that's not an exhaustive list. I'm a bit afraid of bulleted lists
like this since they're somewhat simplifying complex stuff. I think we would
like (quoting myself)
"a different kind of wording [of the GPL+Exception statements] which is
compatible with [the goals of the classpath people], Apache's goals with
Harmony, and the Apache License"
"Apache's goals with harmony" is something like "creating a J2SE
implementation which is effectively under about the same set of rules as
those spelled out in the Apache License". IIUC (IANAL!) that means that the
classpath code has to be under a license that is "less restrictive" or "just
as restrictive" as the apache license, but not "more restrictive". However,
there's some "wiggle room" where Apache might want to "swallow" some of
those goals in the interest of cooperation.
But before we can start discussing any of that...
> On 5/14/05, Leo Simons <ma...@leosimons.com> wrote:
>> The first thing we would like to do is get rid of all those question marks.
>> It's probably not productive to go through all of them. One suggestion I'd
>> like to pass on is that you guys write up a list of the goals to be achieved
>> with the GPL+exception construct. (...)
I somewhat doubt that the goal with classpath licensing is simply "be
compatible with the GPL, be compatible with the AL, be compatible with the
MPL", since that's then a really short and simple license (MIT license would
do for example).
Now, I think we're all reasonably clear on what the goals of the GPL are
(redistribution-oriented copyleft, blah blah) and that's pretty
well-documented elsewhere, so for starters we "just" need a delta between
the license goals of the GPL and the license goals for classpath. Without
all those question marks :-)
Cheers!
Leo
Re: Questions about the Classpath license exception
Posted by Davanum Srinivas <da...@gmail.com>.
Leo
We can use the con call next week as the forum.
Folks,
Just to summarize *Ideally* what we would like, here's a list:
- We don't want to modify any classpath code. If we need changes, we
can work with classpath folks.
- We don't want to add classpath sources to our tree. this will avoid
local changes.
- We want to add classpath jar snapshots to our CVS/SVN (preferable).
- We want to add classpath jar to our installer to distribute a
working JVM/JRE in a single download.
- We want to enable a commercial product to be able to sublicense the
complete JVM/JRE.
Thanks,
dims
On 5/14/05, Leo Simons <ma...@leosimons.com> wrote:
> Hi classpath developers!
>
> (Harmony people: replies only on the classpath mailing list please, this has
> in reality only little to do with harmony.)
>
> "Oh no, not all that licensing crap again!"
>
> As part of the ongoing investigation whether the new Apache Harmony project
> can legally use GNU Classpath and what the licensing implications of that
> should be, one of Apache's resident license experts inlined some comments
> into the classpath exception wording:
>
> Linking this library (scope?) statically or dynamically with
> other modules (define?) is making a combined work based on this
> library. Thus, the terms and conditions of the GNU General
> Public License cover the whole combination. (I.e., this work
> and anything you combine with it cannot be copied, redistributed,
> or made into derivative works except under the terms of the GPL).
>
> As a special exception (on what?), the copyright holders (who?)
> of this library (encompassing what?) give you permission to
> link (how?) this (what?) library with independent modules (defined
> later) to produce an executable (what's that?), regardless of
> the license terms of these independent modules (license as
> received or license for redistribution?), and to copy and
> distribute (a small fraction of the rights under copyright law,
> not to mention patents) the resulting executable (but what about
> the source libraries?) under terms of your choice, provided that
> you also meet, for each linked independent module, the terms and
> conditions of the license of that module. An independent module
> is a module which is not derived from or based on (define?) this
> library. If you modify this library, you may extend this exception
> to your version of the library, but you are not obligated to do so.
> If you do not wish to do so, delete this exception statement from
> your version (which is the same as dual-licensing with GPL).
>
> That's a lot of comments and question marks! The gist of this is that the
> combination of GPL + this exception has many legal holes at a glance. From
> what I understand (not a lot, IANAL), that is because various things in the
> statement are not fully defined.
>
> The first thing we would like to do is get rid of all those question marks.
> It's probably not productive to go through all of them. One suggestion I'd
> like to pass on is that you guys write up a list of the goals to be achieved
> with the GPL+exception construct (ideally in the form of a web page, since
> links are easy to pass around :-)) and some of the ASF people take a look at
> that and take a stab at a proposal for a different kind of wording which
> would be deemed to be compatible with those goals, Apache's goals with
> Harmony, and the Apache License, if that's possible. We can then make the
> three texts (the classpath exception, the goals to be achieved with the
> exception, an alternative proposal) subject of a discussion, perhaps via
> concall.
>
> Sound like a plan? Mark, I think you've got my cell if you want a
> high-bandwidth chat :-)
>
> Cheers,
>
> Leo
>
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/