You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Simon Kitching <sk...@apache.org> on 2005/05/07 04:26:35 UTC
Harmony: project purpose
Hi,
Can someone clarify for me why Harmony is being proposed when GNU
Classpath, Kaffe and other projects are quite a long way to satisfying
the goal of a Free Java environment?
Is it:
* 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?
* That you feel that more contributors will be involved in an
Apache-licensed project than in a GPL-licensed project, resulting in a
better overall end result? If so, why?
* 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?
* That Kaffe/Classpath are somehow flawed and that it is necessary to
start again?
* 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?
Regards,
Simon
---------------------------------------------------------------------
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>.
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
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
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 Tom Tromey <tr...@redhat.com>.
>>>>> "Mark" == Mark Wielaard <ma...@klomp.org> writes:
Mark> I don't know if there are documents on the shared bytecode
Mark> verifier ideas that some people talked about. The verifier exists in
Mark> pluggable form on the gcjx branch of the GCC cvs repository.
There are no documents. I ought to write some. If another VM
(kaffe... hi Dalibor) starts using this, we ought to push it into
Classpath.
Mark> Mauve http://sources.redhat.com/mauve/ contains tests for the
Mark> various parts (language, core-libraries, jit, visual AWT tester,
Mark> BC). JikesRVM comes with a JNI testframework.
Yes, at the very least we ought to collaborate on testing. I can't
think of a reason why we wouldn't do that.
Mark> There have been talks about sharing parts of the JDWP and JVMTI
Mark> layers/interfaces. Most of the wire-protocol at least can be
Mark> shared. I have some designs for that, but I forgot who is
Mark> working on this for gcj.
The documents for this still haven't been released; I'll try to push
on that again.
Tom
Re: Harmony: project purpose
Posted by Mark Wielaard <ma...@klomp.org>.
Hi (moved to harmonay list since it is just a list of teechnical
points),
On Fri, 2005-05-06 at 23:02 -0400, Geir Magnusson Jr. wrote:
> On May 6, 2005, at 10:54 PM, Simon Kitching wrote:
>
> > Without that, only general "design
> > principles" can be shared between Harmony and these projects, which
> > really isn't of much use in the Classpath case as the classes must
> > adhere to the Sun TCK which must be pretty detailed on library class
> > behaviour.
>
> Except that it's my understanding that the GNU "family" of projects
> (Kaffe, GNU Classpath, GCJ, etc) all want to use GNU Classpath, and
> are working out how to make it pluggable and modular. We need the
> same thing (would be great to have a VM that we could plug a
> different classlibrary into to get J2ME, for example), so why not
> work together? Then when we get past the license problem, we can
> intermix.
Yes. And I urge everybody to take a look at the current projects around
GNU Classpath and how they integrated different parts:
http://www.gnu.org/software/classpath/stories.html
When Geir proposed the Harmony project to me and asked if I was
interested in helping out defining bridges I send the following
referrences that I think will benefit the project:
GNU Classpath VM Integration Guide
http://www.gnu.org/software/classpath/docs/vmintegration.html
Hacking on the VM Interface workshop slides
http://klomp.org/mark/classpath/slides/gnu_classpath_workshop.html
Both are a bot out of date, it would be good to update them
again. Currently the vm/reference source code in a recent GNU
Classpath release tarbal should give you a better impression.
There is of course the binary compatibility ABI for GCJ:
ftp://gcc.gnu.org/pub/gcc/summit/2004/GCJ%20New%20ABI.pdf
I don't know if there are documents on the shared bytecode
verifier ideas that some people talked about. The verifier exists in
pluggable form on the gcjx branch of the GCC cvs repository.
Both gcj and kaffe now (can) use the boehmgc.
Mauve http://sources.redhat.com/mauve/ contains tests for the
various parts (language, core-libraries, jit, visual AWT tester,
BC). JikesRVM comes with a JNI testframework.
The CNI used to bind classes/methods written in c++ and java in
gcj is described at:
http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html
There have been talks about sharing parts of the JDWP and JVMTI
layers/interfaces. Most of the wire-protocol at least can be
shared. I have some designs for that, but I forgot who is
working on this for gcj.
GNU Classpath Tools provides some tools (like gjdoc) that
runtimes can share
http://www.gnu.org/software/classpath/cp-tools/
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>.
On May 6, 2005, at 10:54 PM, Simon Kitching wrote:
> Unfortunately, legally isn't it impossible for a GPL'd project and an
> ASF'd project to *have* "synergies"?
Only if you narrowly define "synergy" to mean combining differently-
licensed code.
>
> If GNU (who presumably have a copyright on all the Classpath code) are
> willing to relicense under the APL, then that would work. Same for
> Kaffe
> (though probably more difficult unless Kaffe require copyright
> assignment as part of contributions as GNU do). But the proposal
> document doesn't state either.
Right - we want to leave it to whoever shows up to talk about
whatever they want to do.
> Without that, only general "design
> principles" can be shared between Harmony and these projects, which
> really isn't of much use in the Classpath case as the classes must
> adhere to the Sun TCK which must be pretty detailed on library class
> behaviour.
Except that it's my understanding that the GNU "family" of projects
(Kaffe, GNU Classpath, GCJ, etc) all want to use GNU Classpath, and
are working out how to make it pluggable and modular. We need the
same thing (would be great to have a VM that we could plug a
different classlibrary into to get J2ME, for example), so why not
work together? Then when we get past the license problem, we can
intermix.
> Sharing design discussions with Kaffe developers may be
> somewhat more productive, but even so 90% of the work is in the code -
> which cannot be transferred to an APL-licensed project.
I'm not so sure. There has been *tremendous* amounts of work out
there thinking about modular platforms, to help get different
performance profiles, for example.
>
> This proposal seems *so* much work to reimplement stuff already done
> under the GPL (unless that code can be relicensed as described above).
> I'm curious to know what the benefit of all that work is..
>
We'll, come help and find out :)
geir
> Regards,
>
> Simon
>
> On Fri, 2005-05-06 at 22:34 -0400, Davanum Srinivas wrote:
>
>> Simon,
>>
>> 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.
>>
>> -- dims
>>
>> On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> Can someone clarify for me why Harmony is being proposed when GNU
>>> Classpath, Kaffe and other projects are quite a long way to
>>> satisfying
>>> the goal of a Free Java environment?
>>> Is it:
>>>
>>> * 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?
>>>
>>> * That you feel that more contributors will be involved in an
>>> Apache-licensed project than in a GPL-licensed project, resulting
>>> in a
>>> better overall end result? If so, why?
>>>
>>> * 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?
>>>
>>> * That Kaffe/Classpath are somehow flawed and that it is
>>> necessary to
>>> start again?
>>>
>>> * 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?
>>>
>>> Regards,
>>>
>>> Simon
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.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:05 AM, Simon Kitching wrote:
> On Sat, 2005-05-07 at 15:52 +1200, Simon Kitching wrote:
>
>> Sorry, the previous email was sent incomplete. I'll try again..
>>
>> On Sat, 2005-05-07 at 15:45 +1200, Simon Kitching wrote:
>>
>>> On Fri, 2005-05-06 at 23:10 -0400, Noel J. Bergman wrote:
>>>
>>>> Simon Kitching wrote:
>>>>
>>>>
>>>>> legally isn't it impossible for a GPL'd project and an
>>>>> ASF'd project to *have* "synergies"?
>>>>>
>>>>
>>>> Not at all. Individual authors may contribute their own
>>>> original works, and
>>>> do not give up that right. Furthermore, we can design
>>>> architectures and
>>>> interface specifications that permit pluggability while
>>>> isolating client
>>>> code from the implementation (and license) of the pluggable.
>>>> Think how JDBC
>>>> or JNDI isolate the code from the service provider classes.
>>>> That doesn't
>>>> solve distribution issues caused by licensing, but it does
>>>> address a coding
>>>> issue.
>>>>
>>>> Right now we're putting a structure -- process and community --
>>>> in place.
>>>> The goal is to work WITH others. As with all other ASF
>>>> projects, we'll be
>>>> very careful about provenance when accepting code.
>>>>
>>>
>>>
>> But why bother to "work with others"? Why not just join the
>> existing GNU
>> Classpath and Kaffe projects and work within them?
>>
>> Classpath appears to have no current competitors; it is clearly *the*
>> free java class library implementation. And while the GPL/LGPL may
>> not
>> be the perfect license for every situation it seems perfectly
>> reasonable
>> to me here. Geir indicated in a reply to my earlier posting that
>> there
>> were no specific objections to the Classpath license.
>>
>> Creating a new project whose purpose is to implement the java core
>> libraries surely *must* draw developers away from contributing to GNU
>> Classpath, as well as wasting vasts amount of programmer time (unless
>> major relicensing from GNU Classpath is possible). I still don't
>> understand what benefits might arise from this.
>>
>
> Sorry, I misrepresented Geir a bit here. Geir *did* indicate a
> hypothetical situation in which a company could generate a proprietory
> product based on an APL classlib but not a GPL'd one.
>
Thank you. The GPL isn't ok for ASF project, and I don't believe
that I have said anything to indicate otherwise.
The GPL isn't the license of choice for many people, including me,
just like the AL isn't for many... As you can see, I'm not
interested in a license debate. I had a long one with Dalibor and
Simon Phipps in Brazil - the only solution we could come up with the
resolve things was to eat more of the excellent beef they serve
there. We did that several nights in a row :)
> The example is fairly unlikely, though. I personally feel that the
> possible gain by allowing this doesn't make up for the damage
> likely to
> be done to GNU Classpath by drawing developers/users from that
> project.
>
> Note that Classpath implements *exactly* the Sun specs. So there isn't
> much room for proprietory innovation (which is what APL would allow).
Well, I would think there are plenty of places for proprietary (and
otherwise) innovation in the class library. The API and behavior
must be compatible, but how you get there is up to you.
>
>
>>
>> The JVM (ie reimplementing what Kaffe does) is a similar
>> situation. What
>> gain is there to create another JVM rather than joining the existing
>> Kaffe project and working within it?
>>
>
> Kaffe *is* a little different. I can see companies adapting an
> existing
> JVM to perform proprietory stuff, even to implementing proprietory
> (non-java) languages (or, as in Geir's example, optimising for a
> particular hardware platform). And an APL'd version would allow
> developers to learn how a VM implementation works without any worries
> about future accusations of violating the GPL by copying into a later
> proprietory project.
>
> I still personally would like to see Kaffe complete before a competing
> project is started, though.
I personally wish Kaffe well, and have no interest in hurting it. I
have every interest in working with Dalibor and meeting other Kaffe
people, and hope that where we can work together is productive for
them, for us, and any other VM project out there.
I think that it's way too early in this "New Era of Managed Runtime
Environments" to think that one is enough, no matter what the licensing.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.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 Simon Kitching <sk...@apache.org>.
On Sat, 2005-05-07 at 15:52 +1200, Simon Kitching wrote:
> Sorry, the previous email was sent incomplete. I'll try again..
>
> On Sat, 2005-05-07 at 15:45 +1200, Simon Kitching wrote:
> > On Fri, 2005-05-06 at 23:10 -0400, Noel J. Bergman wrote:
> > > Simon Kitching wrote:
> > >
> > > > legally isn't it impossible for a GPL'd project and an
> > > > ASF'd project to *have* "synergies"?
> > >
> > > Not at all. Individual authors may contribute their own original works, and
> > > do not give up that right. Furthermore, we can design architectures and
> > > interface specifications that permit pluggability while isolating client
> > > code from the implementation (and license) of the pluggable. Think how JDBC
> > > or JNDI isolate the code from the service provider classes. That doesn't
> > > solve distribution issues caused by licensing, but it does address a coding
> > > issue.
> > >
> > > Right now we're putting a structure -- process and community -- in place.
> > > The goal is to work WITH others. As with all other ASF projects, we'll be
> > > very careful about provenance when accepting code.
> >
> But why bother to "work with others"? Why not just join the existing GNU
> Classpath and Kaffe projects and work within them?
>
> Classpath appears to have no current competitors; it is clearly *the*
> free java class library implementation. And while the GPL/LGPL may not
> be the perfect license for every situation it seems perfectly reasonable
> to me here. Geir indicated in a reply to my earlier posting that there
> were no specific objections to the Classpath license.
>
> Creating a new project whose purpose is to implement the java core
> libraries surely *must* draw developers away from contributing to GNU
> Classpath, as well as wasting vasts amount of programmer time (unless
> major relicensing from GNU Classpath is possible). I still don't
> understand what benefits might arise from this.
Sorry, I misrepresented Geir a bit here. Geir *did* indicate a
hypothetical situation in which a company could generate a proprietory
product based on an APL classlib but not a GPL'd one.
The example is fairly unlikely, though. I personally feel that the
possible gain by allowing this doesn't make up for the damage likely to
be done to GNU Classpath by drawing developers/users from that project.
Note that Classpath implements *exactly* the Sun specs. So there isn't
much room for proprietory innovation (which is what APL would allow).
>
> The JVM (ie reimplementing what Kaffe does) is a similar situation. What
> gain is there to create another JVM rather than joining the existing
> Kaffe project and working within it?
Kaffe *is* a little different. I can see companies adapting an existing
JVM to perform proprietory stuff, even to implementing proprietory
(non-java) languages (or, as in Geir's example, optimising for a
particular hardware platform). And an APL'd version would allow
developers to learn how a VM implementation works without any worries
about future accusations of violating the GPL by copying into a later
proprietory project.
I still personally would like to see Kaffe complete before a competing
project is started, though.
Regards,
Simon
---------------------------------------------------------------------
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 "Roy T. Fielding" <fi...@gbiv.com>.
On May 7, 2005, at 12:38 PM, Paul Hammant wrote:
> Unless I am mistaken, Apache licensed code will never be able to
> 'legally' import GPL code.
You are mistaken -- the copyright owner can do whatever they want,
as can users. It is only redistributors that are constrained on
how they can combine and redistribute.
> The logic behind this -
>
> GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot
> currently Apache licensed. That may well be worked out with an
> revision to the Apache Software License 2.0.
It is only an opinion of the FSF. It makes no difference to anyone
else and certainly isn't based on law.
> BSD (etc) is not currently able to import GPL licensed code.
Sure it is. It just can't turn around and redistribute the combination
as anything other than GPL.
> Why would Apache licensed code be any different even if the current
> issue were worked thru?
>
> Its the lack of a reciprocal arrangement on legal/allowed importing
> that is the long term blocker on ASF / FSF cooperation.
The FSF does not have reciprocal arrangements -- the GPL is all or
nothing. The Apache License is already reciprocal in nature -- as
far as we are concerned, GPL projects are free to incorporate and
redistribute our code.
....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 Mark Wielaard <ma...@klomp.org>.
Hi,
On Sun, 2005-05-08 at 06:42 -0400, Sam Ruby wrote:
> My point here is not that the above is wrong. My point is simply that
> these issues are hard.
>
> Nor do I mean to single out classpath. The ASF, for example, takes
> equal care in evaluating dependencies, ensuring that projects that may
> wish to make use our work are able to do so.
>
> I suspect that the only robust solution to this will be to do the hard
> work to make the various license compatible with one another.
Agreed on all points! I hope for harmony we can build consensus to use
distribution terms that are both acceptable to the GNU community and
projects which need to be able to be used in larger works distributed
under the GPL and to the Apache community and projects which need to be
able to be used in larger works distributed under the ASL. At the same
times we must certainly attack the larger GPL/ASL issue. And I do hope
we will be able to finally solve those since most of them are just legal
technicalities and misunderstandings/misinterpretations (blown way out
of proportion imho).
Cheeers,
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 Sam Ruby <ru...@apache.org>.
Mark Wielaard wrote:
> Hi,
>
> On Sat, 2005-05-07 at 14:38 -0500, Paul Hammant wrote:
>
>>GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot
>>currently Apache licensed. That may well be worked out with an
>>revision to the Apache Software License 2.0.
>>
>>BSD (etc) is not currently able to import GPL licensed code.
>>
>>Why would Apache licensed code be any different even if the current
>>issue were worked thru?
>
> For project Harmony we (FSF with GNU Classpath) are willing to use
> explicit exceptions to the GPL to make mixing and matching with Apache
> licensed code possible. Of course we cannot promise that every GPLed
> project out there wants to make the same compromises in the sake of
> cooperation.
Consider your words of yesterday:
> 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.
My point here is not that the above is wrong. My point is simply that
these issues are hard.
Nor do I mean to single out classpath. The ASF, for example, takes
equal care in evaluating dependencies, ensuring that projects that may
wish to make use our work are able to do so.
I suspect that the only robust solution to this will be to do the hard
work to make the various license compatible with one another.
- Sam Ruby
---------------------------------------------------------------------
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 Mark Wielaard <ma...@klomp.org>.
Hi,
On Sat, 2005-05-07 at 14:38 -0500, Paul Hammant wrote:
> GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot
> currently Apache licensed. That may well be worked out with an
> revision to the Apache Software License 2.0.
>
> BSD (etc) is not currently able to import GPL licensed code.
>
> Why would Apache licensed code be any different even if the current
> issue were worked thru?
For project Harmony we (FSF with GNU Classpath) are willing to use
explicit exceptions to the GPL to make mixing and matching with Apache
licensed code possible. Of course we cannot promise that every GPLed
project out there wants to make the same compromises in the sake of
cooperation.
When the Netscape dual-licensed their javascript code under both the NPL
and GPL (which was later extended to all Mozilla projects with their
tripple-license under MPL/GPL/LGPL) we got Richard Stallman to give the
following statement:
> "On behalf of the GNU Project, I would like to thank Netscape for
> making the interpreter for the JavaScript language available under the
> terms of the GNU GPL as well as under the NPL. I would like to ask
> all programmers who make changes in this interpreter to give Netscape
> their fullest cooperation in mutual use of these changes, and to
> release these changes under the NPL as well as the GPL."
It would be nice if we could get a similar statement of intend when we
fix the GPL/Apache license incompatability.
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 Paul Hammant <Pa...@ThoughtWorks.net>.
> If we want to integrate any new code produced by the Harmany effort
> into
> any of the existing projects, many of which are under the GPL or only
> accept code compatible with the GPL, and since the Apache Incubator
> terms allow modern BSD, MIT/X or MIT/W3C terms I think that is probably
> the best we can do for now. But as said before if we can (ab)use the
> Harmony project to get a strong signal to BOTH the FSF and ASF to fix
> any remaining incompatabilities between (L)GPL and ASL then lets do
> that!
Unless I am mistaken, Apache licensed code will never be able to
'legally' import GPL code.
The logic behind this -
GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot
currently Apache licensed. That may well be worked out with an
revision to the Apache Software License 2.0.
BSD (etc) is not currently able to import GPL licensed code.
Why would Apache licensed code be any different even if the current
issue were worked thru?
Its the lack of a reciprocal arrangement on legal/allowed importing
that is the long term blocker on ASF / FSF cooperation.
- Paul
---------------------------------------------------------------------
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 Mark Wielaard <ma...@klomp.org>.
Hi,
On Sat, 2005-05-07 at 00:26 -0400, Noel J. Bergman wrote:
> > But why bother to "work with others"? Why not just join the existing GNU
> > Classpath and Kaffe projects and work within them?
>
> > Geir indicated in a reply to my earlier posting that there were
> > no specific objections to the Classpath license.
>
> There is a list of issues with both the LGPL and the GPL+Exception for which
> I do not believe we have satisfactory answers. There is an on-going effort
> to get the issues resolved, and that could be part of what comes out of
> Harmony. Remember that Harmony is about creating a reusable and free Java
> platform. It would not have to recreate Classpath if Classpath were
> available to use. As Mark noted in his e-mail, that is not currently the
> case.
Just to be completely clear about the issues.
Obviously it is hard to "just solve" the general (L)GPL and ASL
incompatabilities. But I have some hope that we know what the legal
issues are now and that there can be some general resolution to make
mixing and matching code from the two community possible in the future.
For the specific case of GNU Classpath being integrated into a larger
"Harmony" work the issue is a little simpler. All copyright in this work
are assigned to the FSF and we already have a special exception that
allows the core class libraries to be used by a project distributed
under the ASL. At least that is what we think. If that is currently not
the case then we will certainly change the wording of the specific GPL
exception statement as used by GNU Classpath to make that more clear.
If we want to integrate any new code produced by the Harmany effort into
any of the existing projects, many of which are under the GPL or only
accept code compatible with the GPL, and since the Apache Incubator
terms allow modern BSD, MIT/X or MIT/W3C terms I think that is probably
the best we can do for now. But as said before if we can (ab)use the
Harmony project to get a strong signal to BOTH the FSF and ASF to fix
any remaining incompatabilities between (L)GPL and ASL then lets do
that!
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:26 -0400, Noel J. Bergman wrote:
> > But why bother to "work with others"? Why not just join the existing GNU
> > Classpath and Kaffe projects and work within them?
>
> > Geir indicated in a reply to my earlier posting that there were
> > no specific objections to the Classpath license.
>
> There is a list of issues with both the LGPL and the GPL+Exception for which
> I do not believe we have satisfactory answers. There is an on-going effort
> to get the issues resolved, and that could be part of what comes out of
> Harmony. Remember that Harmony is about creating a reusable and free Java
> platform. It would not have to recreate Classpath if Classpath were
> available to use. As Mark noted in his e-mail, that is not currently the
> case.
Just to be completely clear about the issues.
Obviously it is hard to "just solve" the general (L)GPL and ASL
incompatabilities. But I have some hope that we know what the legal
issues are now and that there can be some general resolution to make
mixing and matching code from the two community possible in the future.
For the specific case of GNU Classpath being integrated into a larger
"Harmony" work the issue is a little simpler. All copyright in this work
are assigned to the FSF and we already have a special exception that
allows the core class libraries to be used by a project distributed
under the ASL. At least that is what we think. If that is currently not
the case then we will certainly change the wording of the specific GPL
exception statement as used by GNU Classpath to make that more clear.
If we want to integrate any new code produced by the Harmany effort into
any of the existing projects, many of which are under the GPL or only
accept code compatible with the GPL, and since the Apache Incubator
terms allow modern BSD, MIT/X or MIT/W3C terms I think that is probably
the best we can do for now. But as said before if we can (ab)use the
Harmony project to get a strong signal to BOTH the FSF and ASF to fix
any remaining incompatabilities between (L)GPL and ASL then lets do
that!
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 "Noel J. Bergman" <no...@devtech.com>.
> But why bother to "work with others"? Why not just join the existing GNU
> Classpath and Kaffe projects and work within them?
> Geir indicated in a reply to my earlier posting that there were
> no specific objections to the Classpath license.
There is a list of issues with both the LGPL and the GPL+Exception for which
I do not believe we have satisfactory answers. There is an on-going effort
to get the issues resolved, and that could be part of what comes out of
Harmony. Remember that Harmony is about creating a reusable and free Java
platform. It would not have to recreate Classpath if Classpath were
available to use. As Mark noted in his e-mail, that is not currently the
case.
--- 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 Simon Kitching <sk...@apache.org>.
Sorry, the previous email was sent incomplete. I'll try again..
On Sat, 2005-05-07 at 15:45 +1200, Simon Kitching wrote:
> On Fri, 2005-05-06 at 23:10 -0400, Noel J. Bergman wrote:
> > Simon Kitching wrote:
> >
> > > legally isn't it impossible for a GPL'd project and an
> > > ASF'd project to *have* "synergies"?
> >
> > Not at all. Individual authors may contribute their own original works, and
> > do not give up that right. Furthermore, we can design architectures and
> > interface specifications that permit pluggability while isolating client
> > code from the implementation (and license) of the pluggable. Think how JDBC
> > or JNDI isolate the code from the service provider classes. That doesn't
> > solve distribution issues caused by licensing, but it does address a coding
> > issue.
> >
> > Right now we're putting a structure -- process and community -- in place.
> > The goal is to work WITH others. As with all other ASF projects, we'll be
> > very careful about provenance when accepting code.
>
But why bother to "work with others"? Why not just join the existing GNU
Classpath and Kaffe projects and work within them?
Classpath appears to have no current competitors; it is clearly *the*
free java class library implementation. And while the GPL/LGPL may not
be the perfect license for every situation it seems perfectly reasonable
to me here. Geir indicated in a reply to my earlier posting that there
were no specific objections to the Classpath license.
Creating a new project whose purpose is to implement the java core
libraries surely *must* draw developers away from contributing to GNU
Classpath, as well as wasting vasts amount of programmer time (unless
major relicensing from GNU Classpath is possible). I still don't
understand what benefits might arise from this.
The JVM (ie reimplementing what Kaffe does) is a similar situation. What
gain is there to create another JVM rather than joining the existing
Kaffe project and working within it?
Regards,
Simon
---------------------------------------------------------------------
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 Simon Kitching <sk...@apache.org>.
On Fri, 2005-05-06 at 23:10 -0400, Noel J. Bergman wrote:
> Simon Kitching wrote:
>
> > legally isn't it impossible for a GPL'd project and an
> > ASF'd project to *have* "synergies"?
>
> Not at all. Individual authors may contribute their own original works, and
> do not give up that right. Furthermore, we can design architectures and
> interface specifications that permit pluggability while isolating client
> code from the implementation (and license) of the pluggable. Think how JDBC
> or JNDI isolate the code from the service provider classes. That doesn't
> solve distribution issues caused by licensing, but it does address a coding
> issue.
>
> Right now we're putting a structure -- process and community -- in place.
> The goal is to work WITH others. As with all other ASF projects, we'll be
> very careful about provenance when accepting code.
But why bother to "work with others"? Why not just join the existing GNU
Classpath and Kaffe projects and work within th
>
> The Apache Harmony Project is about finding the "harmonics" -- projects and
> people with whom to collaborate -- bring them together. And don't forget
> that we have a bunch of harmonics here already. JNDI code with the
> Directory project. JDBC code with Derby. Regex code in Jakarta. APR.
> Lots of really good and usable code. And we already have other people
> recommending additional harmonics to work with us. And some of the
> synergies have just amazing potential.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.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 "Noel J. Bergman" <no...@devtech.com>.
Simon Kitching wrote:
> legally isn't it impossible for a GPL'd project and an
> ASF'd project to *have* "synergies"?
Not at all. Individual authors may contribute their own original works, and
do not give up that right. Furthermore, we can design architectures and
interface specifications that permit pluggability while isolating client
code from the implementation (and license) of the pluggable. Think how JDBC
or JNDI isolate the code from the service provider classes. That doesn't
solve distribution issues caused by licensing, but it does address a coding
issue.
Right now we're putting a structure -- process and community -- in place.
The goal is to work WITH others. As with all other ASF projects, we'll be
very careful about provenance when accepting code.
The Apache Harmony Project is about finding the "harmonics" -- projects and
people with whom to collaborate -- bring them together. And don't forget
that we have a bunch of harmonics here already. JNDI code with the
Directory project. JDBC code with Derby. Regex code in Jakarta. APR.
Lots of really good and usable code. And we already have other people
recommending additional harmonics to work with us. And some of the
synergies have just amazing potential.
--- 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 Simon Kitching <sk...@apache.org>.
Unfortunately, legally isn't it impossible for a GPL'd project and an
ASF'd project to *have* "synergies"?
If GNU (who presumably have a copyright on all the Classpath code) are
willing to relicense under the APL, then that would work. Same for Kaffe
(though probably more difficult unless Kaffe require copyright
assignment as part of contributions as GNU do). But the proposal
document doesn't state either. Without that, only general "design
principles" can be shared between Harmony and these projects, which
really isn't of much use in the Classpath case as the classes must
adhere to the Sun TCK which must be pretty detailed on library class
behaviour. Sharing design discussions with Kaffe developers may be
somewhat more productive, but even so 90% of the work is in the code -
which cannot be transferred to an APL-licensed project.
This proposal seems *so* much work to reimplement stuff already done
under the GPL (unless that code can be relicensed as described above).
I'm curious to know what the benefit of all that work is..
Regards,
Simon
On Fri, 2005-05-06 at 22:34 -0400, Davanum Srinivas wrote:
> Simon,
>
> 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.
>
> -- dims
>
> On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
> > Hi,
> >
> > Can someone clarify for me why Harmony is being proposed when GNU
> > Classpath, Kaffe and other projects are quite a long way to satisfying
> > the goal of a Free Java environment?
> > Is it:
> >
> > * 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?
> >
> > * That you feel that more contributors will be involved in an
> > Apache-licensed project than in a GPL-licensed project, resulting in a
> > better overall end result? If so, why?
> >
> > * 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?
> >
> > * That Kaffe/Classpath are somehow flawed and that it is necessary to
> > start again?
> >
> > * 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?
> >
> > Regards,
> >
> > Simon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.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 Mark Wielaard <ma...@klomp.org>.
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 Davanum Srinivas <da...@gmail.com>.
Simon,
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.
-- dims
On 5/6/05, Simon Kitching <sk...@apache.org> wrote:
> Hi,
>
> Can someone clarify for me why Harmony is being proposed when GNU
> Classpath, Kaffe and other projects are quite a long way to satisfying
> the goal of a Free Java environment?
> Is it:
>
> * 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?
>
> * That you feel that more contributors will be involved in an
> Apache-licensed project than in a GPL-licensed project, resulting in a
> better overall end result? If so, why?
>
> * 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?
>
> * That Kaffe/Classpath are somehow flawed and that it is necessary to
> start again?
>
> * 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?
>
> Regards,
>
> Simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
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...@optonline.net>.
On May 6, 2005, at 11:12 PM, Henri Yandell wrote:
> On 5/6/05, Sam Ruby <ru...@apache.org> wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>
>>>
>> [snip]
>>
>> Suggestion: the way to encourage people to move to the
>> harmony-dev@incubator.apache.org mailing list is to stop
>> responding to
>> questions posted here.
>>
>> It only encourages them.
>>
>
> +1
>
> My new harmony folder is sad without any entries.
to be fair, we aren't talking about harmony technology, design or
related, but "meta-harmony" about purpose and motivation...
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.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 Henri Yandell <fl...@gmail.com>.
On 5/6/05, Sam Ruby <ru...@apache.org> wrote:
> Geir Magnusson Jr. wrote:
> >
> [snip]
>
> Suggestion: the way to encourage people to move to the
> harmony-dev@incubator.apache.org mailing list is to stop responding to
> questions posted here.
>
> It only encourages them.
+1
My new harmony folder is sad without any entries.
Hen
---------------------------------------------------------------------
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 Simon Kitching <sk...@apache.org>.
On Fri, 2005-05-06 at 23:04 -0400, Sam Ruby wrote:
> Geir Magnusson Jr. wrote:
> >
> [snip]
>
> Suggestion: the way to encourage people to move to the
> harmony-dev@incubator.apache.org mailing list is to stop responding to
> questions posted here.
>
> It only encourages them.
I'm happy to ask future questions on harmony-dev if it is the
appropriate list. However what I am asking about is really related to
*whether* Harmony should be accepted as an Incubator project (ie it's
related to the current VOTE thread on this list). Isn't this list
therefore the correct forum for that discussion?
Please let me know; I'm subscribed to harmony-dev and am happy to follow
up there if it's a better place.
Regards,
Simon
---------------------------------------------------------------------
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>.
Geir Magnusson Jr. wrote:
>
[snip]
Suggestion: the way to encourage people to move to the
harmony-dev@incubator.apache.org mailing list is to stop responding to
questions posted here.
It only encourages them.
- Sam Ruby
---------------------------------------------------------------------
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 6, 2005, at 10:26 PM, Simon Kitching wrote:
> Hi,
>
> Can someone clarify for me why Harmony is being proposed when GNU
> Classpath, Kaffe and other projects are quite a long way to satisfying
> the goal of a Free Java environment?
>
> Is it:
>
> * 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?
No. I fully expect Sun to grant the TCK to a GPL-licensed project
when the time is right - I don't think that there are any limitations
around the license under which an OSS project chooses to work.
Certainly that isn't what Apache was striving for in it's JCP efforts
(when Jason Hunter was JCP rep) when the JSPA was changed to allow
OSS impls, and it's not a limitation we'd support now.
>
> * That you feel that more contributors will be involved in an
> Apache-licensed project than in a GPL-licensed project, resulting in a
> better overall end result? If so, why?
It remains to be seen. Clearly people have license preferences.
It's clear that there are contributors that only wish to contribute
to GPL-licensed projects. Similarly, there are contributors that only
wish to contribute to BSD or other no-copyleft or weak-copyleft
licenses.
What we're trying to do is two things - do an implementation under
the Apache License (that's how we license things at the ASF...) but
at the same time, collaborate with any other interested people,
communities and organizations so that we can share and interchange as
much as we can. And when we fix the license incompatibility issues,
we'll be able to share more.
>
> * 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?
What if you wanted to extend it in a proprietary way? Suppose you
had a killer GC implementation that you wanted to try to build a
business around (ok, farfetched, but you grok the intent...)? or
wanted to tune it for your hardware w/o giving what could be
proprietary techniques away?
I don't want to debate GPL vs AL vs CDDL vs MPL vs ... here.
The fact is, we have a big community around us that has an interest,
and the ASF is willing (if the PMC approves) to give us a shot to try.
>
> * That Kaffe/Classpath are somehow flawed and that it is necessary to
> start again?
No. Kaffe and GNU Classpath people will be participating and
observing. This is an open project, and people from Kaffe and GNU
Classpath have been invited and helped get the conversation started.
Lets bridge these communities in whatever way we can. We can't do it
w/ licenses (although we're working on it) so we'll do it w/
technology and design.
>
> * 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?
No, I don't think that's anyone motivation. We aren't thinking about
this as anti-Kaffe or anti-GNU Classpath, but rather pro Java, pro
independent implementation, and pro community. We've been building
relationships and friendships with the people in those communities
and I'd like to keep working with them, not alienate them.
geir
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org