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

[Tzeng, Nigel H.]

>On Feb 19, 2009, at 13:17, Stefano Maffulli wrote:

>> On 19/feb/09, at 05:41, Tzeng, Nigel H. wrote:
>>
>>> I think that it is a new trait that probably isn't covered by
>>> another license and deserves more than being a waiver if it is
>>> indeed a new open source (sub?) genre.
>>
>>
>> This is not a new license. It's a license similar to other existing
>> ones with an additional clause that sets a time based deadline.
>> Software released under the TGPPL falls under the Open Source
>> Definition only when the time has passed. Until then it's not open
>> source software.

>Having followed the discussion, that's my conclusion too. As a free-
>standing license I don't believe it would qualify as Open Source
>because of that initial period where the four freedoms are not
>available. I'd be surprised if the OSI Board approved it. That's not
>to say a company attempting a business model on this approach would
>fail, but their software could not be described as open source until
>the initial period had expired.

>S.

OSL has been described as both a license and contract.

"So OSL 3.0 can be both a license and a contract, but at heart it is a license just like GPL or any other open source license, phrased in contract language.

As a legal document, OSL 3.0 is drafted as a unilateral contract in which the Licensor makes certain promises and accepts certain obligations. In return, any licensee who accepts and uses the software must honor certain conditions. In a formal sense, in unilateral contracts licensees don't make promises, they merely honor conditions, and so you will find no language in OSL 3.0 to the effect that "licensee promises" anything at all. For example, the obligation to publish source code is an obligation of the Licensor, not a licensee"

In Michael's Apple example, OSX would not be considered open source because there is no obligation to ever open source OSX.  Hence the dislike of some to permissive licenses.

In this example, there would be a contractural obligation to open source the code within 12 months or be in breach.  Or if you prefer, lose your licence to use the code.  Which ever way is the correct way of thinking of this restriction (license or contract).  Perhaps it is not a freestanding open source license but open source contract.  I don't know, perhaps Larry would comment on that aspect.

To me the biggest question is that how to make this something that happens as a matter of course rather than as a matter of court. Hence the suggestion for a escrow service that makes compliance as painless as possible.

The time period should not be variable but some agreed upon balance between potential business needs and common good.  A pragmatic question that will ultimately be "arbitrary" but hopefully based on consensus what is, in fact, reasonable.  Postulating 12 seconds or 12 years is unhelpful except as an exercise in reductio ad absurdum.

I would ask instead the question whether an open source contract (if license is too rigid a term) such as this would be useful for the community to have.  Saying it's just the same thing as OSL 3.0 with a time clause is ignoring the potential vast difference in how commercial open source could work under this.  

If you prefer we can move that aspect to license-discuss or even license-poliferation since the submitter appears to me to really just want validation that the license is OSD compliant but there's no such mechanism other than OSI approved.