|
|
|
|
|
|
by javajosh
1740 days ago
|
|
|
Yes, that all seems so trivial a small child could understand it. So what's my problem?! /s But seriously, you don't see how this might be confusing? And what you've described is really only the tip of the iceberg. Who defines the specs? Who writes the compliance tests with the specs? Who runs those and certifies that implementations are compatible? What limits are there on entities that make builds, either on the patches they can apply (and still call it "Java") or the licenses they can adopt? What does "GPL with classpath exception" mean in the real world, that JDK-itself changes must be upstreamed, but linked applications need not be? What are the limits there? The point is, getting an open source JDK binary is not easy, especially if you want to understand what you're getting. "OpenJDK" may exist as an OSS project, but I wouldn't call it typical. Not because it doesn't release binaries (although I just discovered it does, provided by Oracle for Windows/Linux only), but because of the license, the owner, and the owner's relationship to binary builders. The binaries you can get in practice have unknown additions from the vendor, and possible adjustments to the license (or is only Oracle allowed to make alternative licenses for an OpenJDK build?) Compare java distribution to, say, node or python. Is it really fair to accuse someone who is confused of being an idiot? |
|
|
The exception is very broad and fairly simple.
Azul has a good breakdown of it https://www.azul.com/blog/why-the-classpath-exception-is-so-...
The short answer though is if you link to a GPL+Classpath exception library you may distribute the results under any license you choose.