For Approval: Transitive Grace Period Public Licence, v1.0

[Michael Tiemann]

On Thu, Feb 19, 2009 at 11:38 AM, Tzeng, Nigel H. <Nigel.Tzeng at jhuapl.edu>wrote:

> Yes.  It would also be a damn shame if the OSI never bothered to approve a
> license that was "different" and perhaps even "complex" even if it appears
> to adhere to the spirit of open source and provided something new.
>
> Essentially, it appears folks may have accepted that there is no middle
> ground between BSD and GPL.  Yes, that's probably true unless you address
> the root desires for finding such middle ground.  Namely, how do I open
> source my stuff and still make money on it?  Today we have hacks to do this:
>  dual license GPL and commercial license with a contributor license
> agreement and hope for no forks that you can't use for your pro product.


The OSI was never consulted, and need not be consulted, by those who wish to
place special conditions for commercial reasons over top of open source
licenses and use them in their businesses.  For example, MySQL's
dual-license didn't need OSI approval--they can say "here's MySQL under an
OSI-approved license, and here it is under our commercial use license--take
your pick and pay as appropriate."

If you wanted to offer to customers "here's the dual-licensable version and
here's the (12 month old) GPL version", you don't need our blessing.  I
think that some kind of commercially controlled switch that governs which
OSI-approved license is in force at what point in time need not itself be an
OSI-approved device.  Moreover, depending on the arbitrariness (and
capriciousness) of the device, it may be something which even if it met the
letter of the OSD, would not be in the spirit of what open source is trying
to accomplish.

To give a concrete example: the Arbitrary and Capricious License (which I
just made up) computes the number of days since Epoch (Jan 1, 1969) modulo
the number of currently approved and recommended OSI licenses and randomly
selects which one is in force for that day (using the timezone of the
licensor as the determinant of when daytime begins and ends) and a random
number generator that publishes its results to the licensor's website.  The
fact that the software is *always* under an open source license means it
should be OSD-compliant.  But the fact that the specific terms are subject
to arbitrary and random change make it virtually impossible to determine
what that OSD-ness actually means in terms of rights, obligations,
compatibility, and community.  Approving such a license would create a legal
mayhem.

I realize that the TGPPL is trying to arbitrate in a more finite way, but
the problems it creates remain (especially when one considers the problem of
versioning changes and grandfathering or not specific functionality).


>
> This is not to say that TGPPL is the correct implementation but surely
> something more elegant is possible.


As previously argued, the most elegant solution is to pick a position and
stick with it, rather than try to create a legal superpositioning that one a
privileged actor can control.

M