November 28, 2006
Attribution may matter (in open source licensing), but making the Open Source Initiative whole matters first
Posted by David Berlind @ 5:30 pm
EXCERPT ONLY
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.
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 o fthe following message is available in HTML format here:
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.
The Socialtext Attribution Memo referenced above from their Wiki:
Socialtext Open Source Wiki
Attribution Memo
The following was sent by Mitch Radcliffe to the OSI Board on November 13th, 2006:
Socialtext has adopted the attribution provision for its own license (as has SugarCRM, Zimbra, Alfresco, Qlusters and Jitterbit). Socialtext believes that the attribution provision is consistent with the Open Source Definition and serves an important business need. Many open source licenses were developed for infrastructure products such as Linux, but the new open source application products, particularly given the increase of large company “distributions”, have different needs than Linux. These application products could be “lost” in the larger distributions. The obligations imposed by the attribution provision are very similar to the reproduction of legal notices which are found in virtually all open source licenses.
However, we understand that attribution may cause problems for OSI, particularly since different companies may have different attribution notices and may use different “base” licenses (all recent attribution agreements are based on the MPL).. Socialtext would like to suggest that OSI consider an “attribution” provision which can be used for any “modifiable” license.
Generic Attribution Provision
Redistributions of the original code in binary form or source code form, must ensure that each time the resulting executable program, a display of the same size as found in the original code released by the original licensor (e.g., splash screen or banner text) of the original licensor's attribution information, which includes:
(a) Company Name
(b) Logo (if any) and
(c) URL
POSITION STATEMENT
1. Consistent with OSD. Attribution is merely a form of notice which is consistent with Section 4, the Integrity of the Author’s Source Code, of the Open Source Definition. Virtually every OSI approved license requires the inclusion of copyright and other legal notices (and frequently more elaborate information, see below). The attribution requirement is similar to this notice requirement.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.
Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
2. Already Approved. OSI has approved several licenses which include attribution, Attribution Assurance License, Open Source License and the Adaptive Public License, as consistent with the Open Source Definition.
2. Redistributions of the Code in binary form must be accompanied by this GPG-signed text in any documentation and, each time the resulting executable program or a program dependent thereon is launched, a prominent display (e.g., splash screen or banner text) of the Author's attribution information, which includes:
(a) Name ("AUTHOR"),
(b) Professional identification ("PROFESSIONAL IDENTIFICATION"), and
(c) URL ("URL").
Section 3.10:
(a) As a modest attribution to the Initial Contributor, in the hope that its promotional value may help justify the time, money and effort invested in writing the Initial Work, the Initial Contributor may include in Part 2 of the Supplement File a requirement that each time an executable program resulting from the Initial Work or any Subsequent Work, or a program dependent thereon, is launched or run, a prominent display of the Initial Contributor's attribution information must occur (the "ATTRIBUTION INFORMATION"). The Attribution Information must be included at the beginning of each Source Code file. For greater certainty, the Initial Contributor may specify in the Supplement File that the above attribution requirement only applies to an executable program resulting from the Initial Work or any Subsequent Work, but not a program dependent thereon. The intent is to provide for reasonably modest attribution, therefore the Initial Contributor may not require Recipients to display, at any time, more than the following Attribution Information: (a) a copyright notice including the name of the Initial Contributor; (b) a word or one phrase (not exceeding 10 words); (c) one digital image or graphic provided with the Initial Work; and (d) a URL (collectively, the "ATTRIBUTION LIMITS").
(b) If no Supplement File exists, or no Attribution Information is set out in Part 2 of the Supplement File, then there are no requirements for Recipients to display any Attribution Information of the Initial Contributor.
Section 3.11: For greater certainty, any description or attribution provisions contained within a Supplement File may only be used to specify the nature of the description or attribution requirements, as the case may be. Any provision in a Supplement File that otherwise purports to modify, vary, nullify or amend any right, obligation or representation contained herein shall be deemed void to that extent, and shall be of no force or effect.
Section 6 Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work