"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,
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.
Comments (5 posted)
A blog posting by Mitchell Baker, chief lizard wrangler and CEO at Mozilla
Corp., set off a firestorm of reaction, as it suggested that it might be best
for Thunderbird to split off from Mozilla. The reaction was probably much
stronger and louder than Baker expected, so she has followed up with a
number of additional posts, clarifying her statements. Though it is rather
counter-intuitive, it may actually be for the best, the main developers are
backing the plan. It could lead to bigger and better things for the
Baker posted her thoughts last week, which were picked up by various online
news sources and the controversy began. Various conspiracy theories,
typically involving Google, were promulgated. The ultimate mission of both
Mozilla Foundation (MF) and Mozilla Corp. (MC) were debated, those organizations alternately ridiculed, reviled
and defended. In short, it was a typical internet flamefest, with far more
heat than light. Baker's original posting was lacking in many of the
details that she filled in later, making it far easier for commenters
to provide their own explanations. The picture that is emerging actually
seems quite positive for Thunderbird development.
Essentially, Baker, other Mozilla Foundation board members and the
lead developers all recognized that Thunderbird was not getting the
attention it deserved - it is overshadowed by Firefox, its higher profile
sibling. The MF has been focused on Firefox from the outset and
created Mozilla Corp. as the for-profit entity to handle the revenue
from the Firefox deal with Google. The vast majority of MC employees
are working on Firefox which is not likely to change. The two Mozilla
entities want to focus their energy on Firefox - Thunderbird was
suffering because of it.
Thunderbird has never attracted the following that Firefox has. In terms
of users, developers and community members, Thunderbird is probably two
orders of magnitude smaller than Firefox. Increasing the size of the
Thunderbird community is at least part of what Baker is trying to do. Her
original post is titled Email Call to Action and contains some
thoughts about coming up with a wider email vision that have mostly been drowned out in
the Thunderbird governance debate.
Baker outlined three possible scenarios for how to move Thunderbird out
from under the current structure and asked for suggestions on others. The
first and second options are similar in that they create a new foundation
for Thunderbird, either as a subsidiary of MF or as a full-fledged company
of its own. Both are considered to have a fairly high overhead,
organizationally, and creating a subsidiary foundation still does not
really address the problem, as MF will still be dealing with
Thunderbird issues. The third option is to spin off the
developers into a small, independent, for-profit services and consulting
company, while turning Thunderbird into a Mozilla community project, like SeaMonkey. Another,
potentially viable, option has emerged from the comments: Thunderbird could
move to another organization, the Apache Foundation is often mentioned,
where it would be on a more equal footing with that organization's other
Based on the thoughts
posted by Thunderbird lead developer, Scott MacGregor, it would appear that
the independent company option is emerging as the lead contender. It has
the advantage of being the simplest to set up and get going, with
being the major question. Based on Baker's posts, it would seem likely
that MC would help with funding, at least for a bit, but a revenue model of
some kind would have to come along relatively soon.
With Thunderbird as a community project, very little would change from an
external view. The development would stay on the Mozilla servers, the
source code repositories and bug tracking systems would not move. The main
difference would be that Thunderbird Corp. (or whatever it ends up being
called) would be responsible for making releases of the code, much like the
community handles SeaMonkey releases today. This would presumably allow
Thunderbird to be released on its own schedule, without any link to the
A Thunderbird Corp. may very well struggle for revenue. MC has been so
successful because of their agreement with Google, making it the default
Firefox search engine and homepage. This has brought in tens of millions
of dollars in revenue, but it is hard to see how Thunderbird could
capitalize on a similar deal. Thunderbird is, at some level, in direct
competition with Google's Gmail service, which is what led some to believe
Google was behind the "ouster" of Thunderbird from Mozilla. Baker has clearly
stated that Google was completely uninvolved in the Thunderbird
discussion, but there are still some who believe otherwise.
Many vocal commenters on the various postings and stories are looking at
this as a hostile act by Mozilla. It appears, however, that this is truly an
attempt to recognize that things are not working and to try and find a
solution that will work. According to Baker, MacGregor and others, it
simply is not possible for two projects as disparate in size as Firefox and
Thunderbird to be handled within the same organization; the smaller always
gets the short end of the stick, a disproportionate short end. In order
for Thunderbird to thrive, it needs to find its own way.
It is hard to visualize Mozilla without Thunderbird or vice versa.
Thunderbird's adoption rate has definitely been helped by the association
with Mozilla (and Firefox). While they may officially be splitting up,
that may not affect very much in the minds of the public. SeaMonkey is
still associated with Mozilla, though it is run as a community project.
Thunderbird will still share lots of code with Firefox - the community
affiliation probably will not affect much, Thunderbird and Firefox are
likely inextricably linked.
The bigger question is whether a new Thunderbird organization can
continue to deliver email client innovation that can attract more users and
a larger community. The Lightning
calendar is something that Thunderbird has needed for a long time. It is
often the "yes, but" that is heard when organizations are considering
dropping proprietary alternatives in favor of Thunderbird. There are
plenty of new and exciting features on the Thunderbird
roadmap, it is merely a matter of choosing wisely, getting them
implemented and released, while struggling to find a revenue model that
works. It is a tall order, but, with a lot of hard work and a bit of luck,
it is achievable.
Comments (2 posted)
The Economist recently ran an
article on avoiding international roaming rates
cellphone use while traveling. Your editor's recent schedule has made him
rather more than usually interested in that subject, so the article seemed
worth a read. It seems that there are not a whole lot of truly viable
solutions available at the moment; the recommended approach appears to be
to get an unlocked GSM phone and buy SIM cards locally - not something one
needs an Economist subscription to know about. Happily, the article
concludes that "relief" is at hand; it then expends several paragraphs on
just what form that relief will take:
Several months before Steve Jobs, Apple's media-savvy boss, gave
the world its first tantalising glimpse of the iPhone, something
remarkably similar in appearance (but wholly different within) was
shown to the Linux software community and other open-source
evangelists. OpenMoko, an initiative aimed at developing all the
technology for a mobile smart phone based on non-proprietary Linux
software, is everything the iPhone could have been but is not.
The article notes that the openness of the platform means that users will
be able to install applications without the approval (or knowledge) of
their cellular providers. Those applications can include voice over IP
tools which can work via a data connection through a local GSM provider,
thus shorting out the roaming and long distance charges. But there's a lot
more that can be done - things that no cellular provider ever dreamed of.
LWN readers will have often heard your editor's contention that truly open
gadgets must, sooner or later, take over the market. But that takeover has
been discouragingly slow in coming. Manufacturers prefer to keep their
products closed and under their control; other forces, including pressures
to support DRM schemes and regulatory issues, also come into play here.
So, while we have more gadgets to play with than ever before, most of those
gadgets cannot be hacked upon and extended to do interesting new things -
at least, not without a serious effort on the community's part to crack
Awareness of the problems associated with closed devices has grown far more
slowly than many of us would like. Most consumers, it seems, are
interested in devices that Just Work and have little interest in extending
them. So there is little pressure in the market for more open devices,
and, thus, little incentive for manufacturers to offer them.
The cellular industry may just be the place where this tide begins to
turn. In the U.S., at least, this industry works under an exploitive and
controlling model. Handsets are usually purchased through the provider,
are locked to that provider, and lack any features which said provider
worries could damage its revenue model. So even simple and obvious
functions, like copying pictures from the handset onto its owner's
computer, tend to be blocked. Voice over IP functionality which could be
used to evade roaming charges in distant countries is entirely out of the
question (though T-Mobile has just launched an interesting plan which
enables free calls from WiFi hotspots).
The cellular telephone has become an increasingly personal and
indispensable tool. It is picking up a number of interesting new
capabilities. Almost everybody has one in the richer parts of the world -
and, often, in the less-rich parts as well. Phones which carry arbitrary
restrictions designed to further somebody else's agenda will get the
attention of people who are not ordinarily tuned into software freedom
issues. That will be especially true when freer alternatives are out there
and their potential becomes clear.
So the OpenMoko phone may yet prove to be the revolutionary device that
some of its backers have promised. Unlike every other Linux-based cellular
phone produced so far, it will be an open system, free for anybody to
extend in any number of ways. If this phone lives up to its potential at
all, people will see what it can do and start asking why their shiny new
handset can't be extended in the same ways. They might just start
demanding a higher degree of openness from their vendors and/or providers.
If we are lucky, purveyors of closed devices will start finding it harder
to compete. Maybe, just maybe, the OpenMoko phone will succeed in teaching
people about the value of free devices and, as a result, help bring an end
to an era of hardware designed to serve the interests of people other than
[As to whether the OpenMoko will live up to its potential: LWN has ordered
one of their early development devices with the idea of writing an article
or two about it. Anybody who has been following that situation knows that
OpenMoko's fulfillment operation is currently not living up to much
of any potential. Stay tuned, hopefully we'll have a device to review
Comments (26 posted)
Page editor: Jonathan Corbet
Next page: Security>>