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.

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

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?

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.

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?