Are SugarCRM, Socialtext, Zimbra, Scalix and others abusing the term "open source?"

Are SugarCRM, Socialtext, Zimbra, Scalix and others abusing the term "open source?"

Summary: 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.

TOPICS: Open Source

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 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

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 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, 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.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • More murky water

    Since we are on a roll criticizing the abuse of the term "open source", lets consider the case organization open sourcing only part of their software stack, holding back parts in the hope that people will migrate to their proprietary version.

    This is of course well documented in the case of SugerCRM. Other lesser example is OpenGroupware (withholding Outlook Support).

    My view is these are merely sophisticated "adware" +"crippleware" hybrid.

    Most importantly, to me, these violates the spirit of "open source".

    However, we should not be too critical. A lot of people benefits from these products. And if we throw the net extremely widely, one can fault IBM for only throwing out basic Rational stuff in the form of Eclipse in the hope that people buy Rational later.
    • On the point of not being too critical

      I agree. one question that is sure to arise in the minds of many is whether the efficacy of the act of open sourcing some software outweighs any downsides to what exactly got open sourced (eg: just a part of the software) or under what licensed.

      I completely understand the reasons for wanting the "badgeware" provisos in these licenses. In fact, in an effort to credit the developers, if it were me personally, I'd be more than happy to respect those wishes if I was hosting their software (wishes=posting logos and copyright notices). I have a great deal of respect for how these entrepreneurs have taken the open source route to their startups and while trying to mitigate the risks to their viability. On the one hand, they're giving their software away. And they're not preventing a big company like Google or Yahoo from using their own software againt them. So, it doesn't seem like too much to ask to get some credit for their efficacy.

      On the other, there are many people within the open source community who are not so deeply in touch with the legal machinations of open source software. So, I also understand the need for their to be some sort of authenticity when the phrase "open source" gets used.

      The actions of SugarCRM, Socialtext, Scalix and Zimbra may be quite noble. You may see them as not pushing the envelope so hard that it breaks open source. But somewhere, someone else is going to come along and add their own Exhibit B that steps much further over the line. And they're going to say, "If those guys can do it, why can't I?" Also, why, for example, should other applicants (like when Sun got the CDDL approved) even bother?

      So, this is a really hard problem to solve. I'm not about to get prescriptive about the solution. There are those in the open source community who I'm sure would bristle at the idea that someone like me would be even be willing to put the copyright notices and logos on their site. Sort of a "give an inch, take a mile" thing. But then again, Perens did tell me that if the language was softened to make the attributions optional, that he'd be OK with that.

      • No need to worry about Google/Yahoo

        If I'm running a commercial open source company that hopes to make money from advanced features and professional services (support, training), I'm not at all worried that Yahoo, Google, or some other large company is going to take my source code and offer it up against me. Those companies have hundreds of highly skilled engineers who could build a comparable and competitive product without access to my source code. They also have valuable equity that they could use to acquire my company and offer it to their users, as happened with Writely, among others.

        My worry is that some other startup will come along and create a new business using my software as a starting point. Under the OSI licenses, there is nothing to stop that new company from forking my project and taking it as their own. In fact, they wouldn't have to do any development at all, and could just take successive releases of my software as new releases of theirs. If they are on some other continent and market in a different geography or market segment, they could go for quite a long time before I would ever hear of them. Even in the US market, a well-funded startup could gain considerable market share selling services on the same software. Would such an ill-intentioned company comply with a "badgeware" requirement? Not likely, but it's another reason why the commercial open source vendors have introduced this feature to their licenses.
        • what ill intentions?

          How can using software licensed as open source as the foundation for a product/service offering be "ill intentioned"?

          If all that code is so important, why is an open source license of any kind being used? Imminently self-defeating. Open source isn't for showcasing coding prowess, it is a set of rules for the use of the code.

          And if it's because other open source code was used as a foundation, then aren't you just doing the same thing you bemoan?

          Badgeware will just be another way for lawyers to make money by hounding site owners for licensing info when their "customer" gets a whiff of some obscure method on some transaction screen. Another $250.00 an hour cottage industry.
  • Stallman

    Welcome to Richard Stallman's distinction between "open source" and "free software" ([i]software libre[/i]).

    I won't take a position on the rights and wrongs of the matter, but the historical fact is that the OSI wanted to define a development methodology without the FSF's ideological freight. They got what they wanted, and this particular situation is a direct consequence.

    The licensed software in question [b]is[/b] "open source," in the literal sense that you can see the source code. It's not even "source under glass," which puts it ahead of the look-but-don't-touch licenses (naming no names.) If there are limits on what changes can be made to it, well, isn't that the main difference between "open source" and "free software" -- that the licensor can attach strings?
    Yagotta B. Kidding
    • Fair points but regarding strings attached..

      On the point of attaching strings, I see a spectrum. Free Software is on one end. Moving away from that end are open source licenses with whatever strings attached there are. Sooner or later though, enough strings turn up that you cross over some boundary, out of open source territory. The question is where that boundary exists and should it be moved.

      You can read a lot into the motivations of the authors of certain non-GPL (non-free) open source licenses when you isolate the so-called strings. I'm sure there were plenty of situations where totally free was simply not a choice. What do you do then? Say, OK, forget it. We're not going to bother open sourcing this at all?

      So, we have 58 open source licenses. And now, maybe just like where totally free wasn't a choice back then, perhaps totally non-attributed in the user interface is the new non-choice.

      Again, outside of what I think Mark Radcliffe needs to do, I don't want to get too prescriptive about the long term reconciliation of the delta between the two positions.

      All I know is that hindsight is 20/20. Looking back is not going to help matters much. The question is, how do we move forward in a way that is as fair and equitable to all those involved and how do we continue to motivate others to engage in the sort of efficacy that Socialtext, SugarCRM, Scalix, and Zimbra have sworn themselves to.

      • Creative Commons

        [i]All I know is that hindsight is 20/20. Looking back is not going to help matters much. The question is, how do we move forward in a way that is as fair and equitable to all those involved and how do we continue to motivate others to engage in the sort of efficacy that Socialtext, SugarCRM, Scalix, and Zimbra have sworn themselves to.[/i]

        Hmmm -- perhaps what you're looking for is a taxonomy similar to what Creative Commons has done by putting a number of variants under a common license with options.

        I suppose that it would make sense for the OSI to build up a license taxonomy. Where possible it is clearly better that some of the variants move to common licenses (as, to their credit, Sun seems to be doing.)
        Yagotta B. Kidding
    • Implementation, not basic philosophy at fault

      It would appear that it is not their basic philosophy (making source available without FSF's Software Communism strings) that is the problem, but their implementation: they did not take the right measures to protect it = Trademarks.

      Now there might have been a philosophical objection to such action, and if so, that is a problem, bacause it clearly failed (by mere fact of a couple of minor players making a minor variation and it's under threat = not very stable).
  • A step in the right direction... to require that all OSI approved licenses carry a notice to the effect that they are, in fact, approved. Turn it into a badge of honor and promote it [i]a la[/i] "Intel Inside" or "Designed for Windows".

    You can't police all the rogues out there, but you can police yourselves.
  • classifications of open source

    I like the "OSI Approved" idea. But the problem with these licenses appears to be that there really are a dozen different "classes" of Open Source, yet the OSI only has one definition. Perhaps they should break that down into several classes of Open Source where:

    Class I is Stallmans Free Software
    Class II is the currant OSI definition
    Class III is Badgeware
    Class IV is partially Open Source (nVidia's video drivers)
    Class V is "look but don't touch"

    and so on. I have never been happy with the one or the other idea of open source. Being a user of both Open Source and proprietary software, I do understand the need for both. However, various organizations seem to be pushing to one extreme or the other. We need someone to step into the middle and tie them all together. The OSI is in the perfect position to accomplish just that. Well, thats my 2 cents anyway.

  • OpenSource

    I've always thought of open source as where you could see the source code. The license really doesn't matter for the definition just matter with what you can do with the source code you see.
    • Not quite

      There is also that class of source availability that's "look but don't touch". It lives in a glass box that doesn't have to be "open" for you to "see" it. (hopefully that analogy helps)

      The "open" label implies that you can actually get at it and work with it.
  • RTFlicense

    Before you use any software, RTFlicense. Even if you're using "approved" open source licenses you still have to pay attention to them. The dubious idea that some organization should be able to "approve" free/open/redistributable/royalty-free/whatever-you-call-it-this-week software licenses is a big part of the problem... it creates the illusion that so long as you use or apply an "open source" license you're done with the whole licensing thing.


    I've run across companies violating the GPL, the original BSDL, even the modified BSDL, all quite innocently... they just took the code and used it. I've run into people using licenses with clauses they never intended to enforce because they didn't read them... or discovering that someone doing something they don't like with their software is perfectly in their rights.

    Then you have people creating new licenses because they mistakenly think one of the licenses they use has requirements they don't like.

    RTFlicense, and decide whether to use the software (or the license) because of what it actually says... not because it's "approved".
    • It's not that easy

      Actually, have an organization like the OSI serves a very good purpose. For example, it allows patent holders gifting their patents to the FOSS community to not have to worry about the definition of open source in their pledges. They can simply say that they're making a non-assertion pledge to any FOSS developers and that developers working under an OSI approved license is the acid test.

      Without such a body, just about anybody could call their code "open source" and get away with it. For every piece of software out there, there would be this huge debate over whether it is or isn't open source and as a result, most people would become distrustful of the phrase whenever they see it.

      I understand your position... well, good. If you take away their security blanket, it will force them to do what they should be doing in the first place: read the license.

      But the truth is that we live in a culture that looks for such certifications.

      Do you study the engineering data on the bumpers of a car your about to buy to make sure it lives up to some standard? Or do you place faith in a process that's governed by the Department of Transportation.

      I'm not saying that people shouldn't read the license. But having the OSI, or an organization like it, is worthwhile.

      • I agree, and add another reason

        Another reason it's useful to certify stuff like this: They can put the standards in terms the average Joe can understand. Then they have a good idea of what generally is and isn't allowed, even though the speifics may vary for different licenses.

        Creative Commons does this also, they offer explanations for the licenses that aybody can understand.

        One of the biggest reasons that people don't read licenses is because the licenses are written in legaleze that only lawyers can understand, and that many licenses are lengthly as well. Who wants to read a long, dry document that is very difficult to understand? Very few people I know of do, even I will often not read the whole thing, and just let EULAlyzer to warn if something may have spyware. Really, EULAs are just a pain.
  • "Open Source" - not a good term.

    I don't know about you, but the very first time I heard a person use the term "open source", I didn't associate it with "free". I thought more along the lines of "open house", and I *still* think that's how "open source" *should* be defined.

    To take the "open house" metaphor further, what's the normal house? Why, a "closed house" of course. For a normal house, there may be a window here and there where you might be able to see into, but for the most part you can't see into the house, nor are you permitted to.

    So until the GNU/freeware movement, what was the case for most (but not all) vendor software you purchased? Why, "closed source" of course! Sure, you may have been provided a few APIs as "windows" into the source, but otherwise it was closed to you.

    So, when someone gives you an "open house" invitation, does that mean you're free to cart off the house, or even anything in the house? No. It means you can come in, look around to your hearts content, maybe fiddle with things a bit, but that's about it.

    So along the same lines, what would one expect from "open source"? While it's true that a direct comparison would be the vendor provides you a copy of the code only to look at, that's clearly pretty useless to just about anyone, so that wouldn't make must sense. So what's the next level of "openness" that would make sense? Well, letting you make your own personal changes into the code and compiling the result for your own usage. And perhaps sharing your CHANGES (not the vendor's code) with others. To me, there seems no reason to bundle the "and you may give our product's code to anyone you want" clause in the simple term "open source".

    I think a better term for what terms "open source" would be "community source".
    • And is this substantially different than MS' "shared source"?

      Shades of gray often lead to complexity and confusion. But sometimes, they allow for certain boundaries to be drawn that might not otherwise be drawn.

  • much ado about NADA

    wow u sure do have your pants in a wad about nada.
    so what if sugarcrm has links that point back to their web site. the source code is open and freely modifiable and distributable by anybody to anyone. At no cost. I really don't care if they want a little credit for bringing an awesome product to the marketplace. And is the place where it all happens and contains many additional plugins that are also free and open source. I really don't understand your point. You have fretted over this for weeks?!?!?
    Sloan Miller
    • You've misunderstood

      I didn't say I have a problem with the requirements of Sugar, Socialtext, Zimbra, and Scalix. In fact, in another comment, I personally would be willing to make that "trade" (although the it would be simply out of respect to them, and not their definition of open source or anything like that).

      The key issue here is that there's a collection of software products out there being billed as open source when the licenses under which they're made available are not OSI approved licenses.

      I am not espousing either of the views that make the situation what it is, or taking sides. But the situation is problematic because it could dilute the value of the phrase "open source" as well as make the OSI completely irrelevant should more companies follow suit.

      After all, if there's one single most important thing that the open source community looks to the OSI for, what is that? If it can't do that one thing well, then why bother doing it all?

    • Mising the Point

      I think you're missing the point of the slippery slope--at some point, someone is going to push the envelope and require something that's not in the spirit or the definition of open source.