SugarCRM: Artificial Sweetener?

I got the following e-mail a few days back:

Dear Summit 2006 Delegates and other List Members,

I am writing for two purposes:

1. First, I’d like to share the URL of an insightful discussion of attribution, OSI, and licensing at http://blogs.zdnet.com/BTL/?p=4013&page=1. This one is worth a read to see some of what is going on the commercial space as well regarding OSI. I found it informative without having to subscribe the OSI Licensing list.

2. You will soon see a revised set of documents that reflect the outcomes of the Summit discussion for next step. This set will include both the inbound Contributor Agreements and outbound distribution license. Chris Coppola (rSmart) continues to be our hero in slugging through many of the details of these processes across the foundations and with OSI.

I will also be providing an update on the Policy and Licensing Summit at next Monday’s CNI meeting in Washington, DC. Again, I appreciate all those who traveled to attend the Summit and who have contributed via the online discussions. The quietness on this list of recent has only indicated much work across other projects, but we will soon distribute for comment the documents derived from the work of the Summit.

Cheers – Brad

IU Chief Information Officer & IU-Bloomington Dean of IT

Brad is the CIO of the University of Indiana, and co-chair of the conference in Indianapolis in mid-October that was the subject of a recent post.

Many of the folks who were at that conference will also be at the weeklong Sakai 2006 Conference that begins this Tuesday in Atlanta. (I’ll be there and am really looking forward to learning more about Sakai.)

The subject of this post is Brad’s mention of an “insightful discussion,” Are SugarCRM, Socialtext, Zimbra, Scalix and others abusing the term “open source?”, by David Berlind. I have been aware of this issue, and also noticed a link to it on Steve O’Grady’s 11/23/06 links. There is a follow-up post, Attribution may matter (in open source licensing), but making the Open Source Initiative whole matters first.

Berlind’s analysis of the issues raised by the SugarCRM license is balanced and nuanced, and I strongly recommend that those interested in open-source licensing issues take the time to carefully read his post.

In brief, the issue is that the company SugarCRM.com has a product called “SugarCRM,” and the company claims that their product is open-source because the code is licensed under combination of the OSI-approved license, Mozilla Public License 1.1 (MPL), and the following exception, that can be found in “Exhibit B”:

SugarCRM Public License 1.1.3 – Exhibit B

Additional Terms applicable to the SugarCRM Public License.

I. Effect.
These additional terms described in this SugarCRM Public License – Additional Terms shall apply to the Covered Code under this License.

II. SugarCRM and logo.
This License does not grant any rights to use the trademarks “SugarCRM” and the “SugarCRM” logos even if such marks are included in the Original Code or Modifications.

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

And you thought open-source was simple? Here we have a license that includes the phrase “106 x 23 pixels.” Are we in a pixel pickle?

The are many questions raised by Exhibit B. Perhaps that most important is whether the Exhibit is an “exception” or a “restriction.” My understanding is that, at least in the view of some people, adding an exception to an open-source license is acceptable since it doesn’t restrict the use of code under the license, while a “restriction” is not acceptable because the modified license restricts the user’s rights.

And of almost equal importance is whether the decision as to which applies can be left up to the authors of the change, or must be reviewed and approved by an independent body such as the Open Source Initiative (OSI).

When I first looked at this issue, I felt the changes were not acceptable, for several reasons.

First, the change is a restriction. It requires the user to do things that the MPL 1.1 does not require.

Second, the change had not been submitted to the OSI for their review and approval.

Third, as a corollary to the second, for SugarCRM.com to use the phrase “open-source” without the consent of OSI was to take unfair advantage of OSI as the maintainer of the notion of “open-source” and “open-source license.” Giving credit where credit is due is fundamental to the ethics of open-source, and to associate your work with the work of others in inappropriate fashion is to take unfair advantage of them.

And so I began a series of posts to address this issue. I though it would be a simple matter to confirm my first impression, but several posts down the road I’m not so sure.

Though some have already taken me to task for making such a mountain out of what is in their view a molehill — as a recent comment attests — I find that on examination this situation, as is so often the case when dealing with open-source, is more subtled and nuanced than a first impression would suggest.

All these concerns equally apply to SugarCRM.com’s new language? Is is an acceptable exception? Something needing OSI review? Not needing OSI review?

Who is to decide? Certainly not me. All I can do is raise some of the points that perhaps should be considered by others who have the responsibility of sorting this out.

The TWIT license: An exceptional license

In a previous post I discussed the TWIT license, which differs from the “approved open-source” MIT license only by changing the sentence:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

to

The above copyright notice shall be included in all copies or substantial portions of the Software.

I said that while I could argue that the changes were such that the TWIT license was “open-source” as the term is commonly used, I could not say that TWIT was an “approved open-source” license unless I submitted it to OSI for their review and got their approval.

However, by reading recent news reports, I have learned of an exceptional technique that lets me say TWIT is open-source without having ever to go near the OSI folks. Why should they be bothered to review something that I know is patently obvious?

This technique is so exceptional in its power that it takes its name from that power — licensing by exception.

Here is how it works. I just say

The TWIT license is not a new license. It is just the fully-approved open-source MIT license with an added exception — you don’t have to copy the permissions, just the copyright notice.

All done! Wasn’t that easy? I have made an exception to recognize Nancy’s exceptional needs. Good work, Dave. Got the job done with no change in the license and no trouble to the OSI.

This is such a clever technique that I doubt I could have figured it out by myself. But at least it’s no longer a secret, especially since it’s been used twice.

Those who have followed the news of the recent Sun / FSF alliance may have noted that the alliance announced that Java was being “open-sourced”

Sun is now seeding open-source communities around its implementations of the Java platform. The company is releasing the code under an open-source license, and putting in place the infrastructure for a community to collaborate on a source-code commons.

…

The code is available today under the Common Development and Distribution License (CDDL); it will soon also be available under the GPL v2 license plus the ClassPath Exception.

There you go. gplv2 didn’t meet the needs of the alliance, so they had to create an exception to get the job done — a “ClassPath” exception, whatever that means, though perhaps it has to do with unusual licensing issues raised by Java’s exception handler. [1]

Or perhaps I got it wrong. I’m hoping that the OSI reviewed the license to be used for the code to be released by the Sun / FSF alliance, in which case can someone please tell me the approval date of OSI’s announcement?

Notes.

1. I know it doesn’t, but all bets are off when you see an opportunity to have fun with a pun.