The TPL proposal

Version 0.92, Feb 23, 2003

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!)

While this model worked well for the X Consortium, there have also been many other examples of companies which have taken BSD-style licensed code, and made improvements to the code which were never contributed back to the community. So, I started thinking about ways in which companies would have an incentive to develop and improve an Open Source product, but yet have a method of enforcing the timeout period after which those enhancement could be delievered back to the community

I believe this can be done very simply by the use of an auxiliary license in addition to the standard GNU Public License. I will call this auxiliary license the Temporary Propietary License, or TPL. Developers who want to follow this model simply release their code so that people who wish to use or distribute their software have their choice of either the terms of the GPL or the TPL.

The TPL allows derivative works to be released without source code (i.e., in a proprietary fashion), but only for a limited amount of time. After N months (where N would likely be somewhere between 12 and 18 months) of the software being released, the company/person doing the proprietary distribution must make the sources available under terms which specify that the contributed code must be made available under the terms which are no more restrictive than that of the original code base, and must send a copy of the modified sources to the original maintainer.

There are some other wrinkles which might be included in the TPL, such as not starting the clock during the beta-testing period, but requiring that the original maintainer be notified at the point where the company wants to distribute beta-test code outside of their company. To avoid an obvious loophole, there might also be a limit to the length of the beta-test period which could be periodically waved by the maintainer if there's some good reason for the extra-long beta cycle --- since database systems traditionally has required a much longer testing cycle.

However, all of these possibilities are merely elaborations on the same basic theme, which is to allow companies the temporary right to benefit from their investments, but to them get those improvements back into the Open Source base.

Benefits to the TPL

As I have already discussed, gives an incentive to companies to make singificant improvements to code bases which are licensed under the TPL/GPL combination. It allows them to gain a temporary advantage over the competitors if they can find a significant way to improve the performance or functionality of the TPL code base. However, these changes must be eventually given back to the community, where it can be used to build further extensions, possibly by some other company. At the risk of misusing a faddish management word, the TPL is a license which encourages "coopetition".

Another further advantage of the TPL is that it guarantees competition, which in the long term will ensure higher quality and lower prices of products based on the TPL codebase. It also protects against the danger of a single company developing a singificant improvement to the TPL codebase, but who then goes out of business or withdraws from the market at a later point. Customers can purchase a TPL-extended product from a company confident that even if that company decides (or is forced) to abandon that product, the company-specific propietary extensions will eventually become generally available so that others will be able to support that product, or bring the functionality into their products.

Using the TPL

For a new project, using the TPL is fairly easy; it simply requires that the initial developer or group of developers be willing to release their code under a license which allows licencees to redistribute and/or modify the code under either the GNU Public License or the Temporary Propietary License. (For example of such language, please see how Perl is licensed; it gives users the choice of either the GPL or the Artistic License.) The project leaders would then have to make sure that people contributing code the project are willing and able to license the code under the same choice of licenses. Note that just as a BSD-licensed or LGPL-licensed project must be careful not to accept GPL-licensed code, a TPL project must also be careful not to allow the introduction of code which is available only under the terms of the GPL.

For pre-existing project, converting the project to use the TPL may present some challenges. These difficulties are exactly the same as required when wanting to change licenses from a more restrictive license to a more library license. For example, if a project wished to convert a library from using the GPL to the LGPL, that project would have to contact all of the copyright holders and make sure that they all agreed to this change in licensing. A similar situation arose early in the days of the Linux kernel, when Linus Torvalds originally released Linux under terms that were more strict that the GPL. When he decided to release Linux under the GPL, fortunately the Linux development community was small enough that he was able to contact everyone and get their agreement to change the license.

Potential objections to the TPL

Objection: The TPL is not an Open Source License

The TPL does not exist as a formally drafted license yet, so it can not be certified by the Open Source Initiative as either being or not being an Open Source compliant license. However, the TPL license as proposed in this paper actually would be Open Source compliant; after all, BSD-style licenses, which allow companies to create derived works which have a propietary license and which are sold as propietary software. What the TPL license does is to require that such derived works be eventually be released under the combination of the terms of the original TPL project (that is, users have the choice of either the TPL or the GPL).

In a sense, what the TPL represents is a compromise between a MIT/BSD-style license and the GPL. An MIT/BSD-style license allows the creation of propietary derived works without any controls, while the GPL does not allow the creation of propietary derived works whatsoever. What the TPL allows is the creation of a proprietary product derived from the TPL code base, but in such a way that the changes eventually become available to the community at large. And since the BSD, MIT, and GPL licenses are all considered "classic" licenses which are approved by the OSI, it seems pretty obvious that once drafted, the TPL should also be easily accepted by the Open Source Initiative as an OSI approved license.

Objection: The TPL would cause a slower development pace

It's true that if people are decide to to wait for the propietary enhancement before doing any other work on the Open Source project, that this would significantly retard the development pace. My assumption was that folks would continue to do work on the project, and that companies who took advantage of the TPL exemptions would only be doing so for major enhancements, for which it would be worth the effort for the company to maintain a separate propietary code fork away from the mainline, and worth the effort for the TPL developers to merge the propietary changes back into the mainline project later. After all, if the enhancements are only minor ones, the moment they get announced to the community, some freeware developer will probably simply implement it over the weekend, and fold it back into into the tree, and thus nullify the competitive advantage of the propietary extension.

Indeed, as long as there are Open Source developers which are continuously improving the tree, companies will have an incentive to contribute their changes back into the mainline, perhaps even earlier than the stipulated time period, since otherwise they will have to continuously merge their changes back into each successive mainline release of TPL'ed product.

On the other hand, if you take a package like the GNU Shell Utilities which had not a single release between 1997 and 1999 (at the time of the original conception of the TPL, GNU Shell Utilities had seemed completely moribound with an entirely unresponsive maintainer), then companies which make propietary extensions won't have any incentive to contribute the changes back until the TPL forces them to give those changes back to the community. But in that case, merging in the changes will probably be very easy, since the Open Source community has been lame and hasn't been making any changes to the code base. At least the code base will get the improvements funded and made by the commercial company!

Objection: The TPL allows companies to exploit the code

This is somewhat true, but only temporarily. After the timeout period has passed, the sources to the propietary extensions become available.

Furthermore, the free version of the TPL project remains available. Hence, if anyone is willing to pay for the commercially enhanced version of the project, it will either because they are stupid (such as the KGB agents who paid $100,000 dollars for a copy of GNU emacs that anyone could have gotten for free over the Internet), or because the company's enhancement really was worth the asking price. So in reality, the company is really receiving money for the value that the company added; not for the value originally created by the Open Source/TPL developers. What customers are and aren't willing to pay for demonstrates whether or not the propietary enhancement has any value or not. So to say that work of the Open Source/TPL developers is being exploited is really quite a stretch.

While it is true the Open Source/TPL base has enabled the company to make a buck by making and selling the propietary enhancement, hopefully that Open Source developer will be mollified knowing that in the long run, the propietary enhancement would be made available to everyone. (Or they might just decide that said enhancement was so trivial to implement that they would simply implement it on spot, thus rendering the propietary enhancement irrelevant.)

Objection: The TPL encourages code forking

As Linus Torvalds has pointed out, in the Open Source world, there always are forks; whenever someone creates a patch and submits it for inclusion, a fork is temporarily created. And certainly "code forks" in the form of the Alan Cox, David Jones, Andrea VM trees, et. al, have certainly not hurt the Linux kernel development community; in fact, they are an important and invaluable part of the Linux development process.

In the case of a TPL project, as long as there remains an active base of Open Source/TPL developers improving the project, the folks who pay the burden of the code forking are the progammers at the company who have produced propietary enhancements, since the Open Source code base will continue improving and gaining new features that will not be in their propietary fork.

At the end of the timeout period, when the propietary changes become available, one of three things will be true. Either (1) The effort of implementing the features that were in the propietary enhancement is far greater than the cost of merging the changes into the Open Source mainline, in which case the Open Source developers will be very happy to do the integration. Or, (2) The changes are relatively trivial, and so it isn't worth the pain of merging the code fork --- in which case developers can just simply reimplement the feature. Or, (3) The changes were really trivial, and the new feature has already been included in the Open Source codebase.

Hence, in the context of the TPL, the risks of code forking really aren't as big as they might first appear. Indeed, the whole point of the TPL is to allow temporary propietary forks of an Open Sorce code base, in order to encourage companies to make improvements to the project that will eventually be contributed back to the Open Source code base.

Conclusion

I have presented in this paper the concept of a new auxiliary license: the TPL, which I believe combines the best of both the Open Source "hordes of developers on the Internet" development model with the private corporate development model for software. I've tried to outline some of the potential benefits of the TPL over more traditional Open Source licenses, and tried to answer some potential objections to the TPL. If folks believe that the TPL is a useful, viable concept, the next step would be to draft some actual legal language which embodied the concepts of the TPL.

Afterword

The original idea of the TPL came to me in the fall of 1999. This was during the height of the dot-com boom, and during the very peak of the Linux mania. Red Hat and VA Linux were just about to have their respective IPO's, and at the time, it seemed that VC money was flowing like water, and concerns about the viability of companies funding Open Source development projects were very far away. So at that time, there did not seem to be much interest in the concepts behind the TPL, and so I shelved the project.

Four years later, with many companies who had tried to make Open Source a part of their business plan either completely gone or struggling to make a profit, it may be time for people to reconsider the ideas behind the TPL. While large companies such as IBM have found ways of making money while engaging and investing in Open Source technologies, smaller companies such as VA Linux Systems were not able to achieve the same level of success. For smaller companies, engaging in developing software for a TPL project might represent business model which is more workable.

Theodore Ts'o