The next time you see the phrase "open source" used in association with some software, be advised that you'll need to take that claim with a grain of salt. That's because beauty (what qualifies as open source) is now apparently in the eyes of the beholder rather than the eyes of the Open Source Initiative -- the supposed keeper of the official definition of "open source" and the consortium to which open source license authors typically turn to have their licenses ratified as adhering to that definition. The result? A collection of new licenses (and software licensed under them) are turning up that claim to be open source licenses. But according to the OSI's official list of approved licenses, they are nothing of the sort. Even worse, some of these licenses aren't up for consideration. The discrepancy raises three important questions:
- What right do the authors of these licenses have to say that they are open source licenses when they are not on the OSI's approved list?
- What right do software companies have to say that software licensed under these unapproved licenses is open source software?
- Why is the OSI so weak that it can't put it's foot down, and keep the public informed of what's going on? (The OSI is very aware of the situation.)
The discrepancy also creates a serious legal pickle moving forward (I'll get to that in a minute).
I've been sitting on this story since August because it's so big that I've had a tough time getting my head and text around it all. I've interviewed practically everyone involved too. There are so many sides to the story that I can't keep track of them. So, I've decided to eliminate a lot of the testimony and research and just report on the facts with some of my opinions so that the conversation about what should be done can begin. Thankfully, the people on all sides to this issue have agreed that they'd like to see the problems worked out.
Look around you. In today's world, we are surrounded by things that claim to be authentic that are not. Walk down any New York City street and you are likely to see popular brands like Nike, Rolex, and others getting completely ripped off by the sellers of unauthentic merchandise. Have you ever seen those blue and white dishes with images of the Dutch countryside on them (for example, a windmill). My wife is Dutch and one thing I learned from her is that you should turn those dishes over to make sure they are authentic Delft Blau. Everything else is a knock off. I never new that. Then again, what does it matter? As long as I like the dish, should I care if it's authentic or not?
The same question now comes up for those in the open source community.
A growing number of software providers including SugarCRM, Socialtext, Scalix, and Zimbra have taken it upon themselves create their own derivatives of the Mozilla Public License. The MPL is an an OSI-approved license. In discussing the matter with them, they justify the practice by pointing to other precedents (including each other), some of which they claim have the OSI's blessing, and the rules of the MPL do permit minor tweaks to its language.
However, open source experts such as Bruce Perens and Larry Rosen whose careers are intertwined with the creation of the open source definition, tell me that these new MPL derivatives cross the line of what's considered an acceptable tweak.
The bottom-line remains unchanged. Regardless of what the OSI has blessed before, the SugarCRM Public License, the Socialtext Public License, the Scalix Public License, and the Zimbra Public License are not on the OSI's approved list. So what right do they have to refer to these licenses as open source?
The authors of these licenses (and the purveyors of the software licensed under them) also cite a significant business risk that didn't necessarily exist when the Open Source Definition was crafted (and modified). In most cases, the user interface to the software in question is browser-based and companies like Socialtext survive on their ability to service users of their software. For example, not only does Socialtext support companies than run the company's namesake wiki software on their own servers, it also offers a hosted version so that those interested in using Socialtext's wiki software don't have to install their own versions. But, under any of the existing open source licenses, one challenge for companies like Socialtext, Zimbra, Scalix, and SugarCRM is that nothing prevents a major internet player like Google from taking that Web-based open source software and offering the exact same hosted services that they do, thereby using their own software against them.
To mitigate that risk, this new breed of MPL derivations requires licensees to display certain hyperlinked images and/or text on some or all of the Web pages that are driven by the software. For example, according to exhibit B of the current SugarCRM Public License:
However, in addition to the other notice obligations, all copies of the Covered Code in Executable and Source Code form distributed must, as a form of attribution of the original author, include on each user interface screen (i) the "Powered by SugarCRM" logo and (ii) the copyright notice in the same form as the latest version of the Covered Code distributed by SugarCRM, Inc. at the time of distribution of such copy. In addition, the "Powered by SugarCRM" logo must be visible to all users and be located at the very bottom center of each user interface screen. Notwithstanding the above, the dimensions of the "Powered By SugarCRM" logo must be at least 106 x 23 pixels. When users click on the "Powered by SugarCRM" logo it must direct them back to http://www.sugarforge.org. In addition, the copyright notice must remain visible to all users at all times at the bottom of the user interface screen. When users click on the copyright notice, it must direct them back to http://www.sugarcrm.com.
If Google decided to offer a browser-based CRM service that was based on SugarCRM, any of the SugarCRM-driven Google Web pages that an end-user sees would have to display SugarCRM's logo and copyright notice according to the above language (which is very specific about location, link text, and image size).
Bruce Perens says classifies this new breed of software as "badgeware" (since it must display what amounts to as a badge). Perens, Rosen and others say it flies completely in the face of the spirit of open source, which traditionally leaves user interface decisions completely up to the developer. On the other side are folks like Socialtext CEO Ross Mayfield, Scalix CEO Glenn Winokur, and Zimbra president and CTO Scott Dietzen who point to OSI-approved precedents such as the Attribution Assurance License that require attribution and linkage to a software's author to appear on a splash screen when the software is first started. Folks in favor of the "badgeware" approach (they don't call it that) say that what they're proposing for Web-delivered applications (which often don't have "splash" screens, especially when bookmarks are used to go straight into their bellies) isn't all that different.
Quite frankly, I see the rationale of both sides. As browser-based applications become increasingly more viable, who would want to see the tools created by innovators like Socialtext, SugarCRM, Zimbra, and Scalix get used against them without at least some credit. On the other hand, it's a seriously slippery slope once the OSI allows such unapproved licenses to proliferate completely unchecked. At some point, as long as third parties are allowed to call whatever they want "open source" without being subject to the publicly vocal community and scrutiny of the OSI (or some other body), the meaning of "open source" becomes completely meaningless.
At the very least, wherever these open source licenses appear, or are cited, they should be footnoted with (1) a disclosure that they are not OSI-approved and (2) a disclosure as to whether such approval is being sought and relevant links to see what the status of that application is. For example, Zimbra's tagline which says, "the leader in open source messaging and collaboration," should be footnoted with a statement that the Zimbra Public License is not OSI approved. Today, such disclosures are sorely lacking, which in turn could mislead those who think, just because something says it's open source means that it is, according to the OSI.
One serious legal issue that could arise if developers are misled has to do with patent covenants. Moving forward, we are likely to see more patent holders like IBM issue patent non-assertion covenants to the open source community that remove the threat of a patent infringement suit should open source developers include implementations of one of IBM's listed patents in their code. Like many other legal documents, such non-assertion pledges could very well include defining text, including a definition of open source software. In IBM's Statement of Non-Assertion of Named Patents Against Open Source Software, a reference is made to the Open Source Initiative's list of approved licenses. Says the pledge:
The pledge will benefit any Open Source Software. Open Source Software is any computer software program whose source code is published and available for inspection and use by anyone, and is made available under a license agreement that permits recipients to copy, modify and distribute the program’s source code without payment of fees or royalties. All licenses certified by opensource.org and listed on their website as of 01/11/2005 are OpenSource Software licenses for the purpose of this pledge.
Although I am not a lawyer, technically speaking, a clever attorney could probably argue that this text doesn't necessarily exclude the SugarCRM, Socialtext, Scalix, or Zimbra public licenses. If I'm reading it correctly, it simply states that the OSI licenses listed as of 01/11/2005 qualify as open source licenses. In other words, while it is inclusive of certain licenses, it is not necessarily exclusive of others. IBM does not go so far as to describe what is meant by "modify" or what modifications, such as removal of the attributions at issue here, can be disallowed.
Finally, there is also the issue of who some of these companies have turned to in order to author these licenses. Mark Radcliffe is an attorney who is General Counsel to the Open Source Initiative. But Radcliffe has also authored some of these licenses. According to Larry Rosen, who used to serve as General Counsel to the OSI, having that title doesn't exactly pay the bills. So, its customary for the OSI's legal counsel to also practice law in their area of expertise, outside of the OSI. For Rosen, that involved writing software licenses and the same goes for Radcliffe.
Going back to when I first started investigating this story, Radcliffe told me that to avoid a conflict of interest, he has recused himself from the OSI's deliberations over what licenses should or shouldn't be approved. Radcliffe also told me that he believes that the modifications to the MPL that he has written also conform to the official Open Source Definition.
I am ambivalent about the rock and the hard place I think Radcliffe is in. As an officer of the OSI, he should not be authoring modifications to the MPL and allowing his clients to be discussing those licenses as though they are open source licenses without also requiring them to disclose that those licenses -- his work -- are not OSI-approved.
Radcliffe, as an officer of the OSI, needs to represent its best interests. And it's in the OSI's best interests to make sure that if someone refers to their software as open source, that the software is licensed under an OSI-approved license. If he can't require the necessary disclosure (which would satisfy the OSI's best interests), then he must step down from his role at the OSI. As long as he does neither, both the OSI and the Open Source Definition are vulnerable to irrelevance.
Again, I'm not debating whether or not these licenses should be approved. I can see both sides of the issue. That is the conversation that needs to be had. It's the conversation that every party I've spoken to agrees should be had. But, for the time being, a situation exists where certain licenses are perceived by most people to be "open source" licenses when they are not listed on the OSI's list of approved licenses. And that, in my estimation, isn't fair to the open source community, the legacy of the OSI, or the open source definition.
Update (11/21/06 18:16 PT): According to Socialtext CEO Ross Mayfield, since I began researching the story, Socialtext has proposed the idea of Generic Attribution Provision to the Open Source Initiative. Wrote Mayfield in his blog:
But unfortunately I haven't had a chance to talk with David in a little while, as I would have highlighted that Socialtext submitted a memo to the OSI board for consideration on November 14th -- proposing a Generic Attribution Provision. I've shared the attribution memo on a wiki page, where you can find additional background information on the issue and the proposal to resolve it through a standard attribution clause that OSI could certify for any OSI license. This structure would be similar to how Creative Commons enables attribution as an option.
Mayfield points to OSI board member Danese Cooper's blog, who, one day after the Generic Attribution Provision proposal was submitted, wrote (excerpted):
Some Web2.0 Application companies want to also call themselves "Open Source" although their source code is available only under *modified* copies of licenses that are "OSI Approved". These modified licenses are most often derivatives of the Mozilla Public License. A partial list of the most visible of these include SugarCRM, Compiere, Alfresco, Socialtext...to name a few.
..There are several potential issues with these licenses. First and perhaps most troubling of all, modification of licenses is supposed to trigger a re-submit to OSI before claiming that the resulting derivative is still Open Source.....
....Many of these new Web2.0 company Attribution Licenses go a little further however and require some sort of attribution in the form of a logo or text which must be displayed on web pages built using any part of the covered code. In our deliberations we are trying to determine how much attribution is "too much" to inhibit the Open Source Effect fueled by unintended consequences and maximum code reuse and where to draw a line if indeed a line needs to be drawn.
Cooper's post also reports that while the conversation has clearly started, the OSI's preference is that one of the companies in question actually submit their license for approval and that she thinks one of them is close to doing that. So, the conversation is underway. But there still exists a collection of licenses out there claiming to be open source that have yet to be approved as such by the OSI. Given that, I still feel as though, where these licenses are documented or cited by software that's licensed under them, until the OSI has given them its blessing, some disclosure is necessary.