Most enterprises needn't worry about the "viral" aspect of open-source licenses. Because most enterprises use software for internal purposes, rather than distribute it, they don't trigger the standard open-source requirement to contribute back derivative works. A recent Federal Computer Week article by John Moore does an admirable job of clarifying this.
There are, however, instances in which an enterprise might well trigger the contribution requirement of open-source licensing. If a company sold off a division to another company, complete with the servers running modified open-source software, this would likely trigger a "distribution" and might well affect the value of the deal.
For this and other instances, it's helpful to have a dual-licensing strategy. In this way, customers get all the benefits of open source, especially the ability to view and modify source code to suit their particular needs, without the obligation to contribute back derivative works.
Unfortunately, this perpetuates the problem that Jim Whitehurst of Red Hat has been highlighting: the more software created in isolation, the greater the industry's inefficiency and the higher the cost of software. Dual-licensing doesn't solve this problem. It is, however, a good way to help guide enterprises into open source on comforting terms.
Pierre notes it is "only a matter of time before an open source company decides patents could be used to solidify open source dual-licensing schemes." I think he's right. In fact, I've seen this very issue rear its ugly head within my own company as I've thought through ways to partner with Microsoft and other proprietary companies.
It would be very easy to do as Novell did: Enter into an agreement to make a version of one's software "safe" from patents. It makes Microsoft happy. Presumably it makes one's users happy ("I'm safe from...my vendor and its partners?!").
But it doesn't fix the downstream problem, and it doesn't fix the broken software patent problem. It trades off FUD to make a sale. Myopic and ultimately damaging to one's customers, one's peers, and oneself.
This isn't even remotely intended to be a criticism of any one company or group of companies. It's rather an acknowledgment of an issue that is going to become more and more pronounced over time.
... Read more
Stefano Comino and Fabio Manenti have written a useful paper [PDF] on dual licensing in open source. It's a decent resource for helping developers and vendors figure out why, if, and how to dual license their software. (See here for a useful explanation of what dual licensing means, and Heather Meeker's piece is a must read for anyone interested in the legal ramifications of the practice.)
I found myself agreeing with much of the authors' conclusions, but not necessarily the tone or conclusion, because they seem to see dual licensing as a way to drive sales. Of course, it sometimes undoubtedly is - for some time a large percentage of MySQL's, Sleepycat's, db4o's, etc. sales were motivated by a proprietary license waiting to "rescue" the OEM/customer from an open source license.
... Read more- prev
- 1
- next
