The Transitive Grace Period Public Licence: good ideas come around…

I recently came across the Transitive Grace Period Public License (alternate link) by Zooko Wilcox-O’Hearn.  I fonud it interesting because it’s very similar — almost identical — to something I had first starting floating about ten years ago.  I called it the Temporary Proprietary License (TPL).  I’m sure this is a case of “great minds think alike”.  One things that I like about my write up is that I gave some of the rationale behind why this approach is a fruitful one:

A while ago, I was talking to Jim Gettys at the IETF meeting in Orlando, and the subject of software licensing issues came up, and he had a very interesting perspective to share about the X Consortium License, and what he viewed as bugs in the GPL.

His basic observation was this: Many companies made various improvements to the X code, which they would keep as proprietary and give them a temporary edge in the marketplace. However, since the X code base was continually evolving, over time it became less attractive to maintain these code forks, since it would mean that they would have to be continually merging their enhancements into the evolving code base. Also, in general, the advantage in having the proprietary new feature or speed enhancement typically degraded over time. After all, most companies are quite happy if it takes 18-24 months for their competitor to match a feature in their release.

So sometime later, the companies would very often donate their previously proprietary enhancement to the X consortium, which would then fold it into the public release of X. Jim Gettys’ complaint about the GPL was that by removing this ability for companies to recoup the investment needed to make major developmental improvements to Open Source code bases, companies might not have the incentive do this type of infrastructural improvements to GPL’ed projects.

Upon reflection, I think this is a very valid model. When Open Vision distributed the Kerberos Administration daemon to MIT, they wanted an 18 month sunset clause in the license which would prevent commercial competitors from turning around and bidding their work against them. My contract with Powerquest for doing the ext2 partition resizer had a similar clause which kept the resizing code proprietary until a suitable timeout period had occurred, at which point it would be released under the GPL. (Note that by releasing under the GPL, it prevents any of Partition Magic’s commercial competitors from including it in their proprietary products!)

For more, read the full proposal.

6 thoughts on “The Transitive Grace Period Public Licence: good ideas come around…

  1. Actually, this form of licensing is neither good nor necessary. Look at the sheer amount of free software that has been written, released, and/or modified by so many software companies in traditionally GPL’ed software. While companies may complain that they are not getting their money back, if free software was not economically important to them, then they would not be interested in it at all.

    Everyone, including for-profit companies, benefit from a completely free software model without these kinds of restrictive or conditional or transitive licensing models. It may serve the short-term interests of some companies to have code they’ve produced be released on such a restrictive license, but in the long term, it will only poison the free software world with even more additional licenses and distracting from the whole point of the principles of freedom.

    Given that you are a Googler, I am worried that this might be a reflection of a trend toward a less open Google in the future. Looking at the recent decision, for example, to standardize on H.264 for YouTube’s codec also makes me worry that Google is changing its tune when it comes to its support for free software. Can you offer some assurances that this is not the case?

  2. Because this is a bolt-on clause, I don’t think it raises a license proliferation problem. However, I’m not at all sure that this business model should be encouraged. I think it might trigger a repeat of the Unix wars. 1980s-1990s Unix vendors kept trying to differentiate their platforms on features, using the tactics Gettys describes among others, and it was an unmitigated disaster for everyone involved. Platform innovation needs to happen without divergence, because application authors want to write their code only once more than they want anything else.

  3. @1: Basil,

    There are two answers to your question. The first is that (and this is spelled out in the full TPL proposal, which I’m not sure if you read) is that code which uses this is dual licensed under the GPL and the TPL. So people who download code have their choice of whether they want to use their code under the GPL or the TPL. If they want to use the GPL, great! They can do so release their changes as required by the GPL, and the fact that the original upstream project is under the GPL/TPL dual license doesn’t matter. It does mean that people who wish to contribute code to the project needs to be willing to have their code be dual licensed, but the dual license situation is one that most developers can easily understand, since it’s by no means unusual. For example, Perl is dual licensed under the GPL and the Perl Artistic License. I don’t think dual licensing is likely to “poison the free software world”, especially when one of the licensing choices is GPL.

    The second answer I can give is that your complaint strikes at the heart of the free software / open source software philosophical divide. It is true that there are many companies that have contributed a huge amount of code under free and open source licenses. It is also true that there are certain classes of contribution that company might hesitate to make simply because it’s a huge amount of work, and if they can’t make a business case that includes their being able to recoup their investment plus some reasonable profit, they won’t do the work. I’ve seen it happen, where a proposal to do some enhancement is shot down because of a concern that a competitor would turn around and use the feature so quickly and without having to pay the development costs associated with that feature, that the company who was considering would end up losing money on that particular proposal. Typically when this happens, the idea simply never sees the light of day, and it’s never pursued, so people outside of the company never realize what the project might have been able to gain, if they were willing to let someone add a private feature and _not_ have to release the changes for it for some limited period of time.

  4. @2: tytso,

    You have allayed most of my concerns in that the code is dual-licensed in the first place. This makes it more akin to how MySQL has released their code under a dual-licensing model, and indeed, it has worked out well for free software in the past. Even Richard Stallman has commented non-negatively on the dual-licensing model.

    As for the second point, I wonder at the use case that you have presented. Would a company that was so uptight as to not want to contribute back to a free software project that they are utilizing and thus getting free maintenance of their feature really see much benefit to holding on to it and then releasing it? They probably would just say, “I’ll just keep it, thank you very much.”

    The major point is that it muddies the water of software freedom – yes, that is the point I am trying to make. The idea behind that (and I know I don’t have to explain it to you, but others may not know) is that free software must remain free – that’s the basic imperative that all GPL licenses aim to achieve. Does the TPL affect this, because it’s not clear to me?

  5. Hi, Ted

    Your ten year old variant and this latest need look no further than the Ghostscript model of a lagged one year, crossover from a restricted, to a FOSS friendly release model. One concern of course is folding in security matter in a timely fashion, but during the lock-up year, the proprietary firm alone ‘owns’ responsibility for issues; after that the usual models can roll in.

    — Russ herrold

  6. @5: Russ,

    The difference between the Ghostscript model and what I’ve described is that the Ghostscript model only allows the proprietary to new features which aren’t released in the GPL version until N months later. With the TPL, any company may add proprietary features, so long as they inform the open source project of the fact that they have exercised the TPL option, and then release the code N months later. (Perhaps there would be a requirement that they put the code in escrow so that the release _does_ happen N months later, even if the company is a startup which has flamed out. That’s an implementation detail.)

    The TPL has a mandatory “tell the open source project” feature which isn’t in the TGPPL, which I think is a good thing, since it hopefully helps discourage cheating, at least by a little, but more importantly, it means that the open source team can either decide to (a) wait until the new feature is made available, N months later, or (b) if it’s a feature which is trivial and/or desireable enough, maybe they’ll decide to reimplement it right away and put it in the open source version.

    In any case, it’s the fact that anybody can temporarily enhance the project with proprietary feature which makes this fundamentally different from what Aladdin did with Ghostscript.

Leave a Reply

Your email address will not be published. Required fields are marked *