X
Tech

Attribution may matter (in open source licensing), but making the Open Source Initiative whole matters first

Just before the Thanksgiving holiday here in the US, I wrote about how a handful of vendors including customer relationship management solution provider SugarCRM were distributing software under licenses that they claimed to be open source licenses, but that don't appear on the Open Source Initiative's (OSI) official list of approved open source licenses.
Written by David Berlind, Inactive

Just before the Thanksgiving holiday here in the US, I wrote about how a handful of vendors including customer relationship management solution provider SugarCRM were distributing software under licenses that they claimed to be open source licenses, but that don't appear on the Open Source Initiative's (OSI) official list of approved open source licenses.

Since 1998 when the OSI was first formed, the technology industry has generally recognized it as the keeper of the definition of open source (known as the Open Source Definition or OSD) as well as the consortium that ratifies certain software licenses such as the GNU General Public License (GPL) and the Mozilla Public License (MPL) as open source licenses: ones that conform to the OSD. An increasing number of software products are being licensed under the heading of open source while the licenses assigned to them have yet to be blessed by the OSI. That recognition however, is an unofficial one. The OSI doesn't have a trademark on the term "open source" which means that it has no legal leverage over when, how, or in what context the phrase gets used. But, even without that legal leverage, developers both small (eg: individuals) and large (ie: IBM and Sun) have respected the OSI's defacto role by either picking from the OSI's approved list of licenses when getting ready to open source some software or by seeking the OSI's seal of approval on a newly authored license before claiming that license to be an open source one, or releasing software under it.  

The OSI has an official but easy process for seeking that seal of approval. Newly authored licenses need only be submitted to an OSI mailing list known as License Discuss. According to the OSI's web site:

OSI has also established a mailing list to review licenses submitted to license-approval at opensource.org. To subscribe, send mail to license-discuss-subscribe at opensource.org. Unsubscribes go to license-discuss-unsubscribe at opensource.org. The usual -request address works as well. This list is archived here.

Once a license has been submitted for approval, anyone with an opinion on the worthiness of the license is free to chime in with their thoughts and comments. Not only will the OSI's board members weigh in with their opinions, so too will other individuals such as Bruce Perens who have played a long term role in drafting and revising the OSI's Open Source Definition. 

While the OSI has had its critics over the years (for everything from having too many licenses on its list to leadership issues to its idealogical differences with the Free Software Foundation), the OSI process has never really been openly challenged. That is, no one has authored a license, declared it to be open source, and released software under that license without at some point, submitting that license for review to the License Discuss mailing list. To do so was considered sacreligious by the open source community.

Then came SugarCRM.  SugarCRM isn't unlike other commercial ventures (eg: Red Hat) looking to capitalize on the popularity of open source. The idea is pretty simple: evolve a product through the sort of community-based development that's common to many open source software projects and monetize that product by offering a layer of support services around it. SugarCRM's tagline (built right into its logo) even says "commercial open source."  On SugarCRM's web site, there's even text that describes SugarCRM motivations:

We thought there was better way. Why not write our product in public and distribute it through an open source license?

And that's exactly what SugarCRM did, but with one wrinkle. The license it released its software under -- the SugarCRM Public License (SPL) -- is one of those licenses that does not appear on the OSI's approved list of open source licenses. In fact, in the two years since SugarCRM was first established, it has yet to submit the SPL for consideration to License Discuss for review. In certain open source circles, particularly those that are faithful to the OSI, doing what SugarCRM has done is not only considered defiance of the OSI, it's considered the open source version of living in sin. Other companies have followed in SugarCRM's footsteps by following almost exactly the same course of action with their own licenses, none of which have been submitted to the OSI's official process.

According to SugarCRM Chairman, CEO, and co-founder John Roberts, he knew that, at the time the SPL was first drafted, it would have been turned down by the OSI. To SugarCRM and the others that have followed suit, the OSI's official seal of disapproval would be far worse to have than no seal at all. 

With a growing number of companies following in SugarCRM's footsteps (including Socialtext, Scalix and Zimbra), the situation as it stands has created divisions in an open source community that was already somewhat fractured by the proliferation of approved licenses (let alone unapproved ones). But these divisions run deepest because of the way they are testing the definition of open source and the relevance and potence of the OSI to be its guardian.

On one side are the drafters of the OSD (and their supporters) who believe that one of the primary tenets of open source is that developers should have the freedom to control any and all parts of a software product's user interface. On the other is SugarCRM and its contemporaries who feel in their hearts that they're justified in requiring open source developers who might be modifying their (SugarCRM, et alia's) source code to make certain elements (in this case, attribution and linkage to SugarCRM, et alia) omnipresent in their user interfaces.  So far, those requirements are being codified into this new wave of licenses which are, invariably, modifications to the MPL.  

In my post last week, I spent a bit of text on why attribution is important to companies like SugarCRM (and what the potential business risks are without it) but remained neutral on whether or not requiring attribution should or shouldn't be allowed into an open source license.

SugarCRM Chairman, CEO, and co-founder John Roberts replied to that post with a discussion of why attribution matters. Roberts also cc:ed that reply to OSI's License Discuss and the discussion over there has been quite vibrant since. According to Roberts, it was his first post ever to License-Discuss. Earlier today, by phone, he told me he knew this day would come. Just getting the conversation started, which was what I had hoped to provoke with my original post, is a big step in the right direction.

The reason for my neutrality is not that I don't believe I could make arguments for one side or the other. In fact, if I were in the position to use or host SugarCRM (and I am, but that's a different story), I'd have no objection to the attribution requirements. My problem is that focusing on the attribution argument right now is a distraction from what in my estimation are the more pressing issues for ZDNet's open source-using readers (and developers) and the open source community as a whole.

The first of these is the fact that there is an increasing number of software products being licensed under the heading of open source while the licenses assigned to them have yet to be blessed by the OSI. This situation requires immediate attention since end-users and developers could easily be misled into thinking that the software meets the commonly accepted definition of open source when, so far, there is no such consensus. The interim solution that I've proposed that has so far been completely ignored (unless someone made changes without pointing me to them) is some form of disclosure. For example, a footnote everywhere these vendors use the term open source to make it clear that the open source licenses in question are so far unapproved licenses according to the OSI.

The second of these is that the more vendors feel free to pursue their own definitions of open source, the more they push the OSI closer to a precipice that the open source community can't afford to have it be near. When it originally avoided the OSI's process for certifying the authenticity of its license, SugarCRM set a precedent that others have already followed. If the trend continues (and it shows no signs of abating), the total number of unblessed licenses will at some point out-number the number of blessed ones. If the SPL takes an inch, which is my way of paraphrasing how Roberts' has characterized what SugarCRM has done (and I'm not concurring, I'm just using it for comparison's sake), another unblessed license that takes a mile, or maybe even two will eventually turn up.  Sooner or later, "open source" will become nothing more than a meaningless catch-all phrase that, by virtue of standing for all sorts of licenses (blessed and unblessed), actually ends up standing for none of them.

Condemnation of SugarCRM, Roberts, or the other companies that have followed suit (and their CEOs) would be highly counterproductive at this point. Roberts is quick to point out that he employs 30 professional software engineers who contribute oceans of internationalized, modifiable source (I'm refraining from "open source") to the world (SugarCRM supports more than 50 languages). He's fairly certain that no other software company is as prolific a generator of such code (officially open source, or not) as SugarCRM. I can't vouch for this claim but, if it's true, or even if SugarCRM ranks 2nd or 3rd in the outpouring of code, the company still represents such a significant force and potential ally that the OSI should court it with diligence rather than arrogance.  

Condemnation of the OSI for not putting its foot down (as some have done) or for sticking too hard to certain ideals doesn't work either. The OSI isn't perfect. But until something better comes along, it's all the open source community has got in terms of what it does (I'm not counting the Free Software Foundation since it focuses on free software licenses which are open source licenses, but not necessarily vice versa).  We're talking about a group of people that, for the most part, believe so strongly in open source that they're willing to trade a significant amount of their personal time to the continued evolution and betterment of the open source community. It's a labor of love. No one doing work for the OSI is making a career out of it. I think someone should be. But that's a story for a different day.

The situation is loaded with all sorts of irony and there's a very important reason for SugarCRM and all of those who followed in it's footsteps to do their part to restore the integrity of the OSI's time-honored procedures. SugarCRM has chosen to associate itself with "open source"  because it sees that association as being very positive for its brand (and it is). The very reason SugarCRM and others including Red Hat, IBM, Sun, etc. are able to make such a positive association with something so meaningful is that the definition of "open source" has been closely guarded by the open source community under the auspices of OSI. Had that definition not been so closely guarded by someone (OSI or otherwise), then, by now, the phrase "open source" would be far less meaningful than it is today and it would carry far more confusion than the positive connotations that it does.  In other words, it might not be the sort of force that SugarCRM or any other vendor for that matter would want to associate their brands with.  Today, should the definition of open source be allowed to erode unchecked, that could be where SugarCRM and the rest end up anyway.

Normally, as an advocate for ZDNet's readers, my job isn't to offer SugarCRM or other vendors advice on how to be more successful. If a vendor wants to play an active role in undermining an important part of its own brand, then that's that the vendor's business. But in this case, what's good for the open source users and developers within ZDNet's audience is actually also good for SugarCRM and the others who have, until this point, avoided interaction with the OSI. In a reflection of that belief, I responded to Roberts' letter with my own post to the OSI's License-Discuss mailing list.

Thankfully, since I wrote my first post on this issue, Socialtext has taken a major step forward with its license. Yesterday, in addition to some steps he took last week to show the OSI he was prepared to work with them, Socialtext CEO and founder Ross Mayfield submitted his company's modification of the MPL -- the Socialtext Public License -- to the OSI's License-Discuss list for review and discussion. Considering the blaze of threaded discussion and emails regarding this issue that have crossed the Internet in the last week, it was a swift and remarkable gesture to the OSI and the open source community. Mayfield opened his post with:

Socialtext which wishes to find a resolution for the attribution issue through the proposal of a Generic Attribution Provision. A copy ofthe following message is available in HTML format here:
https://www.socialtext.net/stoss/index.cgi?attribution_memo
I look forward to the conversation....

I've known Mayfield for sometime now. Like Roberts, he too employs software engineers to write code that is subsequently given away. He saw the wisdom in Dan Bricklin's wonderfully done wikiCalc (which Bricklin always intended to be open source) and started paying him too. From what OSI Board member, Secretary, and Treasurer Danese Cooper has told me so far, the OSI is incredibly appreciative of Mayfield's gesture and willingness to work with the organization. Earlier today, Cooper told me:

The Board has been working for a long time to get one of these licenses posted by a licensor. Up until now our process has definitely depended on the responsible actions of those wishing to call their projects Open Source. This situation was difficult, because the many companies using these modified licenses were holding off on bringing them to us. We're pleased that the public debate can happen now with a responsible company that wants to do the right thing. 

Not only is it the right thing to do for the open source community, it's the right thing to do for Socialtext (for the same reasons that it's the right thing to do for SugarCRM). SugarCRM's Roberts may have led with an example that others followed. But, among those willing to modify the MPL, Mayfield is the real leader now. 

As bitter an issue as attribution is for open source hard liners, hopefully now that Socialtext has placed the issue squarely in front of the OSI (now that the discussion is started, it eventually must end), the OSI will recognize the business realities faced by Web 2.0 startups like Socialtext that truly want to make innovative contributions to the open source community, but that also must make every engineering investment count for themselves as well. Finding some common ground will be a win for everybody involved.

Editorial standards