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

[Tzeng, Nigel H.]

>From: mdtiemann at gmail.com [mdtiemann at gmail.com] On Behalf Of Michael Tiemann [tiemann at opensource.org]

>I find the TGPPL to be complicated in ways not anticipated by the OSD.  I
>believe that one of the goals of any new, innovative open source license is
>that it can be expressed in simple terms.  

>I believe that what people most seek when evaluating open source licenses is
>the answer to two questions: does this license grant me the rights and
>freedoms that I expect (thus permitting me to enjoy the fruits of my labor),
>and are those rights and freedoms well understood and accepted by the wider
>community (thus enabling the network effect)?  The issue of time-boundedness
>is problematic because it means that an observable property may have one
>evaluation at one point in time and another evaluation at another point in
>time, not because of some extrinsic change in circumstances, but because of
>the software in question itself.

I disagree that this license is not simple since it can be reduced to "This is OSL 3.0 with a time delay.  You get the fruits of MY labor 12 months after I release binary."

I do not see how time is not an observable property.  Binary release 19 FEB 2009.  Code release must be no later than 19 FEB 2010.

I can see how trust is an issue that I will indeed release on 19 FEB 2010 but this isn't too different than any other non-compliance scenario.

>For me, a rider or a waiver or an indulgence, or whatever you want to call
>it, that suspends the open source property has no place in being called open
>source.  It may be a wonderful thing that you have created a mechanism that
>automagically creates or releases or liberates open source software from
>special proprietary rights, but it is only in the state of being actual open
>source software that we should make our evaluation.  We should not make our
>evaluation based on the certainty of a promise that can be deferred for some
>period of time.

It would be a certainty of promise to release by a certain date backed by either copyright or contract law.  I'm not certain that you ever get anything more.

>Now: the TGPPL says that the grace period is 12 months.  Who is the OSI to
>say that 12 months is fair and adequate?  If TGPPL version 2 said 12 years,
>how could we say "that's unacceptable"?  Even 12 seconds is problematic
>because somebody could argue for 24 seconds, then 48 seconds, etc.
>
>Instead, I believe the OSI's concern should be "what is true now?  And can
>that truth be trusted for the foreseeable future?"  The TGPPL would set a
>bad precedent that would encourage longer waivers, to the point where the
>fact of the software is that it is proprietary, at least in somebody's
>eyes.  

OSI would not necessarily be saying that 12 months is fair any more than it makes judgements on whether permissive or copyleft licenses are more "fair".  The contributor or user decides it is fair and bases their use on their own criteria.

Of course, as I stated earlier, the time shouldn't be variable so the OSI could refrain from approving licenses beyond 12 months ever.

>And it would be a damn shame for the OSI to approve a license as open source that had that property.

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.

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