Public open specs

[Dalibor Topic]

Mark Wielaard wrote:
> Hi Dalibor,
>   
>>> There are currently restrictions on the JSRs that prevent
>>> reusing any Sun OpenJDK code for implementations because they aren't
>>> considered "independent" because of clause 5 ('"Independent
>>> Implementation" shall mean an implementation of the Specification that
>>> neither derives from any of Sun's source code or binary code
>>> materials, ...'). 
>>>       
>> That does not seem to be a GPL compatibility issue to me.
>>     
>
> 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.
>   
Thank you very much for the explanation, Mark. Technically speaking,
that doesn't seem to be a GPL
compatibility issue - when the FSF speaks about GPL compatibility, it
talks about something else:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WhatDoesCompatMean
*
"What does it mean to say a license is “compatible with the GPL”.
<http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCWhatDoesCompatMean>*


    It means that the other license and the GNU GPL are compatible; you
    can combine code released under the other license with code released
    under the GNU GPL in one larger program.

    The GPL permits such a combination provided it is released under the
    GNU GPL. The other license is compatible with the GPL if it permits
    this too."


Since the specification license is used for specifications, which are
basically documentation in say, PDF or HTML formats, and aren't executable,
there doesn't seem to be a useful scenario in which combining the two in
one larger program makes a lot of practical sense.

>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.
>>> 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.").
>>>       
>>  [...]
>> If what you have is your personal non-lawyerly opinion, than that's
>> cool, too - but in that case I'd suggest
>> focusing the argument for spec license changes on more promising aspects
>> - the GPL incompatibility
>> argument is not really a great tool for me to work with in face of a lot
>> of GPLd code successfully
>> implementing JSRs showing the opposite.
>>     
>
> I am somewhat puzzled by your reply. For years we have known that the
> restrictions mentioned in these JSR licenses are incompatible with the
> way our communities work. You have been a very good spokesperson for the
> community explaining why these kind of restrictive licenses used by Sun
> are just nuts. I have read and laughed a lot about blog posts you made
> in the past explaining such things in simple, direct words. That you now
> suddenly don't see how these restrictions on what code you can publish
> are incompatible with the whole spirit of the GPL is somewhat strange to
> me.
>   
Ah! Let me explain, then - sometimes I assume that my song and dance act
is as obvious to others as it is to me. My apologies.

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.

You've had me at hello, of course ;) But in order to get the best
arguments for that cause, I need to step into the role of a very nasty
advocatus diaboli, and examine the arguments made not just with the eye
of an activist, but also with the eye on arguments that could be
brought against them, like the mean little technicality I used above.

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.

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.

cheers,
dalibor topic,

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring