[ANSI-Smalltalk] Re: STEP Licenses

[Paolo Bonzini]

Bruce Badger wrote:
> 2008/9/23 Steve Wart <steve.wart at gmail.com>:
>> This is documentation, not code we are talking about, correct?
>> What's wrong with CC?
> 
> The FSF say that CC is not compatible with the GPL.  The FSF list the
> GPL-compatible licenses here:
> 
>   http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses

There are three cases to consider.

1) Documents.  Basically no "document license" is compatible with the
GPL, including the FSF's own GFDL; I don't really have an explanation
for this, but I guess it is a good reason not to use an MIT license.
Eben Moglen (FSF's license lawyer) says that it is as complicated as
merging gravity with the other three elementary forces. :-)  In this
case I agree with Steve that CC is good enough, the alternative being GFDL.

There are many different CC licenses, depending on what clauses you apply:

* BY (attribution): Similar to MIT/X11 but for documents instead of
software.

* SA (share-alike): "Viral", similar to GPL/GFDL, but not compatible
with it.

* NC (non-commercial), ND (no-derivative): Also not compatible with
GPL/GFDL.  The Free Software Foundation does not accept licenses with
these clauses as being free.

My suggestion for licensing STEP documents is either a permissive CC-BY
license (http://creativecommons.org/licenses/by/3.0/ gives a
human-readable summary of the license), or a stricter dual CC-BY-SA+GFDL
license.  Maybe we can poll on this?

I think this is what Bruce was talking about.  Anyway, I'll go on
discussing code licenses because the MIT license is more generally
applicable to code.


2) Reference implementations (RI).  I think having MIT- or BSD-licensed
implementations would indeed be a good thing.  But I'm not sure about
forcing it, because I'm afraid it would slow down releasing code because
of legal issues; for example, I would have to ask RMS to relicense GNU
Smalltalk code; it'd not be a big deal after the STEP process took some
momentum, but in the beginning it would be a little harder.

So I'm ambivalent about this, but I'm leaning more towards making it a
"strong suggestion".  Everyone should know that if the RI is more easily
embraced, the STEP is more likely to succeed.


3) Technology compatibility kits (TCK -- testsuites, basically).  I
don't think that in this case it is necessary to have a sanctioned
license, and actually it would be nice to have a GPL-like license: this
way, if the TCK is enhanced in-house there is no limitation, but if the
enhancements are distributed everybody can validate their implementation
against them and redistribute them.  I think that in the case of
testsuites, the "viral" behavior of the GPL can only produce positive
feedback.


As an aside, the STEP documents says that these properties are
*desirable*, not requested:

    * the reference implementation should run on at least two
      implementations of Smalltalk;

    * the reference implementation should run on at least one
      open-source implementation of Smalltalk;

    * the technology compatibility kit should be available under a
      GPL-compatible license;

    * a reference implementation working on at least one implementation
      of Smalltalk should be itself available under an OSI-approved,
      GPL-compatible license.

This might seem weak, but it is for a reason.  For example in some cases
(imagine a debugging class library, or even something as basic as file
system classes) it may just not be feasible to have a single RI working
on two implementation of Smalltalk.

In particular, regarding the last two bullets, exactly because in some
cases it might not be even possible to fulfill them, then it is IMO
better to make their fulfillment easier.  As I said before, all we can
do, is hope that this tension has two positive effects: 1) get more
STEPs written, because providing RIs is hopefully not a big chore; 2)
have at least some STEPs with liberal reference implementation, because
they are more likely to succeed.

Paolo