Public open specs

[Mark Wielaard]

Hi Dalibor,

On Fri, 2008-11-14 at 19:20 +0100, Dalibor Topic wrote:
> Mark Wielaard wrote:
> > It explicitly says that the license is only for implementing an
> > Independent Implementation, and that code derived from Sun's source code
> > is not considered an "Independent Implementation". Since we are talking
> > about OpenJDK (Sun's source code), which is distributed under the GPL
> > that seems an conflict. Unless Sun declares that accepting this JSR
> > license agreement does not in any way take away any rights that were
> > granted under the GPL for OpenJDK and that even after accepting the JSR
> > license you are allowed to publish any derivative work of OpenJDK
> > without any restrictions following the GPL.
> [...]
> From your last line about using the specs while working on OpenJDK, it
> seems that you are looking for assurance
> from Sun about something else. I'd be happy to explore addressing that
> question in the Open Source Java FAQ, in
> case it hasn't been addressed yet.

It would be great if you could get in writing that accepting any
click-through license of any of the Sun lead JSRs, for which Sun holds
the rights, does not take away any rights that were granted under the
GPL for OpenJDK and that even after accepting the JSR license you are
allowed to publish any derivative work of OpenJDK without any
restrictions following the GPL.

Having that the the FAQ would be a good thing. Just removing the
click-through license that implies otherwise would be even better.

> >>> clauses 2
> >>> (a - c) limit the scope of the code you can publish, which
> conflicts
> >>> with the rights granted under the GPL, which doesn't limit the
> scope
> >>> ("does not modify, subset, superset, etc.").
> [...]
> You've mentioned in your previous post about a dozen JSRs for which
> you'd like to see me explore alternative licensing options for the
> specifications.
> I'm more than happy to do so, as that aligns very much with my own goals
> and ambitions as a free software activist and developer.
> 
> As you can probably imagine, though, such a change would need to go
> through many hands and heads, including spec leads, and
> actual lawyers who understand all the involved licenses, so it would be
> in effect a significant investment in time for at least a dozen people.
> So, before I embark on that long journey, and try to make that happen, I
> want to make sure that I have the best arguments to convince
> everyone that such a change is necessary and desirable in the most
> effective way.

Sure, that is why I listed just the JSRs relevant for OpenJDK
development, which have Sun as spec lead, so that there is just one
party to convince. Keep it focused.

> The problem, in my opinion, on focusing the argument for a spec license
> change on mental gymnastics around trying to fit the description of the
> problem
> to the trusty and familiar bludgeon of GPL incompatibility is that such
> mental gymnastics are not necessarily as convincing to a practicing lawyer
> as they are to a practicing free software activist. Reasonable people
> can have arguments about the interpretation of the GPL, for example, not to
> mention other licenses.  So I don't want to even go there, if I can
> avoid it, because I think that kind of argument is, while familiar and
> evoking
> strong emotions, setting that cause up for slow failure amidst hefty
> non-lawyerly handwaving.

The GPL is just the constitution that defines a bare minimum of rights
granted by Free Software, a framework in which communities work. Whether
you express it in the GPL legalize, or just point to the Free Software
definition, doesn't really matter imho.

> Similarly, I don't think that hypothetical scenarios are as convincing
> as real, existing issues - and those are the kind of things I'd expect
> to see brought up
> for the specifications you mentioned, in order to be able to make a
> good, convincing case for change of existing terms for them. I believe
> that the
> 'incompatible with the way our communities work' angle you mentioned
> above is one that is a lot more promising in yielding strong arguments
> that hold
> up upon close inspection, then an angle that tries to frame the issue as
> a matter of GPL interpretation.

So let rephrase one more time:

Since the code on which OpenJDK is based is a work in progress we are
constantly publishing sub sets or super sets of what is defined in a
JSR, restrictions on publishing such things harm cooperation in the
community that wants to improve the code. OpenJDK doesn't pass the TCK
(even though some derivatives like IcedTea do at times in certain
configurations used by some GNU/Linux distros), so any restriction on
publishing implementations that require passing a test suite cannot be
easily met by the community. Also since OpenJDK is future focused
additions are always made that were not in older specs. So by definition
the code published by the community doesn't pass either the old
spec/tck, or does not yet pass the new spec/tck. To work together the
community must be able to both read the specs and compare and share code
in progress that might or might not ever pass any tck. All such
restrictions are also in conflict with the rights granted under the GPL,
which is the license used for distributing OpenJDK and all its
derivatives.

Please fix. The list of Sun lead JSRs that are relevant for OpenJDK
hackers is below.

Getting all these JSRs published freely and openly without click-through
like you want to do for the JVM spec would solve all these issues.

Thanks,

Mark

JSR 105: XML Digital Signature APIs
JSR 199: Java Compiler API
JSR 202: JavaTM Class File Specification Update
JSR 203: More New I/O APIs for the JavaTM Platform ("NIO.2")
JSR 221: JDBC 4.0 API Specification
JSR 222: Java Architecture for XML Binding (JAXB) 2.0
JSR 223: Scripting for the Java Platform
JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0
JSR 250: Common Annotations for the Java Platform
JSR 255: Java Management Extensions (JMX) Specification, version 2.0
JSR 269: Pluggable Annotation Processing API
JSR 270: Java SE 6 Release Contents
JSR 277: Java Module System
JSR 292: Supporting Dynamically Typed Languages on the Java Platform
JSR 294: Improved Modularity Support in the Java Programming Language