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

[Bruce Perens]

I didn't expect to have an embarrassment of riches when I wrote the OSD. 
That we have one is a problem for the users that should not be made worse.

The TGPPL's main failing, IMO, is its questionable utility weighed 
against the existing licenses and the cost to the users of having 
another. This calls on OSI to reject it for a reason I didn't write into 
the OSD, but which is still their duty.

Other licenses are poorly written, self-contradictory, or impractical. 
Those aren't in the OSD either, but it's OSI's duty to reject them 
rather than inflict them on the user community.

    Bruce

Russ Nelson wrote:
> Christopher Schmidt writes:
>  > It seems clear to me from watching this list over the past two years
>  > that there is a limited relationship between "Meeting the OSD" and
>  > "Being approved by OSI".
>
> True.  Unarguable.  Zooko agrees with you, because he already claims
> that his software meets the OSD, and yet he wants OSI approval on top
> of that.  Whatever is the difference between those two things, it is
> something desirable.  Since it's a scarce commodity, we should expect
> people to be willing to pay a price to get it (ECON101).
>
>  > because OSI has a policy of encouraging license submitters to not
>  > submit licenses which may be similar to existing ones. This is
>  > understandable, but given that, I can't (personally) seriously
>  > accept that the definition of 'open source' should be limited to a
>  > set of licenses that are managed by OSI.
>
> There is a commons here, in the Garret Hardin _Tragedy of the Commons_
> sense.  From your perspective, I can agree with you.  Why should you
> be limited to a choice of one, two, five, ten, or seventy licenses?
> It's no skin off your back if you choose the Chris Schmidt Public
> License for your software.  But the problem is that your *users* need
> to understand your license, and worse than that, if party A has
> responsibility for party B, and they give party B a distribution with
> your software as an installation possiblity, party A needs to
> understand your license.
>
> And every other license written by every other developer whose
> software is in the distribution.
>
> Every little bit of pain you inflict on your users through your choice
> of a non-OSI-approved license becomes a big pain in the ass for
> someone responsible for the legal compliance of a lot of software.
>
> It's our job to manage the commons.  Sometimes that means saying "no."
> It doesn't make you any friends, but it does save the commons from
> overuse.
>
>