Just the Java J2ME,J2SE,J2EE Libraries [LWN.net]

Just the Java J2ME,J2SE,J2EE Libraries

Posted Feb 19, 2004 23:08 UTC (Thu) by NZheretic (guest, #409)
Parent article: Let Java Go

First posted to in reply to Russ Miles Sun and Open Sourcing, the debate continues...

It would benefit the entire Java based industy, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libaries and Java to bytecode compilers.

Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of vendors were using the same core libaries.

To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.

Contributions to the core standard would be required to licensed under the same open source license. The existing JCP standard body could decide what becomes part of the Open Java Core.

It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.

(Log in to post comments)

Just the Java J2ME,J2SE,J2EE Libraries

Posted Feb 20, 2004 23:19 UTC (Fri) by piman (subscriber, #8957) [Link]

> To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace.

This is not a free software, or open source, license. In fact, that's pretty much what Sun's license for some of Java says already.

Just the Java J2ME,J2SE,J2EE Libraries

Posted Feb 21, 2004 10:16 UTC (Sat) by NZheretic (guest, #409) [Link]

In fact, that's pretty much what Sun's license for some of Java says already..

The current set of Sun Java source licenses is not by any means an open source license. It is more along the line of the old AT&T Unix and Microsoft shared source licenses.

Just the Java J2ME,J2SE,J2EE Libraries

Posted Feb 21, 2004 19:29 UTC (Sat) by piman (subscriber, #8957) [Link]

> The current set of Sun Java source licenses is not by any means an open source license.

Correct! Neither is the license you proposed, preventing people from changing the library behavior inside certain namespaces. That is one of the main reasons that Sun's current Java implementation is not open source or free.

Such a license would still be classed as an open source license.

Posted Feb 22, 2004 3:09 UTC (Sun) by NZheretic (guest, #409) [Link]

What part of the above would conflict with the definition of an open source license?

In fact clause 5 explicitly states: "The license may require derived works to carry a different name or version number from the original software."

Such a license would still be classed as an open source license.

Posted Feb 22, 2004 5:24 UTC (Sun) by piman (subscriber, #8957) [Link]

A name or version, which is exposed to humans, is not the same as a library interface, which is a technical consideration. Debian, for example, has explicitly rejected such licenses as non-free (following the DFSG, upon which the OSD is based). The requirement in the LaTeX license to require one to change the filename of any modified file was rejected as non-free. I suspect a similar requirement in any other language would be rejected as such.

Some points

Posted Feb 22, 2004 13:56 UTC (Sun) by NZheretic (guest, #409) [Link]

1) I stated from the start that it would be an Open source license and nothing in the clause would necessarily be in breach of the actual offical definition of the Open Source Initiative (OSI)'s Open Source Definition.

2) Changes would only be required to shift to the vendors/developers namespace if the changes were incompatable with the JCP JSR open standards. This would not prevent additional optimizations, ports or bug fixes. Since adoption of standards has for a long time been an opens source tradition, it wpuld not be much of an imposition.

3) Shifting "unoffically" extended or modifed incompatable standard classes to the vendors/developers namespace is not a major limiatation. It is possible to add a custom class loader/converter and/or modify the Java to bytecode compiler ( requiring an addional flag ) to re-reference/re-map existing standard API calls to the vendors/developers namespaced classes.

4) On case in precedence where a change of name affected the API for free license source code is the Elba fork of the LGPL'ed JBoss. JBoss Group LLC owns the "JBOSS" trademark and the jboss identifer is used thoughout the JBoss implementation. The Core Developer Network LLC member replaced all instances of "jboss" with "elba" in the source code and could have added a modified class loader ( the Jboss project now includes a custom class loader ) without any loss of functionality.( All of the lead Geronimo developers had worked on Elba and Marc Fleury sent the Apache project a warning letter about possible derivative lines of source from JBoss/Elba released under the Apache license instead of the LGPL )

5) Sun already,under the JCP organization, licenses the use of J2EE Certification to open source developent organizations on the grounds that the organization's product passes the relevent test suite. The LGPL'ed JBoss JBoss Group commits to J2EE Certification for JBoss Application Server.

6) Although the Debian DFSG and the Debian legal mailing list are influential, they do not hold a monopoly on what is or is not either a free license or an opens source license. In fact many of the members take issue on section 2c of the GPL license, claiming it violates the the terms of the Debian DFSG.

7) The LaTeX Project Public License (LPPL) issue was more a case of the wording of the clauses and the ambiguity of what would constitute an incompatable change. This would not be a problem in the case of a Java Open core because of the availability of the test suites used for Certification of the Java standards.