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

[Tzeng, Nigel H.]

You know, I was pretty surprised there were two folks interested in time-bounded licenses like this when reading ESR's blog comments*.

I am curious that the theory that more proprietary software developers/companies would use a time bounded open source license if they knew they could garner a years worth of "secrecy rent" did not get more discussion here.  Looking at the archive, I don't believe it was quite phrased that way but I think it would be the primary draw of such a license for some folks that are looking to balance income and greater good.

I'm not convinced that this theory has a lot of merit (vice simply dual licensing using GPL) but 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.   It more like AFL or Non-Profit OSL variants than simply OSL with a waiver you can ignore downstream.

The reason you wouldn't want the waiver to be removable is because if you're a developer or company releasing under this license with the expectation that you can take ANY derivative of your work, improve it and sell it for a year, you don't want someone downstream stripping you of that ability on what was your work you put out for the common good.  You get this in exchange for allowing some other developer or company take your work, improve it and compete with you for a year with the knowledge that their competitive advantage become part of your feature list in the not too distant future.

Independent contributors might also be more inclined to participate with the knowledge that any their improvements used in the commercial product are guaranteed to reemerge along with the other new features in a year.  Some users might be more willing to pay for a product when they know the outcome is source in a year.  They get the benefit of the current "pro" version in exchange for their financial support without the proprietary lock-in.

All without CLAs or other entanglements.  I think that ideally that is their objective.  If it really pans out that way, I can see the attraction and perhaps otherwise closed source might be made open and we might even get a new sustainable open source business model out of it.

That said, I echoed Matthew's objections about code escrow and trust.  This is not an issue that can be easily dismissed.  My recommendation is for Zooko and/or Ajay to create a modified GForge site that automatically released code 12 months after check in and the license be modified to require that folks use that or some other equivalent escrow service to ensure (or at least increase the likelihood of) compliance with the license.  Bonus points for having the code encrypted in the repository so not even the site maintainers can see the code for a year.  You make a release or a patch for anyone and you need to check source for those changes into the repository at the same time so the clock starts.  Extra bonus points for having a software storefront as well.

If they were to put the effort in making sure the infrastructure for such a time delay was as painless as possible and as secure as reasonable for both project owners, contributors and users I would hope that the OSI would be kind enough to assure potential contributors that TGPPL v1 was indeed OSD compliant and was waiting until the end of some experimental period (say 2 years for 2 full release generations) before full OSI license approval was granted for TGPPL v2 (after a couple years experimentation you've probably learned what needs tweaking).

This would have the benefit of giving the concept the maximum possible traction and chance for success during this experimental period while not producing any immediate license proliferation.  If it is a new successful form of open source, then it's not proliferation at all.

* http://esr.ibiblio.org/?p=658#comment-233052