Although there are dozens of open source licenses, there is a general consensus in the IT community that the GNU General Public License (GPL) is the most appropriate for enterprise software development. Recently, however, Sun Microsystems has muddied the already murky waters of open source licensing with its Common Development and Distribution License, version one. In this face-off challenge, IT book authors and consultants Paul Murphy and Bernard Golden take different sides in the GPL versus CDDL debate. After reading both cases, be sure to use our 'Sound Off!' feature to make your opinions known.
Open source with IP protection: Have it both ways with Sun's CDDL
By Paul Murphy
Sun has been talking about OpenSolaris for some time and has actually made Dtrace source available as a first step toward opening all of Solaris 10. That's a great step forward for them, but the question for the rest of us is where to place our bets now that all three Unix genres: BSD, Linux, and Solaris will soon be fully open source productions.
Since the right answer depends on who you are, what you do with Unix, and what you believe is coming next, it's obvious that no single answer is appropriate for everyone. There is, however, a business consideration that does apply to just about every developer outside the computing research and defense sectors. That consideration derives from what Sun is doing with licensing. The whole
What's on the virtual mantelpiece is an anti-patent litigation condition, while what's missing is a GPL like a "viral" component affecting intellectual property. The operative section for the former is, of course, written in the usual turgid legalese. We'll have to wait until this is tested in the courts to really know for sure; but section 6.2, in particular, seems to make the intent clear. Here's an extract with much of the convolution choped out:
"If you assert a patent infringement claim... alleging that the Participant Software... directly or indirectly infringes any patent, then any and all rights granted directly or indirectly to You by such Participant... shall, upon 60 days notice from Participant terminate."
So, this clause is saying that you can't play in the CDDL community and sue other members at the same time. On the other hand, section two of the GPL says: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.'
That clause is functionally missing from the CDDL. In other words, a CDDL developer can have it both ways: working within the open source community while retaining full control of intellectual property.
From a developer perspective, there is one other consideration that makes the Linux versus Solaris decision an easy one: Solaris runs Linux code unmodified -meaning that choosing to develop under the CDDL on Solaris not only gets you access to the SPARC market, but lets you provide both run-time and source support for Linux from the same code base.
So what does a Solaris CDDL developer get: a bigger market, a unified code base, intellectual property protection, some protection from patent infringement claims, and all the benefits of the open source review process. Is that a no brainer, or what?
Why use the Sun CDDL driver's license?
By Bernard Golden
The Sun CDDL open source license looks good at first glance, but is it the big bang that will spawn the creation of an open source Sun community? I don't think so, but readers of Paul Murphy's article on CDDL will see that he does. Let's take a look at his argument and see if it holds water.
Murphy analyzes the Sun CDDL open source license (under which Sun's open source Solaris will be released) and concludes it offers a more attractive opportunity for developers than does Linux. His argument goes something like this:
- If a company using CDDL-licensed Solaris asserts a patent infringement against someone else using open source Solaris, the company forfeits its right to use Solaris. This is a positive, since it offers the using company protection against infringement suits because a patent holder will be unlikely to sue someone if it means giving up the right to use the software.
- The CDDL license does not call for user extensions to the Solaris code base to be made available to the larger community but may be held as proprietary intellectual property. In this way, the CDDL license more closely resembles Berkeley-style licenses which enable organizations to utilize the open source code as the basis for a proprietary product.
- Solaris will run Linux applications natively. Therefore, if you write a Linux app, you have access to a larger market, since it may also be used by Solaris users.
- You gain all the benefits of the open source review process. I'm not sure what this means; perhaps it is a reference to the fact that because the product community can examine the source code, higher quality products may result.
While all of his points make sense, I don't necessarily see how they'll motivate individuals to get involved with open source Solaris and thereby build a Solaris community -- which is the key achievement Sun needs to make the whole effort worthwhile. After all, Sun is having their lunch eaten by customers turning to Linux, so they need to figure out a way to remain relevant to open source-oriented users.
Let's look at each of these points in turn:
- So, a CDDL user would forfeit Solaris access if he or she brings a patent infringement action. This is a good thing. With the cloud of patent litigation hanging over the open source world, a license condition like this might dissuade an organization from pursuing litigation.
This CDDL requirement reminds me of the Mutually Assured Destruction (MAD) nuclear strategy that the US pursued during the Cold War, in which aggressors were motivated to avoid attacking by the knowledge that their societies would be destroyed in return.
On the other hand, I don't know how much this will mean to potential users in the real world. After all, a company that is going to pursue a patent litigation effort is hardly likely to be an open source consumer, is it? I don't see this significantly helping to build a Solaris community.
- CDDL does not require reciprocity of source code release. You can argue this one both ways. Berkeley-style licenses don't require releasing code modifications, while GPL-style licenses do. The *BSD Unix variants, which utilize Berkeley licenses are losing out to Linux in terms of adoption, so it's hard to argue that CDDL adopting this approach will build community.
In any case, the main point of Berkeley-style licenses is to enable companies to build businesses based on converting the open source code base to a proprietary product, which I am sure is not Sun's goal for Solaris. It's not clear this provision will help build a community.
- Solaris will run Linux apps natively. Anyone with a few years in the industry remembers this one from the first time around: OS/2: a better Windows than Windows. Sun won't be any more successful than IBM was with this approach.
- Open sourcing Solaris gives the benefit of the higher quality products that open source offers. True, but, again, how does this build a Solaris-specific community?
Sun has been too clever by half in their open sourcing of Solaris. They desperately need to build a vibrant user community for the OS, but creating a new license does not help that effort. They will spend the next year explaining it to puzzled users, who will be trying to understand what open source Solaris is, rather than building new apps for it. For a community that already is unhappy with the semi-open Java product, the CDDL is Act II.
I think Sun is in for a very disappointing experience with the CDDL. They haven't really provided any compelling reason to begin working with open source Solaris, and it's unlikely that people using or considering using Linux are going to change their mind. Open sourcing Solaris may appeal to the ever-shrinking band of committed Solaris users, but Sun is going to have to do better if it wants to regain its tech heavyweight crown.About the authors: Bernard Golden is CEO of Navica Inc., a systems integrator based in San Carlos, Calif. He is the author of Succeeding with Open Source (Addison-Wesley, August 2004) and the creator of the Open Source Maturity Model (OSMM), a formalized method of locating, assessing, and implementing open source software. Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry.
Interview: Authors slam Sun's open source strategy
Send your feedback to the SearchEnterpriseLinux.com news team.