Skip to main content

Proprietary parts in the Sun's open source java release

4 replies [Last post]
Joined: 2005-11-16

Just found (1) that even the open source Sun's java release may have the poprietary parts for that the Sun itself has no right to put them under open source. The open source community surely will not be happy. The cited paper talks about fonts, but I know there are also other parts like* classes that are normally generated from the IDL files with the "no-modify" licence. These files belong the the Object Management Group. From the API documentation, many Sun's CORBA classes also look like generated.

This may be a serious reason to think that the license may also be a GPL compatible, as the existing GNU Classpath project has the largely working implementation, including the manually written and documented classes. In other words, why to include the proprietary parts that are even not owned by Sun, when it is possible to find a replacements in the world of the Free software? Surely, Apache Harmony would also fit, but they do not have the manually written so far.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-08-22

This is one of the issues that makes open sourcing the JDK complex:

As we've stated [1] we are working on...
+ Identifing, evaluating, and managing intellectual property encumbrances.




Joined: 2006-11-05

My pov on this is that the fastest thing to do is a bsd-like release. Drop everything you are unsure about and make it a subset of the compleate JDK. Then let the community fill the holes. Split the JDK in a open source package and a closed source package and focus all new development on the open one .

Joined: 2003-06-06

I don't think a split like this is necessary; I think the encumbered parts will be obvious enough, and that the community can just target and eliminate them.

Joined: 2006-11-05

If sun wants to release something asap a split is needed. They could start the "openjava" project and put in code in it when its cleared. That would give the oss developers something to play around with, even if its incomplete.

The purpose of such a split is not to grow two incompatible jdk:s but to make an incompleate oss development project that could be started as soon as the license has been chosen. We could then get the parts that has been cleared for distribution faster instead of waiting for the review of the entire JDK. It could also allow us to start integrating it with code from projects like mono and the gnu classpath. mono has a lot of toys like the static linker and the aot-compiler that would probably be fun to play with.

Message was edited by: falde