You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Wielaard <ma...@klomp.org> on 2005/05/07 05:31:27 UTC
Re: Harmony: project purpose
Hi,
On Fri, 2005-05-06 at 22:34 -0400, Davanum Srinivas wrote:
> People working on Kaffe/Classpath are gonna advise us..see their names
> on the proposal :) We (Apache Gump team) has been working with them
> to make Kaffe/Classpath better for a while now
> (http://brutus.apache.org/gump/kaffe/buildLog.html). Harmony is going
> to increase synergies. We are working in parallel with FSF folks on
> the licensing issues as well for while now. Please see the FAQ as
> well. we are gonna leverage every bit of code and expertise that we
> can to make this happen.
As GNU Classpath maintainer I must admit that I am not 100% happy with
how the announcement came out. I had hoped it would have more emphasized
the fact that we would do everything in our power to work out the
philosophical, legal and practical issues when reusing existing code for
Harmony.
I do however acknowledge that some of the reluctance comes from my side.
I explicitly said that I would not contribute to any Apache licensed
project as long as code distributed under the (L)GPL and ASL couldn't be
mixed into a larger work. That is why there are actually multiple lists
of "interested individuals", some people don't want to contribute to a
new code base that isn't acceptable to both the GNU and the Apache
community. But those people, like me, might still be interested in the
technical discussions around such a new code base (even though the
duplicated effort hurts to even think about).
> On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
> > * That SUN is not expected to ever grant a free license to run the TCK
> > for a GPL-licensed project, so the only way to get a "certified" free
> > Java implementation is to ignore the existing GPL'd stuff and start
> > again from scratch?
Kaffe is currently in the process of getting access to the TCK:
http://www.advogato.org/person/robilad/diary.html?start=64
> > * That you feel that the availability of an Apache-licensed project is
> > important enough to duplicate all the existing GPL'd effort? If so, why?
> > Who in particular wants an Apache-licensed implementation and can't
> > accept a GPL'd one?
At least for the GNU Classpath project we have a special exception to
the GPL that we think balances the GPL copyleft terms against the need
to attract a wider community helping with the development and
enhancements to our core class library implementation.
http://www.gnu.org/software/classpath/license.html
If these terms are unclear or might stop certain people from
contributing to GNU Classpath we would like to hear about that.
We setup a wiki for discussion:
http://developer.classpath.org/licensing/
> > * That Kaffe/Classpath are somehow flawed and that it is necessary to
> > start again?
Obviously I don't think so. But if they are then I want to hear about it
(and fix it). That is why I am here.
> > * That because Apache is a well-respected player in the Java community
> > that a project hosted at Apache will be so much better accepted that it
> > is worth discarding all the Kaffe/Classpath work done so far?
It might well be that adding Apache to a name automatically attracts
more contributors then adding GNU to it. If that is true and that would
be the only reason to discard all the work done so far I think I could
convince some people to add "Apache" to their project name and make use
of the apache hosting facilities. Although I believe the FSF savannah
systems are doing just fine.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Keeping the crosspost because the some part is relevant to the "meta"
discussion around the announcement. Inline....
On May 6, 2005, at 11:31 PM, Mark Wielaard wrote:
> Hi,
>
> On Fri, 2005-05-06 at 22:34 -0400, Davanum Srinivas wrote:
>
>> People working on Kaffe/Classpath are gonna advise us..see their
>> names
>> on the proposal :) We (Apache Gump team) has been working with them
>> to make Kaffe/Classpath better for a while now
>> (http://brutus.apache.org/gump/kaffe/buildLog.html). Harmony is going
>> to increase synergies. We are working in parallel with FSF folks on
>> the licensing issues as well for while now. Please see the FAQ as
>> well. we are gonna leverage every bit of code and expertise that we
>> can to make this happen.
>>
>
> As GNU Classpath maintainer I must admit that I am not 100% happy with
> how the announcement came out. I had hoped it would have more
> emphasized
> the fact that we would do everything in our power to work out the
> philosophical, legal and practical issues when reusing existing
> code for
> Harmony.
For this I apologize. I could have done a better job of working with
you to get that message across. You were very clear in our
discussions that this was of significant interest to you.
>
> I do however acknowledge that some of the reluctance comes from my
> side.
> I explicitly said that I would not contribute to any Apache licensed
> project as long as code distributed under the (L)GPL and ASL
> couldn't be
> mixed into a larger work. That is why there are actually multiple
> lists
> of "interested individuals", some people don't want to contribute to a
> new code base that isn't acceptable to both the GNU and the Apache
> community. But those people, like me, might still be interested in the
> technical discussions around such a new code base (even though the
> duplicated effort hurts to even think about).
+1 :)
>
>
>> On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
>>
>>> * That SUN is not expected to ever grant a free license to run
>>> the TCK
>>> for a GPL-licensed project, so the only way to get a "certified"
>>> free
>>> Java implementation is to ignore the existing GPL'd stuff and start
>>> again from scratch?
>>>
>
> Kaffe is currently in the process of getting access to the TCK:
> http://www.advogato.org/person/robilad/diary.html?start=64
>
>
>>> * That you feel that the availability of an Apache-licensed
>>> project is
>>> important enough to duplicate all the existing GPL'd effort? If
>>> so, why?
>>> Who in particular wants an Apache-licensed implementation and can't
>>> accept a GPL'd one?
>>>
>
> At least for the GNU Classpath project we have a special exception to
> the GPL that we think balances the GPL copyleft terms against the need
> to attract a wider community helping with the development and
> enhancements to our core class library implementation.
> http://www.gnu.org/software/classpath/license.html
>
> If these terms are unclear or might stop certain people from
> contributing to GNU Classpath we would like to hear about that.
> We setup a wiki for discussion:
> http://developer.classpath.org/licensing/
>
>
>>> * That Kaffe/Classpath are somehow flawed and that it is
>>> necessary to
>>> start again?
>>>
>
> Obviously I don't think so. But if they are then I want to hear
> about it
> (and fix it). That is why I am here.
>
>
>>> * That because Apache is a well-respected player in the Java
>>> community
>>> that a project hosted at Apache will be so much better accepted
>>> that it
>>> is worth discarding all the Kaffe/Classpath work done so far?
>>>
>
> It might well be that adding Apache to a name automatically attracts
> more contributors then adding GNU to it. If that is true and that
> would
> be the only reason to discard all the work done so far I think I could
> convince some people to add "Apache" to their project name and make
> use
> of the apache hosting facilities. Although I believe the FSF savannah
> systems are doing just fine.
>
> Cheers,
>
> Mark
> --
> Escape the Java Trap with GNU Classpath!
> http://www.gnu.org/philosophy/java-trap.html
>
> Join the community at http://planet.classpath.org/
>
Re: Harmony: project purpose
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Keeping the crosspost because the some part is relevant to the "meta"
discussion around the announcement. Inline....
On May 6, 2005, at 11:31 PM, Mark Wielaard wrote:
> Hi,
>
> On Fri, 2005-05-06 at 22:34 -0400, Davanum Srinivas wrote:
>
>> People working on Kaffe/Classpath are gonna advise us..see their
>> names
>> on the proposal :) We (Apache Gump team) has been working with them
>> to make Kaffe/Classpath better for a while now
>> (http://brutus.apache.org/gump/kaffe/buildLog.html). Harmony is going
>> to increase synergies. We are working in parallel with FSF folks on
>> the licensing issues as well for while now. Please see the FAQ as
>> well. we are gonna leverage every bit of code and expertise that we
>> can to make this happen.
>>
>
> As GNU Classpath maintainer I must admit that I am not 100% happy with
> how the announcement came out. I had hoped it would have more
> emphasized
> the fact that we would do everything in our power to work out the
> philosophical, legal and practical issues when reusing existing
> code for
> Harmony.
For this I apologize. I could have done a better job of working with
you to get that message across. You were very clear in our
discussions that this was of significant interest to you.
>
> I do however acknowledge that some of the reluctance comes from my
> side.
> I explicitly said that I would not contribute to any Apache licensed
> project as long as code distributed under the (L)GPL and ASL
> couldn't be
> mixed into a larger work. That is why there are actually multiple
> lists
> of "interested individuals", some people don't want to contribute to a
> new code base that isn't acceptable to both the GNU and the Apache
> community. But those people, like me, might still be interested in the
> technical discussions around such a new code base (even though the
> duplicated effort hurts to even think about).
+1 :)
>
>
>> On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
>>
>>> * That SUN is not expected to ever grant a free license to run
>>> the TCK
>>> for a GPL-licensed project, so the only way to get a "certified"
>>> free
>>> Java implementation is to ignore the existing GPL'd stuff and start
>>> again from scratch?
>>>
>
> Kaffe is currently in the process of getting access to the TCK:
> http://www.advogato.org/person/robilad/diary.html?start=64
>
>
>>> * That you feel that the availability of an Apache-licensed
>>> project is
>>> important enough to duplicate all the existing GPL'd effort? If
>>> so, why?
>>> Who in particular wants an Apache-licensed implementation and can't
>>> accept a GPL'd one?
>>>
>
> At least for the GNU Classpath project we have a special exception to
> the GPL that we think balances the GPL copyleft terms against the need
> to attract a wider community helping with the development and
> enhancements to our core class library implementation.
> http://www.gnu.org/software/classpath/license.html
>
> If these terms are unclear or might stop certain people from
> contributing to GNU Classpath we would like to hear about that.
> We setup a wiki for discussion:
> http://developer.classpath.org/licensing/
>
>
>>> * That Kaffe/Classpath are somehow flawed and that it is
>>> necessary to
>>> start again?
>>>
>
> Obviously I don't think so. But if they are then I want to hear
> about it
> (and fix it). That is why I am here.
>
>
>>> * That because Apache is a well-respected player in the Java
>>> community
>>> that a project hosted at Apache will be so much better accepted
>>> that it
>>> is worth discarding all the Kaffe/Classpath work done so far?
>>>
>
> It might well be that adding Apache to a name automatically attracts
> more contributors then adding GNU to it. If that is true and that
> would
> be the only reason to discard all the work done so far I think I could
> convince some people to add "Apache" to their project name and make
> use
> of the apache hosting facilities. Although I believe the FSF savannah
> systems are doing just fine.
>
> Cheers,
>
> Mark
> --
> Escape the Java Trap with GNU Classpath!
> http://www.gnu.org/philosophy/java-trap.html
>
> Join the community at http://planet.classpath.org/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Harmony: project purpose
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 7, 2005, at 12:02 PM, Stefano Mazzocchi wrote:
> Anthony Green wrote:
>
>> On Sat, 2005-05-07 at 17:12 +0200, Mark Wielaard wrote:
>>
>>>> * Can Harmony use ClassPath?
>>>>
>>>
>>> Yes! That is the intention. As explained earlier the FSF wants
>>> this to
>>> be the case.
>>>
>> Hopefully we're talking about using and _contributing_ to GNU
>> Classpath. It would be a shame if Harmony simply used GNU
>> Classpath and started
>> filling it out with non-GNU Classpath licensed code instead of
>> merging
>> appropriate changes upstream. To make this simple, it would be
>> convenient if the ASF had a blanket copyright assignment in place for
>> GNU Classpath changes.
>>
>
> I think there is *no* intention from this project to make fixes
> that are not 'mixable' with the original one. Our intention is to
> create 'harmony' not 'hell' :-)
>
Right. I think that's a project over on sourceforge... :)
geir
> --
> Stefano.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Harmony: project purpose
Posted by Stefano Mazzocchi <st...@apache.org>.
Anthony Green wrote:
> On Sat, 2005-05-07 at 17:12 +0200, Mark Wielaard wrote:
>
>>> * Can Harmony use ClassPath?
>>
>>Yes! That is the intention. As explained earlier the FSF wants this to
>>be the case.
>
>
> Hopefully we're talking about using and _contributing_ to GNU
> Classpath.
>
> It would be a shame if Harmony simply used GNU Classpath and started
> filling it out with non-GNU Classpath licensed code instead of merging
> appropriate changes upstream. To make this simple, it would be
> convenient if the ASF had a blanket copyright assignment in place for
> GNU Classpath changes.
I think there is *no* intention from this project to make fixes that are
not 'mixable' with the original one. Our intention is to create
'harmony' not 'hell' :-)
--
Stefano.
Re: Harmony: project purpose
Posted by Anthony Green <gr...@redhat.com>.
On Sat, 2005-05-07 at 17:12 +0200, Mark Wielaard wrote:
> > * Can Harmony use ClassPath?
>
> Yes! That is the intention. As explained earlier the FSF wants this to
> be the case.
Hopefully we're talking about using and _contributing_ to GNU
Classpath.
It would be a shame if Harmony simply used GNU Classpath and started
filling it out with non-GNU Classpath licensed code instead of merging
appropriate changes upstream. To make this simple, it would be
convenient if the ASF had a blanket copyright assignment in place for
GNU Classpath changes.
AG
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
On Sat, 2005-05-07 at 08:19 -0400, Sam Ruby wrote:
> Mark Wielaard wrote:
> >
> > I'll make sure I talk to one of the FSF legal people again to make sure
> > there is progress in these discussions. Some people are setting up a new
> > teleconference between the ASF and FSF to talk about these issues more
> > directly.
>
> The lengthy set of teleconferences we have been having have been
> somewhat... inconclusive.
Agreed. I think we at least know now what the issues (social/legal) are
with the ASL/GPL incompatability are. There were some proposed textual
changes that should make them compatible. It probably is time to call in
the laywers (general counsel) of both sides, put them in the same room
and hammer out a final text.
But for the LGPL list of issues that the Apache hackers had in response
to http://www.gnu.org/licenses/lgpl-java.html we might need some more
discussion.
> This is still a lot of room for optimism.
>
> Concrete questions to help focus the discussion:
>
> * Can ClassPath use APR?
We have a reference implementation of some of the
platform/runtime/compiler specific parts of the core library that works
with C, JNI on GNU/Posix like systems (for io, nio, timezones, etc.)
This can be replaced with a version that uses APR if there is a
technical need. Kaffe for example replaces part of this layer with a KNI
implementation. IKVM.NET replaces it with a system that uses the
standard C# libraries as much as possible. And GCJ replaces parts of it
with a C++/CNI implementation. See the links to various documentation
about this VM Interface layer posted earlier. Or look into vm/reference
in a recent GNU Classpath release.
We will most likely not replace the current reference implementation
with one that is based on APR since that is currently licensed under the
ASL and we want GNU Classpath to be GPL-compatible for projects that use
and distribute it under the GPL. But if the ASL could be changed to
become GPL-compatible or APR would dual license under the (L)GPL or use
a GPL-compatible license such as modern BSD, MIT/X, W3C, etc then we
will certainly consider it if there is a technical need.
> * Can Harmony use ClassPath?
Yes! That is the intention. As explained earlier the FSF wants this to
be the case. If there are any legal issues with the current GPL
exception statement wording then we want to fix that by clarifying the
exception to clearly address any concerns the harmony people have that
might prevent them from embracing and extending GNU Classpath.
Cheers,
Mark
> P.S. I still believe that we all would be best served if the
> meta-harmony discussions were moved to the harmony mailing lists,
> reporting back as appropriate as we come to conclusions, but sometimes
> it doesn't make sense to argue with a herd of elephants.
Moved this to just the harmony list.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Steve,
On Sun, 2005-05-08 at 08:13 -0700, Steven Augart wrote:
> This is ideal. I was concerned that we'd be building a new set of
> APL-licensed libraries from scratch, after the hard work we've put into
> GNU Classpath.
And thanks for your contributions to it!
It seems most people involved are convinced that building something
around the GNU Classpath core libraries and runtime/compiler interfaces
is a sane idea. This is however a group discussion, so maybe someone
will come up with some other plan. We will have to wait and see.
> Just to confirm: you're saying that the GNU Classpath project will be
> relicensing the existing GNU Classpath code base with some sort of
> MPL-style license that is GPL and APL compatible. Have I understood
> correctly?
No. I got some feedback on-list and off-list that there is no need for
that. The current exception statement to the GPL used by GNU Classpath
is compatible with and acceptable to the Apache community. But the FSF
did say that IF the exception statement was in any way unclear THEN they
would certainly be willing to clarify it so that there was no obstacle
for adoption of GNU Classpath. There currently doesn't seem any need to
do this though.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by Steven Augart <sa...@yahoo.com>.
--- Mark Wielaard <ma...@klomp.org> wrote:
> Hi Doug,
>
> On Sat, 2005-05-07 at 12:00 -0400, Doug Lea wrote:
> > I think the brilliance of Geir's move here is that all of
> > FSF, Sun, IBM, BEA, etc now have equal motivation to change
> > their licensing so that they can participate. I hope they all
> > do.
>
> If you reveal the secret plan, it isn't secret anymore... :)
>
> But yes, I can confirm that the FSF GNU Classpath project will make
> sure
> that their license will be GPL and APL compatible. And we hope that
> everything that comes out of the Harmony project will be acceptable to
> both the GNU and Apache communities.
Mark,
This is ideal. I was concerned that we'd be building a new set of
APL-licensed libraries from scratch, after the hard work we've put into
GNU Classpath.
Just to confirm: you're saying that the GNU Classpath project will be
relicensing the existing GNU Classpath code base with some sort of
MPL-style license that is GPL and APL compatible. Have I understood
correctly?
--Steve Augart
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Doug,
On Sat, 2005-05-07 at 12:00 -0400, Doug Lea wrote:
> I think the brilliance of Geir's move here is that all of
> FSF, Sun, IBM, BEA, etc now have equal motivation to change
> their licensing so that they can participate. I hope they all
> do.
If you reveal the secret plan, it isn't secret anymore... :)
But yes, I can confirm that the FSF GNU Classpath project will make sure
that their license will be GPL and APL compatible. And we hope that
everything that comes out of the Harmony project will be acceptable to
both the GNU and Apache communities.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Sun, 2005-05-08 at 00:44 -0700, Jason Brittain wrote:
> * I have been watching the Kaffe and Classpath projects since their inception,
> and wow, that's quite a bit of work they bit off for the sake of free Java.
> Although the licenses don't work for me, I'm proud of them for sticking with
> it. And, I must congratulate them on being complete enough to run Tomcat.
> This is the first OSS JVM I've ever been able to get Tomcat running on.
> Keep up the exceptional work!
> http://article.gmane.org/gmane.comp.jakarta.tomcat.devel/51624/match=kaffe++tomcat
Thanks.
> * Aside from dual-licensing, reimplementation seems to be the only way to have
> the same kind of software available under more than one OSS license. And,
> I believe the Apache licenses have a different and mutually exclusive purpose
> in life versus the (L)GPL licenses. Probably few codebases will be
> dual-licensed AL and (L)GPL like the "tri-licensed" Mozilla browser, which the
> FSF describes as the "disjunction of the GPL and the MPL".
> http://www.mozilla.org/MPL/
> Maybe I'm wrong here, but if Kaffe and Classpath were dual-licensed this way,
> wouldn't that be acceptable to all, except for the ASF politics of adopting
> donated code?
The intention of the current GNU Classpath license is to be acceptable
to the Apache community. If it is not, then we are willing to discuss
and eventually change it in a way so that it is.
> * I believe that the AL and GPL have different goals that are mutually exclusive.
> It would sure solve some problems if they could one day be reconciled enough
> to consolidate major OSS projects like this. It's certainly worth trying.
> But, people have been trying to get these two licenses to be compatible enough
> to collaborate for a long time and it still hasn't happened, so I have serious
> doubts that it happen.
I am optimistic. There are currently talks on the highest levels of the
FSF and ASF to get things finally cleared up. It looks like we will have
a breakthrough soon. But it happens when it happens. Till then we will
at least for the projects participating on Harmony make the best of it.
> * I have chosen not to contribute to Kaffe nor to Classpath, solely due to
> their licenses. Yes, I'm aware that Classpath's license is GPL with
> exceptions to make it not GPL anymore. But, to me, it's either GPL or it's
> not GPL. If it's not the GPL, I don't understand why the FSF would want to
> help. The FSF worded the GPL carefully and deliberately to achieve certain
> goals. Removing the viralness of the GPL undermines restrictions that the FSF
> seems to want in there. This changes the license significantly. It's not
> actually the GPL. It's close, but it's probably more like the LGPL, which
> is also not the license that the Classpath project members chose.
Yes, the FSF and GNU projects like to use pure unadulterate GPL whenever
they can. But that doesn't mean they don't want to compromise when that
is of strategic interest. For GNU Classpath we have adapted the license
two times already to appeal to a wider audience. We are willing to do
that again if necessary.
Dalibor and I had a little discussion session about the GNU community,
the GPL, making compromises and working with other communities a while
ago: http://www.klomp.org/mark/classpath/CommunityGPLCompromise/
As you can see one of the participants was Geir. That is one of the
reasons we are now talking about Harmony.
> I also do not find the GPL as free as
> the AL or BSD-style licenses due mainly to the viralness, which is there for
> reasons that I understand, but in the end it's just unacceptable for the
> Java code that I write and the ways I need/want to use it.
We all make different compromises. And we all want to do the best for
our respective GNU or Apache communities. That is something we have to
respect. So I am sure we won't cooperate on everything. But I do hope we
will cooperate on most things and make the results usable to both the
Apache and the GNU worlds.
> * It sure seems like the about only time the committers of a GPL or LGPL Java
> project spend time seriously considering the terms of their chosen license is
> when they hear about an Apache licensed project with the same goals that is
> getting some resources and attention. In the absence of the Apache licensed
> project, I've asked about BSD-style relicensing or dual-licensing and it's
> just out of the question (to be clear, I never asked for a BSD licensed Kaffe
> nor Classpath, but other (L)GPL'd projects that will remain unnamed). I've
> often been told "there's nothing wrong with the (L)GPL, it's plenty free
> enough and we're not changing it". I've all but given up asking. But, then
> when enough people give up waiting and asking, and have to have it licensed
> as BSD-style, and form a new project to just reimplement all of it because
> there is no other option, then lots of GPL developers seem more interested in
> discussing collaboration again. I wish this wasn't a recurring pattern.
We do feel the same pain "on the other side". Often the first reaction
of someone pointing out a Apache licensed code base is to say "O, no!
That would be nice to use, but I am sure if we asked to distribute under
a acceptable license they get mad. Lets not have a flameware. Lets not
ask. Lets start our own thing." That is sad, but it happens. And
sometimes it happens for good technical reasons. But often it happens
because of some legal technicality. It would indeed be great if that
could be solved not just in project Harmony, but also on a bigger
FSF/ASF scale.
> * I like the Apache license all except for the attribution terms. Really, guys,
> do you think everyone would just forget that the ASF existed if the
> attribution terms weren't in the license? To me it seems like a vanity
> restriction placed on all licensees. If there's a good reason for it, I
> wish I knew what it was. It's not a very big deal, but I wish OSS code
> could be free of advertizing. But, also, hasn't this been one of the
> barriers to GPL compatibility/collaboration since this is a license
> restriction that the GPL doesn't have?
Yes it was with the Apache License 1.1. This part has been solved by
rewording it a bit so that it is technically GPL compatible in the 2.0
version. The only remaining difficulty with the 2.0 version is the
precise wording of the patent retaliation clause. There were some other
misunderstandings which have been worked out already.
> Now, a suggestion for the Harmony project:
>
> - Any Java runtime can only safely implement one version of Java at a time.
> For example, it's either Java 1.3 or it's Java 1.4. It can't be both.
> Programs that run on the JVM often try to detect which version of Java
> they're running on, and call appropriate methods based on the detected
> version. If you target Java 1.5 now, by the time you get, say, one fourth
> of the way to having it fully implemented, the latest stable version of
> Java may be Java 2.3 (or something higher like that), and 1.5 won't seem
> important anymore. If then you try to implement newer versions of some core
> classes to stay at least partially compatible with the latest stable Java,
> then parts of the core will implement v1.5, and parts will implement v2.3,
> and programs will end up being very confused about which version of Java
> they're running on, and will break in random ways. I noticed this problem
> with Kaffe, and I wanted to mention it here. Please, in any one binary
> release of Harmony, make sure it attempts to implement exactly one version of
> Java.
Note that this is the reason there is no GNU Classpath 1.0 release yet.
We don't feel that it is a complete free replacement for the proprietary
core class libraries just yet. The coverage is somewhere between 1.1 and
1.5, with some packages better then their proprietary counterparts,
where others have just been started. Kaffe actually keeps a list of the
progress they are making with the integrated effort:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-kaffe.html
The problem here has always been whether or not we should just halt
development and just forbid people to work on the parts they would
really want to improve (maybe just because their application uses those
parts, but not others). But that is just not how cooperative distributed
development works. We are all volunteers and rejecting work that is
technically good and useful is just not what we do. We could create
different branches for work on 1.1, 1.2, 1.3, 1.4 and 1.5 work
simultaniously. But this is a lot of extra work and maintanance for
which we don't have the voluteers atm. We do have a separate branch for
the new generics work in GNU Classpath though. We do have a volunteer
that manages that branch. So we could certainly use someone that just
made a GNU Classpath 1.1, 1.2, 1.3 and 1.4 'cuts'. Containing just those
parts that could be considered part of the proprietary counterpart of
the JDK. That is real work though. So we would need really dedicated
volunteers that really can do that work of cutting up the unified
release. We also don't want to see lots and lots of shattered releases
that are all not really done. But there is a lot of important other work
to do that might be more urgent to get done. Just focussing on getting
full 1.4 and 1.5 coverage will certainly be multiple person-months of
work.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by Jason Brittain <ja...@brittainweb.org>.
Stefano Mazzocchi wrote:
> Sam Ruby wrote:
>> Doug Lea wrote:
>>
>>> Re: licensing etc.
>>>
>>> I think the brilliance of Geir's move here is that all of
>>> FSF, Sun, IBM, BEA, etc now have equal motivation to change
>>> their licensing so that they can participate. I hope they all
>>> do.
>>
>> Add the ASF to that list.
>>
>> I firmly believe that we can form an inclusive community in which
>> everybody who is willing to meet each other half was has an opportunity
>> to participate.
>
> Amen.
This is one of the most important points I've read yet. Each of these
licenses have one or more clauses that are unacceptable for whatever reason,
and the Apache license is no exception.
My perspective, as neither an ASF member nor an FSF member:
* I'm excited to hear about this project! I do plan to contribute where I
can, even if I can only be a small contributor.
* The more open source Java there is, the better, even if we have competing
projects, and especially if we have projects that use different licenses that
each are good for their own intended purpose. Competition is good for us.
And, why shouldn't we be able to choose the best license for the task at hand,
and still have good code to use?
* I have been watching the Kaffe and Classpath projects since their inception,
and wow, that's quite a bit of work they bit off for the sake of free Java.
Although the licenses don't work for me, I'm proud of them for sticking with
it. And, I must congratulate them on being complete enough to run Tomcat.
This is the first OSS JVM I've ever been able to get Tomcat running on.
Keep up the exceptional work!
http://article.gmane.org/gmane.comp.jakarta.tomcat.devel/51624/match=kaffe++tomcat
* Aside from dual-licensing, reimplementation seems to be the only way to have
the same kind of software available under more than one OSS license. And,
I believe the Apache licenses have a different and mutually exclusive purpose
in life versus the (L)GPL licenses. Probably few codebases will be
dual-licensed AL and (L)GPL like the "tri-licensed" Mozilla browser, which the
FSF describes as the "disjunction of the GPL and the MPL".
http://www.mozilla.org/MPL/
Maybe I'm wrong here, but if Kaffe and Classpath were dual-licensed this way,
wouldn't that be acceptable to all, except for the ASF politics of adopting
donated code?
* I believe that the AL and GPL have different goals that are mutually exclusive.
It would sure solve some problems if they could one day be reconciled enough
to consolidate major OSS projects like this. It's certainly worth trying.
But, people have been trying to get these two licenses to be compatible enough
to collaborate for a long time and it still hasn't happened, so I have serious
doubts that it happen.
* I have chosen not to contribute to Kaffe nor to Classpath, solely due to
their licenses. Yes, I'm aware that Classpath's license is GPL with
exceptions to make it not GPL anymore. But, to me, it's either GPL or it's
not GPL. If it's not the GPL, I don't understand why the FSF would want to
help. The FSF worded the GPL carefully and deliberately to achieve certain
goals. Removing the viralness of the GPL undermines restrictions that the FSF
seems to want in there. This changes the license significantly. It's not
actually the GPL. It's close, but it's probably more like the LGPL, which
is also not the license that the Classpath project members chose. It hurts
my brain to try to figure out what the terms of the unmodified GPL really
mean for a Java program, let alone what they mean after special (major)
exceptions. And, as for Kaffe's license, I find the GPL's terms unacceptable
for the Java language and Java runtime because the terms used are more like
C language constructs that have undefined or multiply defined meanings for
the Java language or the Java runtime. I also do not find the GPL as free as
the AL or BSD-style licenses due mainly to the viralness, which is there for
reasons that I understand, but in the end it's just unacceptable for the
Java code that I write and the ways I need/want to use it.
* It sure seems like the about only time the committers of a GPL or LGPL Java
project spend time seriously considering the terms of their chosen license is
when they hear about an Apache licensed project with the same goals that is
getting some resources and attention. In the absence of the Apache licensed
project, I've asked about BSD-style relicensing or dual-licensing and it's
just out of the question (to be clear, I never asked for a BSD licensed Kaffe
nor Classpath, but other (L)GPL'd projects that will remain unnamed). I've
often been told "there's nothing wrong with the (L)GPL, it's plenty free
enough and we're not changing it". I've all but given up asking. But, then
when enough people give up waiting and asking, and have to have it licensed
as BSD-style, and form a new project to just reimplement all of it because
there is no other option, then lots of GPL developers seem more interested in
discussing collaboration again. I wish this wasn't a recurring pattern.
* I like the Apache license all except for the attribution terms. Really, guys,
do you think everyone would just forget that the ASF existed if the
attribution terms weren't in the license? To me it seems like a vanity
restriction placed on all licensees. If there's a good reason for it, I
wish I knew what it was. It's not a very big deal, but I wish OSS code
could be free of advertizing. But, also, hasn't this been one of the
barriers to GPL compatibility/collaboration since this is a license
restriction that the GPL doesn't have?
Now, a suggestion for the Harmony project:
- Any Java runtime can only safely implement one version of Java at a time.
For example, it's either Java 1.3 or it's Java 1.4. It can't be both.
Programs that run on the JVM often try to detect which version of Java
they're running on, and call appropriate methods based on the detected
version. If you target Java 1.5 now, by the time you get, say, one fourth
of the way to having it fully implemented, the latest stable version of
Java may be Java 2.3 (or something higher like that), and 1.5 won't seem
important anymore. If then you try to implement newer versions of some core
classes to stay at least partially compatible with the latest stable Java,
then parts of the core will implement v1.5, and parts will implement v2.3,
and programs will end up being very confused about which version of Java
they're running on, and will break in random ways. I noticed this problem
with Kaffe, and I wanted to mention it here. Please, in any one binary
release of Harmony, make sure it attempts to implement exactly one version of
Java.
Cheers.
--
Jason Brittain
This message presents personal opinions which are not necessarily those
of my employer(s).
Re: Harmony: project purpose
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Doug Lea wrote:
>
>>
>> Re: licensing etc.
>>
>> I think the brilliance of Geir's move here is that all of
>> FSF, Sun, IBM, BEA, etc now have equal motivation to change
>> their licensing so that they can participate. I hope they all
>> do.
>
>
> Add the ASF to that list.
>
> I firmly believe that we can form an inclusive community in which
> everybody who is willing to meet each other half was has an opportunity
> to participate.
Amen.
--
Stefano.
Re: Harmony: project purpose
Posted by Sam Ruby <ru...@apache.org>.
Anthony Green wrote:
> On Sat, 2005-05-07 at 15:55 -0400, Sam Ruby wrote:
>
>>I firmly believe that we can form an inclusive community in which
>>everybody who is willing to meet each other half was has an opportunity
>>to participate.
>
> Yes, we've seen this work before...
>
> http://gcc.gnu.org/ml/java-announce/2000/msg00001.html
>
> Cygnus and the FSF were both implementing our own versions of the core
> class libraries. GNU Classpath was LGPLd at the time. This was
> unsuitable for Cygnus, who wanted something more like the libgcc or
> libstdc++ license. In the end, the FSF agreed to change the GNU
> Classpath license and Cygnus assigned copyright of all of our class
> library code to the FSF. It was a great move for everybody.
Excellent!
I doubt that we know yet what (if any?) change to the GNU Classpath
license would be required, nor even if a copyright assignment from the
ASF would be required (be aware the contributors don't currently assign
copyright to the ASF, instead they grant the ASF a copyright license to
distribute), but it is nice to know that there is precedent here.
Perhaps in this way we can also address the Classpath/APR license issue.
Related reading:
http://www.apache.org/licenses/icla.txt
http://www.apache.org/licenses/GPL-compatibility
- Sam Ruby
Re: Harmony: project purpose
Posted by Anthony Green <gr...@redhat.com>.
On Sat, 2005-05-07 at 15:55 -0400, Sam Ruby wrote:
> I firmly believe that we can form an inclusive community in which
> everybody who is willing to meet each other half was has an opportunity
> to participate.
Yes, we've seen this work before...
http://gcc.gnu.org/ml/java-announce/2000/msg00001.html
Cygnus and the FSF were both implementing our own versions of the core
class libraries. GNU Classpath was LGPLd at the time. This was
unsuitable for Cygnus, who wanted something more like the libgcc or
libstdc++ license. In the end, the FSF agreed to change the GNU
Classpath license and Cygnus assigned copyright of all of our class
library code to the FSF. It was a great move for everybody.
AG
Re: Harmony: project purpose
Posted by Sam Ruby <ru...@apache.org>.
Doug Lea wrote:
>
> Re: licensing etc.
>
> I think the brilliance of Geir's move here is that all of
> FSF, Sun, IBM, BEA, etc now have equal motivation to change
> their licensing so that they can participate. I hope they all
> do.
Add the ASF to that list.
I firmly believe that we can form an inclusive community in which
everybody who is willing to meet each other half was has an opportunity
to participate.
- Sam Ruby
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Doug,
On Sat, 2005-05-07 at 12:00 -0400, Doug Lea wrote:
> I think the brilliance of Geir's move here is that all of
> FSF, Sun, IBM, BEA, etc now have equal motivation to change
> their licensing so that they can participate. I hope they all
> do.
If you reveal the secret plan, it isn't secret anymore... :)
But yes, I can confirm that the FSF GNU Classpath project will make sure
that their license will be GPL and APL compatible. And we hope that
everything that comes out of the Harmony project will be acceptable to
both the GNU and Apache communities.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by Doug Lea <dl...@cs.oswego.edu>.
Re: licensing etc.
I think the brilliance of Geir's move here is that all of
FSF, Sun, IBM, BEA, etc now have equal motivation to change
their licensing so that they can participate. I hope they all
do.
-Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Harmony: project purpose
Posted by Doug Lea <dl...@cs.oswego.edu>.
Re: licensing etc.
I think the brilliance of Geir's move here is that all of
FSF, Sun, IBM, BEA, etc now have equal motivation to change
their licensing so that they can participate. I hope they all
do.
-Doug
Re: Harmony: project purpose
Posted by Sam Ruby <ru...@apache.org>.
Mark Wielaard wrote:
>
> I'll make sure I talk to one of the FSF legal people again to make sure
> there is progress in these discussions. Some people are setting up a new
> teleconference between the ASF and FSF to talk about these issues more
> directly.
The lengthy set of teleconferences we have been having have been
somewhat... inconclusive.
It is my hope that the harmony proposal accelerates that process.
Preferably with an answer that we all like. But if not - at some point
even an answer that we don't like is better than lingering unanswered
open questions.
I'd also like to point out that we are not at that point yet. Not even
close. Apache incubation can be a fairly long process, particularly for
proposals such as this one.
This is still a lot of room for optimism.
Concrete questions to help focus the discussion:
* Can ClassPath use APR?
* Can Harmony use ClassPath?
- Sam Ruby
P.S. I still believe that we all would be best served if the
meta-harmony discussions were moved to the harmony mailing lists,
reporting back as appropriate as we come to conclusions, but sometimes
it doesn't make sense to argue with a herd of elephants.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Harmony: project purpose
Posted by Sam Ruby <ru...@apache.org>.
Mark Wielaard wrote:
>
> I'll make sure I talk to one of the FSF legal people again to make sure
> there is progress in these discussions. Some people are setting up a new
> teleconference between the ASF and FSF to talk about these issues more
> directly.
The lengthy set of teleconferences we have been having have been
somewhat... inconclusive.
It is my hope that the harmony proposal accelerates that process.
Preferably with an answer that we all like. But if not - at some point
even an answer that we don't like is better than lingering unanswered
open questions.
I'd also like to point out that we are not at that point yet. Not even
close. Apache incubation can be a fairly long process, particularly for
proposals such as this one.
This is still a lot of room for optimism.
Concrete questions to help focus the discussion:
* Can ClassPath use APR?
* Can Harmony use ClassPath?
- Sam Ruby
P.S. I still believe that we all would be best served if the
meta-harmony discussions were moved to the harmony mailing lists,
reporting back as appropriate as we come to conclusions, but sometimes
it doesn't make sense to argue with a herd of elephants.
RE: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Sat, 2005-05-07 at 00:20 -0400, Noel J. Bergman wrote:
> Mark Wielaard wrote:
>
> > I had hoped it would have more emphasized the fact that we would do
> > everything in our power to work out the philosophical, legal and
> > practical issues when reusing existing code for Harmony.
>
> Well, I think it does try, but at this point it must be more important how
> we go on from here. :-) And your expression is an important part of that
> process.
Thanks. I feel it is important that we build bridges between the Apache
and GNU communities whenever possible.
> > I explicitly said that I would not contribute to any Apache licensed
> > project as long as code distributed under the (L)GPL and ASL couldn't
> > be mixed into a larger work.
>
> You are aware that the ASF and FSF are trying to address the issues, and
> this effort may help move that along.
>
> > At least for the GNU Classpath project we have a special exception
>
> And we're still trying to work out some issues with the FSF there. Unless
> there has been a breakthrough recently, we posed very specific use cases,
> and have as yet not gotten the necessary response.
I didn't realize these were for the GNU Classpath license. Which you can
read here: http://www.gnu.org/software/classpath/license.html
I thought these questions were in connection with the LGPL and how to
interpret the explanation posted by the FSF here:
http://www.gnu.org/licenses/lgpl-java.html
I'll make sure I talk to one of the FSF legal people again to make sure
there is progress in these discussions. Some people are setting up a new
teleconference between the ASF and FSF to talk about these issues more
directly.
> > Kaffe is currently in the process of getting access to the TCK:
> > http://www.advogato.org/person/robilad/diary.html?start=64
>
> The aforementioned issues between GPL and AL aside, I am still trying to see
> how the TCK licensing restrictions are compatible with the GPL.
I am not a party in these discussions. And as I understood from Dalibor
from the Kaffe team the actual terms are still under discussion and
confidential at the moment. So I am not sure they can already tell how
and if Sun wants to handle this.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
RE: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Sat, 2005-05-07 at 00:20 -0400, Noel J. Bergman wrote:
> Mark Wielaard wrote:
>
> > I had hoped it would have more emphasized the fact that we would do
> > everything in our power to work out the philosophical, legal and
> > practical issues when reusing existing code for Harmony.
>
> Well, I think it does try, but at this point it must be more important how
> we go on from here. :-) And your expression is an important part of that
> process.
Thanks. I feel it is important that we build bridges between the Apache
and GNU communities whenever possible.
> > I explicitly said that I would not contribute to any Apache licensed
> > project as long as code distributed under the (L)GPL and ASL couldn't
> > be mixed into a larger work.
>
> You are aware that the ASF and FSF are trying to address the issues, and
> this effort may help move that along.
>
> > At least for the GNU Classpath project we have a special exception
>
> And we're still trying to work out some issues with the FSF there. Unless
> there has been a breakthrough recently, we posed very specific use cases,
> and have as yet not gotten the necessary response.
I didn't realize these were for the GNU Classpath license. Which you can
read here: http://www.gnu.org/software/classpath/license.html
I thought these questions were in connection with the LGPL and how to
interpret the explanation posted by the FSF here:
http://www.gnu.org/licenses/lgpl-java.html
I'll make sure I talk to one of the FSF legal people again to make sure
there is progress in these discussions. Some people are setting up a new
teleconference between the ASF and FSF to talk about these issues more
directly.
> > Kaffe is currently in the process of getting access to the TCK:
> > http://www.advogato.org/person/robilad/diary.html?start=64
>
> The aforementioned issues between GPL and AL aside, I am still trying to see
> how the TCK licensing restrictions are compatible with the GPL.
I am not a party in these discussions. And as I understood from Dalibor
from the Kaffe team the actual terms are still under discussion and
confidential at the moment. So I am not sure they can already tell how
and if Sun wants to handle this.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: Harmony: project purpose
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On May 6, 2005, at 9:20 PM, Noel J. Bergman wrote:
> The aforementioned issues between GPL and AL aside, I am still trying
> to see
> how the TCK licensing restrictions are compatible with the GPL.
> According
> to the FSF licensing page, the Apache License is deemed by the FSF to
> be
> "incompatible with the GPL because it has a specific requirement that
> is not
> in the GPL." So how much worse are the TCK licensing restrictions?
> For
> examples, see the modified version of the AL that has been drafted for
> dealing with JSR's:
> http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt. As I read
> things, it really does not seem possible to meet the requirements of
> both
> the GPL and the Java licenses. And any bending necessary to accept
> the TCK
> terms should help to address the AL issue as well.
Note that, although the JSR license above is a proposal that has since
been modified (it is working through the approval process right now as
part of Day's JSR 170), the reciprocal patent license is actually a
requirement of the JSPA. So, even if Sun has some other terms in
mind for their own TCKs, they will have to include a patent termination
clause that is almost identical to the one that the FSF claims in
incompatible with the GPL.
Personally, I think the FSF should just create a Java-specific license
that says what they want.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Harmony: project purpose
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mark Wielaard wrote:
> I had hoped it would have more emphasized the fact that we would do
> everything in our power to work out the philosophical, legal and
> practical issues when reusing existing code for Harmony.
Well, I think it does try, but at this point it must be more important how
we go on from here. :-) And your expression is an important part of that
process.
> I explicitly said that I would not contribute to any Apache licensed
> project as long as code distributed under the (L)GPL and ASL couldn't
> be mixed into a larger work.
You are aware that the ASF and FSF are trying to address the issues, and
this effort may help move that along.
> At least for the GNU Classpath project we have a special exception
And we're still trying to work out some issues with the FSF there. Unless
there has been a breakthrough recently, we posed very specific use cases,
and have as yet not gotten the necessary response.
> Kaffe is currently in the process of getting access to the TCK:
> http://www.advogato.org/person/robilad/diary.html?start=64
The aforementioned issues between GPL and AL aside, I am still trying to see
how the TCK licensing restrictions are compatible with the GPL. According
to the FSF licensing page, the Apache License is deemed by the FSF to be
"incompatible with the GPL because it has a specific requirement that is not
in the GPL." So how much worse are the TCK licensing restrictions? For
examples, see the modified version of the AL that has been drafted for
dealing with JSR's:
http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt. As I read
things, it really does not seem possible to meet the requirements of both
the GPL and the Java licenses. And any bending necessary to accept the TCK
terms should help to address the AL issue as well.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Harmony: project purpose
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mark Wielaard wrote:
> I had hoped it would have more emphasized the fact that we would do
> everything in our power to work out the philosophical, legal and
> practical issues when reusing existing code for Harmony.
Well, I think it does try, but at this point it must be more important how
we go on from here. :-) And your expression is an important part of that
process.
> I explicitly said that I would not contribute to any Apache licensed
> project as long as code distributed under the (L)GPL and ASL couldn't
> be mixed into a larger work.
You are aware that the ASF and FSF are trying to address the issues, and
this effort may help move that along.
> At least for the GNU Classpath project we have a special exception
And we're still trying to work out some issues with the FSF there. Unless
there has been a breakthrough recently, we posed very specific use cases,
and have as yet not gotten the necessary response.
> Kaffe is currently in the process of getting access to the TCK:
> http://www.advogato.org/person/robilad/diary.html?start=64
The aforementioned issues between GPL and AL aside, I am still trying to see
how the TCK licensing restrictions are compatible with the GPL. According
to the FSF licensing page, the Apache License is deemed by the FSF to be
"incompatible with the GPL because it has a specific requirement that is not
in the GPL." So how much worse are the TCK licensing restrictions? For
examples, see the modified version of the AL that has been drafted for
dealing with JSR's:
http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt. As I read
things, it really does not seem possible to meet the requirements of both
the GPL and the Java licenses. And any bending necessary to accept the TCK
terms should help to address the AL issue as well.
--- Noel