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

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]

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.

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.