Leading items

Open-source badgeware

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

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:

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:

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:

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.

Comments (5 posted)

Thunderbird to form its own organization

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

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

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 "start-up" funding 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 Firefox schedule.

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)

A turning point for open gadgets?

The Economist recently ran an article on avoiding international roaming rates associated with 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:

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 them open.

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 its owner.

[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 sometime soon.]

Comments (26 posted)

Page editor: Jonathan Corbet
Next page: Security>>