Open-source badgeware

By Jonathan Corbet
July 31, 2007

"Badgeware" refers to a class of software with licenses requiring that some sort of attribution of its origin be displayed in all copies. An example which has seen much discussion over the last year is SugarCRM, whose license required that every screen carry a 106x23 "Powered by SugarCRM" logo and a copyright notice. This decoration was required for any program derived from the SugarCRM code, even if it was far removed from SugarCRM in its actual functionality. SugarCRM's pushing of this license and describing it as "open source" caused a lot of fuss; many in the community were glad when SugarCRM recently announced that it was dropping its badgeware license in favor of GPLv3.

Badgeware licenses are seen widely (though not universally) as not being free. "Free," for the purposes of a discussion like this, means compliant with the Open Source Definition. It is said that badgeware provisions interfere with clause 3, which requires that it be possible to create derived works. Since the attribution functionality cannot be removed, certain kinds of modifications are prohibited by attribution requirements. Provision 6 says that there cannot be any discrimination against any particular field of endeavor; badgeware requirements can prevent code from running in a mode where there is no graphical interface, or where the display is so small (on a phone handset, for example) that the requisite attribution would take up most of the useful space. And term 10 requires that the license be technology-neutral, which is hard to achieve if the license is requiring that attribution be displayed in specific ways.

Even so, attribution requirements are not unknown in free software licenses. The OSI-approved Adaptive Public License (APL) has such a requirement. Version 2 of the General Public License puts this requirement on derived works:

If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

Early versions of the BSD license also carried the infamous advertising clause. So attribution requirements are not exactly a new thing. The debate on those licenses has certainly not ended; a number of companies have taken the liberty of calling their badgeware licenses "open source" despite the lack of any certification from the Open Source Initiative. In most cases, that certification has not even been requested, perhaps because the companies involved fear that the answer would not be to their liking.

An exception has been Socialtext, which submitted its Common Public Attribution License for OSI approval (after several previous rounds) in June. There was a long, inconclusive discussion. The OSI's license committee considered the license in July, but was unable to provide a recommendation. Committee chair Russ Nelson personally recommended approval, though, saying:

The APL was not a widely used license, I suspect because of its complexity. Let's give attribution requirements another chance in a simpler license. If such a licensed software does not achieve the Open Source effect, it will put the issue to rest.

Shortly thereafter, the OSI board took his advice and approved the CPAL as an open-source license.

The CPAL (in its final form) is based strongly on the Mozilla Public License, but it adds two terms to the end. One, of course, is the attribution requirement:

...the Original Developer may include in Exhibit B ("Attribution Information") a requirement that each time an Executable and Source Code or a Larger Work is launched or initially run (which includes initiating a session), a prominent display of the Original Developer's Attribution Information (as defined below) must occur on the graphic user interface employed by the end user to access such Covered Code (which may include display on a splash screen), if any. The size of the graphic image should be consistent with the size of the other elements of the Attribution Information. If the access by the end user to the Executable and Source Code does not create a graphic user interface for access to the Covered Code, this obligation shall not apply.

There are some limits on the attribution information - the phrase cannot exceed ten words, for example. The attribution need only be displayed at startup time, and not on every screen as some other licenses have required. If there is no graphical interface, there is no requirement to display the attribution information. So it would seem that this is about as gentle as attribution requirements can be expected to be - and it is no worse than was already approved in the APL.

One interesting term appears to have not drawn much scrutiny:

You acknowledge that all trademarks, service marks and/or trade names contained within the Attribution Information distributed with the Covered Code are the exclusive property of their owners and may only be used with the permission of their owners, or under circumstances otherwise permitted by law or as expressly set out in this License.

Nothing in the license grants any sort of permission to use any trademarks which might be contained in the required attribution information. Since display of the attribution information is required, a denial of the right to use the trademark could potentially shut down any right to use the software at all. So anybody who is considering building on a CPAL-licensed program would be well advised to carefully study the trademark policies which apply to the attribution information.

The CPAL also contains a Affero-style requirement that the source be made available to anybody who uses the software. So anybody who builds a web site based on CPAL-licensed code must be prepared to distribute their source even if they are not distributing the software in any other form.

The reaction to this approval has not been universally positive. There are many in our community who do not want to see badgeware legitimized as "open source"; they see the CPAL as being a nose in the tent door with a very large camel behind it. On the other hand, Socialtext has done its best to play by the rules and has spent many months trying to craft attribution terms which meet the community's standards. The real test, now, will be to see whether others use this license or build upon CPAL-licensed software. If that does not happen, the CPAL will have little effect regardless of what the OSI thinks of it.

Open-source badgeware

Posted Aug 2, 2007 3:36 UTC (Thu) by dberkholz (guest, #23346) [Link] (1 responses)

I'm pretty sure that "hole" of refusing to let them use the trademark isn't valid. I would guess that courts would read the license as an implicit grant of permission to use the trademark.

"Affero-style" open-source badgeware ?

Posted Aug 2, 2007 6:25 UTC (Thu) by khim (subscriber, #9252) [Link]

"Affero-style requirement" is very bad in this context. Especially for interpreted languages. "Big boys" will just refuse to use such licenses unless really pressed and for "single hacker" site it's not a good choice too - because it's often not easy to separate pieces of code installed on server (typical server will include code from different projects plus local modifications). Who's left ? Hardcore freedom lovers ? They will reject license because of the attribution clause...

Open-source badgeware

Posted Aug 2, 2007 15:33 UTC (Thu) by vmole (guest, #111) [Link] (2 responses)

...and may only be used with the permission of their owners, or under circumstances otherwise permitted by law or as expressly set out in this License.

Doesn't that explicitly allow use of the trademark in the attribution, since the attribution requirement is expressly set out in the license?

Open-source badgeware

Posted Aug 2, 2007 19:48 UTC (Thu) by dmarti (subscriber, #11625) [Link] (1 responses)

Not necessarily. The trademark holder could have a policy that, for example, forbids use of its trademark on porn sites, or sites that link to circumvention devices. In that case, the user could get the right to use the trademark and the software by simply taking down the porn or links.

<p>If using a trademark is required to use the software, then the trademark license effectively becomes part of the software license.

Open-source badgeware

Posted Aug 4, 2007 0:00 UTC (Sat) by giraffedata (guest, #1954) [Link]

I don't see how the trademark owner's policy has anything to do with it; it's what the owner actually licenses, not what it's his policy to license that matters.

But you have to go rather beyond the literal meaning of that paragraph to say it's a trademark license. The paragraph starts out "you acknowledge," which is not language that grants anything at all. It's language that takes away -- it takes away the licensee's right to argue "I thought I was getting a trademark license". The latter part of the paragraph limits the amount that the paragraph takes away, but can't semantically add anything that wasn't already there in other paragraphs.

So maybe the attribution requirement is a trademark license, and maybe the copyright license implies a trademark license because the former is useless without the latter (I personally doubt both of these), but the paragraph in question doesn't grant any trademark rights.