Skip to main content

I think, there could be existing a unique Java-license

21 replies [Last post]
theuserbl
Offline
Joined: 2004-05-04
Points: 0

There are some comments like at
http://www.vnunet.com/vnunet/news/2163078/open-source-java-licence
where people say, that every license decision would make problems.

Either the Apache Harmony people or the GNU Classpath people would be unhappy with the license, Sun would choose.

But I don't think so.

For this, I want to go back in the history of OpenSource Java.

In November 2000 GNU Classpath have published it first version of GNU Classpath
http://www.gnu.org/software/classpath/downloads/20001120.html

It have had a much more liberal license then Kaffe, which only was licensed under GPL.
Later GNU Classpath has also makes its license much more liberal. Under the GPL with linking exception. This means, it is alowed to compile and link the GNU Classpath files against other files of any other license.

A little bit more later, Kaffe ported GNU Classpath to its platform. So there existing different OpenSource JVMs, but oonly one OpenSource class-library: GNU Classpath.

Also important is, that it was created, because there existing before no OpenSource Java library. If there would be existing already an OpenSource Java under the Apache or BSD license, then it would never be started, I think.

2005 Apache started the Harmony project. Still today I can't understand, how so much motivation can be existing, to begin a new OpenSource Java, where already an OpenSource Java exists (GNU Classpath), where it is allowed to link (statical and dynamical) against other files of any other license.

The Apache people have started the Harmony-project, because they are unhappy with the GNU Classpath license. But I think, the GNU Classpath people don't have so much problems with other licenses.

For example the GPL 3 will be allowing generelly to link against other OpenSource files.
And Tom Tromey planned to integrate the Eclipse Compiler for Java (ecj), which is licensed under the Eclipse license (and not any GNU lincense) in the new gcj/gcjx (a frontend for the GCC):
http://tromey.com/blog/?p=6
http://tromey.com/blog/?p=9
http://tromey.com/blog/?p=10

So I think, there existing for GNU Classpath people no fears of contacts with other OpenSource-licenses.

The things, why GNU Classpath don't working together on Apache Harmony is that GNU Classpath
- existing long before Apache Harmony
- is much more advanced
- don't understand (like me), why Apache have started a new project, where alaredy GNU Classpath exists.

But if Sun makes its Java OpenSource, then the code of this Java exists much longer then the GNU Classpath code. And the code is much more advanced and stable then the GNU Classpath code.

I think, in this case it would make sense, that GNU Classpath developer change from its Java implementation to Suns implementation.

The only problem which then exists, to show the developers a new way. The wind have changed. It is no longer necessary to rewrite the JDK. The new activity is to help improving Suns Java. And accept, that possible no of the GNU Classpath code (and so of your six years old work) would be integrated in Suns JDK.

And now a question to GNU Classpath people (ans especialy to the leader ark Wielaard:

The qoal is to bring Apache Harmony, GNU Classpath and Suns Java together.

What must be happen to leave GNU Classpath and working instead of that on Suns Java. Improving it and fixing bugs on it? (more then one answer is allowed)

a) "Nothing. I am only familiar with GNU Classpath. It needs to much time, to undertand other code"

b) "It must be a GNU project. Sun must sign a Copyright-Assignment, to give the copyright to the FSF, only then I would work on the code"

c) "under the GPL + linking exception (like the GNU Classpath license)"

d) "under a GPL license"

e) "under a LGPL license"

f) "the BSD license is ok. If ift oukld be BSD, I would also change to Suns Java"

g) "the Apache license is ok ..."

h) "the CDDL license is ok ..."

Greatings
theuserbl

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02
Points: 0

>
> > So I think, that - if Sun makes its Java OpenSource
> - it would be a bad thing, if then GNU Classpath and
> Apache Harmony still exists.
>
> That's an opinion I'd heavily disagree with, as I
> don't think that existence of any free software is a
> bad thing.
>
Too many competing projects that all strive to do the same thing causes stagnation as there won't be enough resources to fuel all of them.
Spread the limited pool of people and time too thin and everything stalls.

Whether 3 is too many or not enough is another debate (but of course there are more than 3 already).

> I really think you're trying to solve a problem noone
> else sees as a big deal: neither Sun, nor anyone else
> making free or non-free Java implementations seems to
> be interested in rooting out the other VMs, afaict,
> and never was.
>
hmm, not quite sure I agree with that. There seems to be a lot of animosity towards Sun in certain circles.

> Free software development is not at all like a
> Highlander movie.
>
Tell that to the Linux zealots who're paramount to destroy all others.
Maybe no longer the majority of users, but they still exist in numbers.

> Everyone is interested in seeing full compatibility
> between different implementations of the standards.

Nope. Quite a few people aren't. They don't care what the rest of the world does as long as what they want gets done and will happily break the standard to get their way.

> There are many ways to encourage and get that, from
> releasing the TCKs under friendly licenses, to
> opening the reference implementation under suitable
> licensing conditions so that it can be shared and

That would be disaster. Everyone would be able to change the language spec and TCK and call it Java with noone there to control it.

> worked on together, to working more closely on JSRs.

There would be no more need for JSRs in that scenario as every kid in his bedroom could create an extension to the language spec on his own.

> The approach you seem to have chosen, though, is to
> try to figure out what it would take to make sure
> other projects drop dead. That does not sound very

It's good to figure out what would cause the Sun implementation to be killed off and do whatever it takes to avoid that scenario.
Know thine enemies so you can more effectively defeat them.

> any project. Holding a gun to anyone's head to debate
> hypothetical scenarios under which they'd give up
> what they have and 'switch' to something else they
> don't know yet, is either way just wasting their good
> will and time, as one could have learned from mailing
> list posts trying to get GNU Classpath to switch to
> Harmony or vice versa. Groups of free people don't
> function that way: you push them in one direction
> from outside, they'll usually shove you back.
>
Yet that's exactly what Sun's being told. That they should abandon their entire effort and join Harmony instead.
They're being told that by their historical antagoniser which has a LOT of resources at their disposal to corrupt an open source JDK: IBM.

> In a similar way to ESR's and IBM's old 'open letter
> campaigns' to drag Sun kicking and screaming into
> licensing the RI under an open source license, your
> approach is doing your cause not much good, afaict.
>
ESR and IBM have succeeded... Sun has submitted to their demands.

neugens
Offline
Joined: 2006-01-31
Points: 0

> But the GNU Classpath license allows it to compile any file of any license against GNU Classpath files.

But you cannot mix the code, which is, in my opinion, what is really needed.

theuserbl
Offline
Joined: 2004-05-04
Points: 0

My answer to Roman on the Classpath list:

[i]>>Now I have a little bit time, to reply to your comment (I will also
>>write this reply in the forum at
>>http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0 ).
>
>Yeah thanks. Please also include my other replies if you see fit.

Done.

>>I think three different OpenSource implementations would be the
>>worst case scenario, if Sun makes its Java OpenSource.
>>Ans I also think, that Suns sees so like I. And I think they want
>>to make it OpenSource, to have _not_ three different
>>implementations.
>
>I disagree. Actually there are already quite a couple of
>(proprietary) implementations of the Java platform which is also
>fine for Sun, so why would it be bad for Java to have a couple more?

The diffrent proprietary implementations are based on Suns Java. So it is unlikly that they are more different to Suns Java, then having a completly new and different implementation.
Or to show it with browsers: Safari is also a proprietary browser based on KHTML. But it is more compatible to Konquerer then to other browsers.

>Well, first thing is, the technical POV is not the only one
>important to some parties. For example, if Sun would decide to
>choose to license under GPL, that would be a problem for a reason
>for some parties to use Classpath or Harmony. Then there are already
>a couple of VMs that are written to use GNU Classpath and it is
>probably not trivial to port them to use Sun's class libraries. Then
>I'm sure there are even some interesting parts in GNU Classpath. I'm
>thinking about the Gnome/Cairo peers that fit better with common
>Linux platforms than the Motif based peers that Sun has.

A different you only feel if you use AWT. But if you use Swing there isn't much different, which peers are used.

> I am not
>sure about GNU Crypto but my feeling is that we cover some areas
>that are not covered by Sun there (and vice versa of course).

In this case a merger would be better, I think.

>In the
>future there could also be interesting cooperation, I am think about
>the AWT/Swing area here, where GNU Classpath could possibly focus on
>specialized peers and Swing L&Fs for Gnome and KDE, while Sun
>focuses more on the core or something similar. Likewise for other
>areas too, where Classpath and/or Harmony could work one
>implementing the glue to specific platforms that Sun doesn't want to
>care about etc etc.

Hmmm... but I still think, it would be better to use Suns Java then for other platforms.
There is a difference, if you have one program and port it to different platforms or if you use a complete new written version
For example there existing NeoOffice, which is a fork of OpenOffice.org. But they are functional the same. But KOffice and OpenOffice.org are _completely_ different.
One of the reasons is, that OpenOffice.org and NeoOffice have the most parts the same code.

>>A good comparision of the different Java-implementations would be
>>the situation with the different Browsers. All Internet-Browsers
>>want to show the internet-sides. So all takes the same resources
>>and wants to do the same with it.
>
>I also don't think that it's a good idea to have only one browser. I
>am quite happy that there are a couple of them and that everybody
>can pick whatever he likes best. I think it's good to have IE,
>Mozilla, Opera, Konqueror etc all around. The browser situation
>actually is a good example why having several implementations is a
>good thing. Think when IE had a marketshare of >95%. This is
>(arguably was) a time of stagnation, Webdesigners forced to use ugly
>hacks to make their pages load etc. Having more then one
>implementation in the market produces an interesting competition and
>somewhat forces everybody involved to write code that is portable.

The direction, which new features browser have to implement, makes the W3C. Since over five years, the W3C have decided, that SVG-files can be shown in browsers. And how SVG files can be interact with JavaScript andf HTML.
Firefox have implemented SVG. Would Firefox the only browser, then there would already a lot of SVG-pictures on some sides existing. But now we must wait until the last browser also supports SVG.

It is also to mention, that SVG isn't fast to implement. And SVG-viewer and -editors are also different then browser-implementations. So there existing SVG-files, which you can see in Inkscape, but not with Apache Batik. Or with Batik, but not with Firefox. Or with Firefox, but not in KDE (KSVG). Or with KDE and not with GNOME (libsvg or librsvg). Or with GNOME, but not with Inkscape.

So, if other browsers are also implementing SVG, there would be SVG-files, which you then also only on one of the browsers can see, but not on the other one.

And imaging, then the JCP decide, that SVG will be part of Java.
The Harmony people can make use of its Batik. Sun have in its Java-implementation already Apache-code, so for Suns implementation it would also no make problems. But Batik is neither under the GNU Classpath license nor have the autors of it signed the Copyright-Assignment, to give the FSF the copyright. So then, GNU Classpath would to reimplement also SVG and the whole problem comes also to Classpath.

>The very same thing holds true for Java and actually we already see
>the bad effects of the dominance of the Sun implementation, which is
>that many developers write their code against undocumented API,
>against Sun specific bugs etc etc. That wouldn't be possible when we
>had several implementations sharing the market equally.

You are right. All have it pros and contras.
On the other side: If Suns implementation is the only one and OpenSource, why not document the undocumented API and make it official?
Important is only, that the API isn't platformdependent.

>I thinnk what you and Sun (and many other devlopers) actually care
>about is not having several implementations of the platform (which
>we already have, even outside of the Sun/GNU/Apache world), but the
>problem of keeping them together and most importantly _compatible_.
>That means that a program written against one implementation should
>run on other implementations too. (given that the program doesn't
>use non-public API and doesn't make use of bugs/special behaviour of
>one impl). In order to avoid that, Sun would need to make the TCK
>more open. I think this has already been said and I don't felt the
>need to repeat this. So what I think would be helpful for Java, Sun,
>and the GNU and Apache community is 1) a sane license to allow
>cooperation and code exchange and 2) opening up the TCK so that all
>3 implementations can be compatible.

You are right, an open TCK would be nice. But the TCK can not test all. And implementations with the same code, are mostly more compatible to each other, then implementations with different code.

Or to mention the pixelgraphic-fomat png: As I know, there existing also only _one_ implementation of png: libpng. All programs are using it. And it have no disadvantage, of having not a second or third implementation of it.
Respectively one other implementation of it exists. It comes from Microsoft and Microsoft use it in its InternetExplorer. But that implementation have problems with transparency in png-files.

Greatings
Patrick -- alias theuserbl[/i]

chris_gray
Offline
Joined: 2005-11-08
Points: 0

> Or to mention the pixelgraphic-fomat png: As I know,
> there existing also only _one_ implementation of png:
> libpng. All programs are using it. And it have no
> disadvantage, of having not a second or third
> implementation of it.

Well there's sixlegs of course. And Wonka for example has its own PNG decoding routines built in, rather than rely on libpng (and zlib); I guess there must be other examples.

dgilbert
Offline
Joined: 2004-05-06
Points: 0

> Well there's sixlegs of course. And Wonka for example
> has its own PNG decoding routines built in, rather
> than rely on libpng (and zlib); I guess there must be
> other examples.

JFreeChart has used the catcode.com PNG encoder for many years with great success:

http://catcode.com/pngencoder/index.html

chris_gray
Offline
Joined: 2005-11-08
Points: 0

> > Well there's sixlegs of course. And Wonka for
> example
> > has its own PNG decoding routines built in, rather
> > than rely on libpng (and zlib); I guess there must
> be
> > other examples.
>
> JFreeChart has used the catcode.com PNG encoder for
> many years with great success:
>
> http://catcode.com/pngencoder/index.html

Hey, that's just what a customer was asking for on Tuesday - thanks. :-)

So fo PNG we have what I would regard as a healthy situation - run-of-the-mill apps just use the RI as-is, and some specialised software re-implements a part of it. For the latter, it's valuable that they can refer to the RI without having nightmares about becoming "tainted". This actually encourages compatibility, because it allows the specialised implementations to be derived from the RI.For TCP/IP you have a similar situation - just about every OS has code derived from the BSD implementation, but with their own tweaks. That hasn't led to TCP/IP chaos, rather the opposite.

theuserbl
Offline
Joined: 2004-05-04
Points: 0
theuserbl
Offline
Joined: 2004-05-04
Points: 0

Written by Roman in the GNU Classpath forum at http://developer.classpath.org/pipermail/classpath/2006-September/001433... :

[i]Hi Patrick,

> Now I have a little bit time, to reply to your comment (I will also
> write this reply in the forum at
> http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0 ).

Yeah thanks. Please also include my other replies if you see fit.

>> What I'd find best for Java is something like we have in the BSD
>> world. Friendly competing communities, with code flowing freely in all
>> directions. Something similar would be healthy for Java too, having 3
>> implementations in friendly competetion with code flowing between them
>> as it fits.
>
> I think three different OpenSource implementations would be the worst
> case scenario, if Sun makes its Java OpenSource.
> Ans I also think, that Suns sees so like I. And I think they want to
> make it OpenSource, to have _not_ three different implementations.

I disagree. Actually there are already quite a couple of (proprietary)
implementations of the Java platform which is also fine for Sun, so why
would it be bad for Java to have a couple more?

>> I'd really like to see Sun, Harmony and Classpath developing and
>> improving Java, all in their own ways and using their own methods.
>
> And in which part is the GNU Classpath implementation better then Suns
> implementation? (from the technical point of view, not from the license
> side) ?

Well, first thing is, the technical POV is not the only one important to
some parties. For example, if Sun would decide to choose to license
under GPL, that would be a problem for a reason for some parties to use
Classpath or Harmony. Then there are already a couple of VMs that are
written to use GNU Classpath and it is probably not trivial to port them
to use Sun's class libraries. Then I'm sure there are even some
interesting parts in GNU Classpath. I'm thinking about the Gnome/Cairo
peers that fit better with common Linux platforms than the Motif based
peers that Sun has. I am not sure about GNU Crypto but my feeling is
that we cover some areas that are not covered by Sun there (and vice
versa of course). In the future there could also be interesting
cooperation, I am think about the AWT/Swing area here, where GNU
Classpath could possibly focus on specialized peers and Swing L&Fs for
Gnome and KDE, while Sun focuses more on the core or something similar.
Likewise for other areas too, where Classpath and/or Harmony could work
one implementing the glue to specific platforms that Sun doesn't want to
care about etc etc.

>> Of course, when GNU, Sun and Apache can get together to work on one
>> implementation, that would be great, but very very unlikely. Just as
>> unlikely as a Gnome-KDE merger, or a Linux/*BSD/Hurd merger, etc.
>
> You can not compare the GNOME/KDE situation or the
> Linux/*BSD/HURD/OpenSolaris situation with the Java situation. It is
> completely different.
> To want a GNOME/KDE merger is like wanting a Java/.NET merger.

Ok agreed. But the comparison still holds for the different BSDs, which
are all BSD kernels/OSes with different focus.

> A good comparision of the different Java-implementations would be the
> situation with the different Browsers. All Internet-Browsers want to
> show the internet-sides. So all takes the same resources and wants to do
> the same with it.

I also don't think that it's a good idea to have only one browser. I am
quite happy that there are a couple of them and that everybody can pick
whatever he likes best. I think it's good to have IE, Mozilla, Opera,
Konqueror etc all around. The browser situation actually is a good
example why having several implementations is a good thing. Think when
IE had a marketshare of >95%. This is (arguably was) a time of
stagnation, Webdesigners forced to use ugly hacks to make their pages
load etc. Having more then one implementation in the market produces an
interesting competition and somewhat forces everybody involved to write
code that is portable.

The very same thing holds true for Java and actually we already see the
bad effects of the dominance of the Sun implementation, which is that
many developers write their code against undocumented API, against Sun
specific bugs etc etc. That wouldn't be possible when we had several
implementations sharing the market equally.

I thinnk what you and Sun (and many other devlopers) actually care about
is not having several implementations of the platform (which we already
have, even outside of the Sun/GNU/Apache world), but the problem of
keeping them together and most importantly _compatible_. That means that
a program written against one implementation should run on other
implementations too. (given that the program doesn't use non-public API
and doesn't make use of bugs/special behaviour of one impl). In order to
avoid that, Sun would need to make the TCK more open. I think this has
already been said and I don't felt the need to repeat this. So what I
think would be helpful for Java, Sun, and the GNU and Apache community
is 1) a sane license to allow cooperation and code exchange and 2)
opening up the TCK so that all 3 implementations can be compatible.

Cheers, Roman[/i]

theuserbl
Offline
Joined: 2004-05-04
Points: 0

And here also a person who have answered on the GNU Classpath mailinglist:

http://developer.classpath.org/pipermail/classpath/2006-September/001429...

As you can see, I try to bring the discussion which happens in the GNU Classpath mailinglist and so in the GNU Classpath world and discussion which happens in Apache Mailinglists and so in the Apache-World to this place, to bring the discussion here together.

Greatings
theuserbl

theuserbl
Offline
Joined: 2004-05-04
Points: 0

Here my answer I have written over the GNU Classpath-Mailinglist to Roman:

-----------------
[i]Hi Roman.
Now I have a little bit time, to reply to your comment (I will also write this reply in the forum at http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0 ).

>What I'd find best for Java is something like we have in the BSD
>world. Friendly competing communities, with code flowing freely in
>all directions. Something similar would be healthy for Java too,
>having 3 implementations in friendly competetion with code flowing
>between them as it fits.

I think three different OpenSource implementations would be the worst case scenario, if Sun makes its Java OpenSource.
Ans I also think, that Suns sees so like I. And I think they want to make it OpenSource, to have _not_ three different implementations.

>I'd really like to see Sun, Harmony
>and Classpath developing and improving Java, all in their own ways
>and using their own methods.

And in which part is the GNU Classpath implementation better then Suns implementation? (from the technical point of view, not from the license side) ?

>Of course, when GNU, Sun and Apache can get together to work on one
>implementation, that would be great, but very very unlikely. Just as
>unlikely as a Gnome-KDE merger, or a Linux/*BSD/Hurd merger, etc.

You can not compare the GNOME/KDE situation or the Linux/*BSD/HURD/OpenSolaris situation with the Java situation. It is completely different.
To want a GNOME/KDE merger is like wanting a Java/.NET merger.

The difference is, that a GNOME/KDE merker and a Java-implementations-merger is, that there existing only _one_ GNOME and _one_ KDE. And the programs written for GNOME and KDE is so only written for this one and only implementation. You can not parts of GNOME programs running with KDE-libs and the other way around.

A good comparision of the different Java-implementations would be the situation with the different Browsers. All Internet-Browsers want to show the internet-sides. So all takes the same resources and wants to do the same with it.

So lets look at the Browser-situation:

Ten years ago I tried to create my first homepage.
At first it was something simple. Using bold, italic and other commands like
.
Then there comes frames, textfields and so on. But how more complex it is, how more differes that what the InternetExmplorer show and that what Netscape show.

Then there comes some gimmiks in Javascript.
Here are for example some sides with Javascript programs for the homepage:
http://www.ramnip.net/js.html
http://www.lipfert-malik.de/webdesign/tutorial/javascript.html

Sorry, that I have find at the moment only this two sides. But today it isn't any more so much used like for some years and so there don't existing no longer so much sides about it.

What you see on this side is, that there is code where stand after it "for all browsers", some code where stand "only IE" and some code where stand "only Netscape".

On other sides about JavaScript, there stands how to find out, which browser is used and writes then with if-else commands, for every browser own code, so that at the result, the side was shown with both browsers similar.

Important is, that Netscape shows the side on all operating systems likewise. Only the IE looks different.

It is still today so, that different browsers show the sides different. In particular if they the homepages using Javascript or other things, which makes the sides a little bit more complex.

Additional we have today four different browser-rendering engines: IE, Gecko (Firefox, MozillaSuite/SeaMonkey, ...), KHTML (Konquerer, Safari, ...) and Opera.

And it is not so, that only Microsoft with its IE going its own way. The other three browsers show also all the sides different. But the browsers itself showing the side on all operating systems identical. Firefox/Linux shows it like Firefox/Windows. Opera/Windows like Opera/Linux.

The webdesigner used and use the least lowest common denominator, so that all internet-sides are looking equal on all browsers. And I have heard, that webdisigner having all browsers installed on its system.

Today JavaScript is mentiond in association with Web 2.0 and so.
Mostly things are today written on server-side, so that the clients become only for the browsers easy-to-understand-sides.

Now have a look at the current situation of Java (only looking at Suns Java):
Java consists of a little platform-dependent part including the JVM, AWT, etc and a big platformindependent part including Swing, Java2D and so.

There existing programs which which run on Java 1.1, but no longer since Java 1.2. But the downward compatibility have also been in the last years better.

The Java-developer can writes its code for Java 5 and it is very likely that it runs also on any other platform with Java 5.
They only must now install also Java 6 beta to look if its program running still on the new Java. If not, then sending a bug-report to Sun or changing the own program.

Until today GNU Classpath makes sence, because it is an OpenSource Java-implementation and Suns Java isn't OpenSource.
And it is not only a Java-implementation it is in parts a rewrite of Suns Java. As i know, there is nowhere defined in any book how the ocean-theme looks like. Only the old metal theme is defined at http://java.sun.com/products/jlf/
So in parts GNU Classpath is not only a implementation of what the JCP defines, its a rewrite of that, what Suns have done.

But until Sun makes its Java implementation OpenSource, then the situation is different.
The advantage of GNU Classpath over Suns Java is the license. After Suns Java is OpenSource, this advantage no longer exists.
And to try to rewrite Suns Java can GNU Classpath not make better then Suns Java. So why then using GNU Classpath?

An additional problem would be that, what already with the browsers exists. Developer would try its programs not only on Suns implementation, they also must try it with GNU Classpath and Apache Harmony --- write once, test thrice.

It isn't enough, that the JCP exists and defindes how Java have to look like. For the web existing also the W3C and the browser-engines are all different.

Until a special point all three Java-implementations will be equal. But especially if new things would be implemented, it would inhibits the evolution of Java.
A chain is only so strong like it flimsiest limb.
And the newest features of Java will only be of all developers used, if the last Java-implementation have included it.

So I think, that - if Sun makes its Java OpenSource - it would be a bad thing, if then GNU Classpath and Apache Harmony still exists.

An additional questions would be: Which distribution would including a GNU Classpath based Java, when Suns reference-implementation is already OpenSource.
LessTif also still exists and the most distribution are including OpenMotif instead. And that though OpenMotif isn't OpenSource. It can only be used on OpenSource operating systems without paying. And only for OpenSource-systems the license is similar to OpenSource - but not OpenSource.

Greatings
Patrick -- alias theuserbl[/i]

---------
Greatings
theuserbl

robilad
Offline
Joined: 2004-05-05
Points: 0

heUser BL wrote:

> And in which part is the GNU Classpath implementation better then Suns implementation? (from the technical point of view, not from the license side) ?
>

There are many software quality metrics, and tools to derive them, so your could do your own research on respective quality of either implementation. I doubt
that comparing interna of class library implementations is a subject that's of utmost interest to the java.net audience, though, at least in the scope of this forum at this point in time.

Objectively, GNU classpath developers can't really say much about Sun's implementation, since it's not open source, and they haven't studied it in detail, so they can't really tell you in which specific parts their code is better or worse.

> So I think, that - if Sun makes its Java OpenSource - it would be a bad thing, if then GNU Classpath and Apache Harmony still exists.

That's an opinion I'd heavily disagree with, as I don't think that existence of any free software is a bad thing.

It was a very good thing that Sun opened up Solaris,
for example, and the continued existence of the Linux kernel does not seem to be a bad thing to me either.

Choice is good.

> An additional questions would be: Which distribution would including a GNU Classpath based Java, when Suns reference-implementation is already OpenSource.

I really think you're trying to solve a problem noone else sees as a big deal: neither Sun, nor anyone else making free or non-free Java implementations seems to be interested in rooting out the other VMs, afaict, and never was.

Free software development is not at all like a Highlander movie.

Everyone is interested in seeing full compatibility between different implementations of the standards. There are many ways to encourage and get that, from releasing the TCKs under friendly licenses, to opening the reference implementation under suitable licensing conditions so that it can be shared and worked on together, to working more closely on JSRs. These approaches are not mutually exclusive, and Sun has shown some really encouraging movement on many sides in the past, including this year's commendable push towards free software in that area.

The approach you seem to have chosen, though, is to try to figure out what it would take to make sure other projects drop dead. That does not sound very productive to me: Sun's developers are rightfully proud of their code, so is probably everyone else in any project. Holding a gun to anyone's head to debate hypothetical scenarios under which they'd give up what they have and 'switch' to something else they don't know yet, is either way just wasting their good will and time, as one could have learned from mailing list posts trying to get GNU Classpath to switch to Harmony or vice versa. Groups of free people don't function that way: you push them in one direction from outside, they'll usually shove you back.

In a similar way to ESR's and IBM's old 'open letter campaigns' to drag Sun kicking and screaming into licensing the RI under an open source license, your approach is doing your cause not much good, afaict.

Relax.

Give Sun some time to sort the 'how' out, and we'll see how it works out when we get there. Put some trust into them, it's not the first time Sun are opening up some crown jewels. Afaict from talking to various Sun employees, they are genuinely interested in doing the right things. It may turn out that 'the right thing' isn't cheered on by everyone everywhere, but that doesn't really matter much in the long run: important problems will be taken up by people who care about them and fixed, eventually, like we've all done throughout all those past years of working together on many issues.

atripp
Offline
Joined: 2003-07-15
Points: 0

> heUser BL wrote:
>
> > And in which part is the GNU Classpath
> implementation better then Suns implementation? (from
> the technical point of view, not from the license
> side) ?
> >
>
> There are many software quality metrics, and tools to
> derive them, so your could do your own research on
> respective quality of either implementation. I doubt
> that comparing interna of class library
> implementations is a subject that's of utmost
> interest to the java.net audience, though, at least
> in the scope of this forum at this point in time.

I think the question was rhetorical. He wasn't literally asking which Classpath parts are better, but really saying that *none* are better, and challenging you to show any counterexample.

Even if he's not making that claim, I will.

>
> Objectively, GNU classpath developers can't really
> say much about Sun's implementation, since it's not
> open source, and they haven't studied it in detail,
> so they can't really tell you in which specific parts
> their code is better or worse.

I can help you out here. I can look at both Suns and Classpath code. If you have any code in Classpath that you think is somehow better than Sun's, let me know and I can verify it.

> Choice is good.

Not always. Choice in C and C++ compilers, for example is bad. It means countless hours of frustrating ports. Life would have been much better if there had only been one dominant C and C++.

>
> > An additional questions would be: Which
> distribution would including a GNU Classpath based
> Java, when Suns reference-implementation is already
> OpenSource.
>
> I really think you're trying to solve a problem noone
> else sees as a big deal: neither Sun, nor anyone else
> making free or non-free Java implementations seems to
> be interested in rooting out the other VMs, afaict,
> and never was.

I, for one, would like to ensure that there is only one Java (i.e. a single, dominant implementation). I am not alone.

> Everyone is interested in seeing full compatibility
> between different implementations of the standards.

Everyone wants full compatibility, but not everyone would like to witness the struggle to make that happen. After all these years, all the C and C++ compilers are incompatible to various degrees. The C/C++ efforts have shown that it's completely impossible to get full compatibility for a C/C++/Java-like language. After decades of standards bodies work and good intentions, the result is still no WORA.

> There are many ways to encourage and get that,

There are lots of ways to encourage full compatibility, but no ways to get it. You can claim that all the C compilers are compatible to the standard all you want. But the fact is, if you try to port your (non-trivial) gcc/linux app to Windows right now, you'll be spending more than just this weekend getting it to work.

>
> The approach you seem to have chosen, though, is to
> try to figure out what it would take to make sure
> other projects drop dead. That does not sound very
> productive to me.

That can be productive. When Sun went about trying to make Visual J++ "drop dead", they had good success, and we never talk about having to "port" between the two today.

tompalmer
Offline
Joined: 2006-08-26
Points: 0

> I, for one, would like to ensure that there is only one Java (i.e. a single, dominant implementation). I am not alone.

I tend to agree. That said, until Sun starts producing their own Java for Mac and it becomes dominant, this world hasn't happened yet. I'm among those hoping for this in the Intel-Mac/Open-Source-Java world of the future.

theuserbl
Offline
Joined: 2004-05-04
Points: 0

Here a link of the reply of an additional GNU Classpath developer. I don't know, if I have the allowance to cite it here. So I post only a link to the reply in the web:

http://developer.classpath.org/pipermail/classpath/2006-September/001425...

Gtreatings
theuserbl

Update: Because Roman have written in a newer mail, that he would be happy, if I publish its mails here, so I now doing it:

----------------
[i]Hi Patrick.

> On Sun, 2006-09-03 at 13:11 +0000, theUser BL wrote:
>> Have a look at
>> http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0
>> there I have written a qustion at Mark and other developers.

IMO, it is not necessary and feasible to have The One OSS/F Java
implementation. That's not how the Free Software model has worked in the
past and I see no reason why it would in the future and for Java. Just
look at the kernels, desktops, editors, etc etc, where there's always
the question 'why not pull forces together and work on The One
implementation'. Easy answer, there's lots of different people and
groups involved in free software development with different goals and
requirements, different development models, different ideals etc etc.
And really, I think the world would not be any better with only one
implementation of them all. AFAICS, it's apparent the having more than
one implementation is better in most cases.

What I'd find best for Java is something like we have in the BSD world.
Friendly competing communities, with code flowing freely in all
directions. Something similar would be healthy for Java too, having 3
implementations in friendly competetion with code flowing between them
as it fits. Of course, the basic requirements for this is that all 3
licenses allow such a scenario. It would be sad if there's only 1 or 2
of the implementations 'inside' and the other(s) 'outside' of the Java
community. I'd really like to see Sun, Harmony and Classpath developing
and improving Java, all in their own ways and using their own methods.
This could allow one party to focus on their stuff and include other
pieces from other parties.

Of course, when GNU, Sun and Apache can get together to work on one
implementation, that would be great, but very very unlikely. Just as
unlikely as a Gnome-KDE merger, or a Linux/*BSD/Hurd merger, etc.

Cheers, Roman[/i]

------------------

Greatings
theuserbl

Message was edited by: theuserbl

theuserbl
Offline
Joined: 2004-05-04
Points: 0

At http://developer.classpath.org/pipermail/classpath/2006-September/001423... Mark have also answered my question.

He wrote:
-------------------------------

[i]Hi Patrick,

On Sun, 2006-09-03 at 13:11 +0000, theUser BL wrote:
> Have a look at
> http://forums.java.net/jive/thread.jspa?threadID=18036&tstart=0
> there I have written a qustion at Mark and other developers.
>
> It would be nice and I would be happy, if you answer it.

Seems you need to have to register for some sort of account on that site
to post there, but feel free to quote or redistribute my response if you
want.

I cannot possibly hope to speak for all GNU Classpath developers since
there are just too many and GNU Classpath is really a community of
communities, lots of individuals, organizations and projects working
together for various reasons. But I think you are right that we are
pretty flexible and accommodating. The common theme in the last 8 years
has been cooperation and respect for each others work. This also extends
to licenses, anything upward compatible with the GPL seems fine with the
community. So you are also right that either the GNU Classpath license,
GPL plus some exception, GPLv2 or v3, LGPL, BSD or MIT/X would all
encourage cooperation between groups. Non-GPL compatible licenses seem
to fragment the community and nobody wants to see an incompatible,
proprietary fork of java.

Sun has in the past chosen to use and create licenses like SISSL and
CDDL, which some say are explicitly designed to be GPL-incompatible so
as to not work together with the larger GNU/Linux community. Lets hope
they are sincere in wanting to work with the existing communities. As
soon as there is code available under a friendly license I am sure we
will see some sort of cooperation between the communities. But no code
is available atm, no license has been chosen and it isn't clear whether
Sun needs or wants help from the community with code that we can provide
for them to create a large free software platform together.

Cheers,

Mark[/i]

--------------------------------
Greatings
theuserbl

theuserbl
Offline
Joined: 2004-05-04
Points: 0

For people, who don't read the GNU Classpath mailinglist. Here my reply to Marks post:

--------------------
[i]>Seems you need to have to register for some sort of account on that site
>to post there, but feel free to quote or redistribute my response if you
>want.

Yes. I have now posted also your answer in this forum (and this reply).

>Sun has in the past chosen to use and create licenses like SISSL and
>CDDL, which some say are explicitly designed to be GPL-incompatible so
>as to not work together with the larger GNU/Linux community. Lets hope
>they are sincere in wanting to work with the existing communities. As
>soon as there is code available under a friendly license I am sure we
>will see some sort of cooperation between the communities. But no code
>is available atm, no license has been chosen and it isn't clear whether
>Sun needs or wants help from the community with code that we can provide
>for them to create a large free software platform together.

You are right, at the moment there is no JDK-source published by Sun.
But that is also the reason, why I write posts like this.

At
http://www.vnunet.com/vnunet/news/2162306/first-open-source-java-promised
stands, that Sun published the first code in the next month. And when they publish the code, they have decided, which license they want to use (at fiirst only for javac and the hotspot-compiler).

Its the decision of Sun, how the license of its Java look like. But at the moment it seems, that they want to bring all OpenSource Java communities together.

I fear, that Sun published in the next month the first codes under a license, for which they are have decided itself. And later GNU Classpath people or Apache Harmony people say: "Bad license-decision. It have been more a license like ..., but the code under this license, we will never use and never work on".

All things have its time. And the time where the license of Suns Java will be decided is _before_ it will be published.

And thanks for the answer.
David Gilbert have also answered in the forum.
I hope your comments helps Sun to find the right license.

Greatings
theuserbl[/i]
-------------------

Greatings
theuserbl

dgilbert
Offline
Joined: 2004-05-06
Points: 0

I've been a contributor to GNU Classpath for two years now. I'll comment, but note that I speak only for myself, not the other GNU Classpath developers...

> The qoal is to bring Apache Harmony, GNU Classpath
> and Suns Java together.

That might be someone's goal, but I doubt that it is Sun's goal and it isn't my goal. My goal is to have the best possible free-in-the-GNU-sense runtime for Java applications. At the moment, I think the surest path to that goal is contributing to GNU Classpath, but at the same time I am very optimistic that Sun will follow through with "open source" Java and trump most of the work that has been done on GNU Classpath. That would be a great outcome, in spite of the "wasted" effort.

> What must be happen to leave GNU Classpath and
> working instead of that on Suns Java.

I'll work on Sun's Java if the licence is one of the Free Software Licences listed on the GNU website, and there are no unnecessary barriers to contributing. I'd prefer a GPL compatible free licence [1], but if Sun chooses a licence that is free but not GPL-compatible [2] I'll still be likely to contribute.

As I said, I'm really optimistic about this happening, but I'll continue contributing to GNU Classpath until Sun delivers.

[1] http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

[2] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses

robilad
Offline
Joined: 2004-05-05
Points: 0

You're apparently trying to work out from an ultimate goal what the conditions would be to reach it.

That's bound to fail, because all sides are forced to operate on assumptions about the future to a certain degree, and their assumptions are unlikely to be the same ones.

Ultimate goals have the disadvantage of not being within (immediate) reach usually, so the best you can get are hypothetical replies, and the worst you can get are debates about hypothetical conditions and steps on the way to reach the ultimate goal.

The reason why Apache Harmony has not attracted GNU Classpath developers lies in ASF's inability to make sure the resulting work is under a license suitable for *all* VMs and use cases, rather than the VM made within the context of the Harmony project. Putting the class library under the Apache license does not work for GPLd VMs, and it does not work for ahead of time compilation of GPLd Java code, as in both cases using Apache Harmony would lead to an undistributable result.

That's all there is to it: people will work on code they can use, and they won't work on code that they can't use.

A precondition for a lot of people working on GPLd runtimes is that the code needs to have a GPL-compatible license, otherwise they can't redistribute it in their VMs.

audriusa
Offline
Joined: 2005-11-16
Points: 0

I think that the license should be compatible with the license of the GNU Classpath project. That is necessary for the immediate replacing of the proprietary components that (the rumours are going around) may still be present in the Sun's open source java release. In the absolute majority of cases GNU Classpath also contains the similar fully functional parts. Better or not, the Sun's implementation may not be accepted in the free world with the proprietary parts still present.

The compatibility with the ASL would also allow to use the pieces of the Harmony, if preferred. Maybe the GPL 3 will be compatible with both licenses, allowing such a solution.

Choosing the third incompatible license is probably the worst they can do.

Audrius Meskauskas

theuserbl
Offline
Joined: 2004-05-04
Points: 0

> [i]GPL compatibility required[/i]
> [i]I think that the license should be compatible with the license of the GNU Classpath project.[/i]

GPL compatiblity and GNU Classpath compatiblity are two different things.

GPL compatible is only the LGPL, BSD and so on.

But the GNU Classpath license allows it to compile [i]any[/i] file of [i]any[/i] license against GNU Classpath files.

> [i]Maybe the GPL 3 will be compatible with both licenses, allowing such a solution.[/i]

All what would be possible with the GPL 3, is already possible with the current GPL + linking exception (the GNU Classpath license)

audriusa
Offline
Joined: 2005-11-16
Points: 0

>All what would be possible with the GPL 3, is already possible with the current GPL + linking exception (the GNU Classpath license)

The ASL and GPL+Exception code fragments still probably cannot be freely mixed, just relatively independent modules can be linked. I am not sure if this is so a good thing if any better alternative like GPL 3 exists.

GPL + exception is also a good solution.