"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
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,
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
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
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.
to post comments)