OSI evacuation begins over 'badgeware' license
The few and the furious
OSCON It took no more than five minutes for a controversy to emerge once the Open Source Initiative (OSI) revealed that it had rushed a new attribution-style license through for approval.
The OSI yesterday confirmed that fluffy, Web 2.0 company Socialtext received the go ahead to use its Common Public Attribution License (CPAL) – or badgeware license – with the OSI's blessing. The license stands as significant since it mutes an ongoing battle over the controversial attribution licenses used by the likes of SugarCRM and Centric CRM, which had yet to meet the OSI's "open source" standards. Now, software makers have the all-clear to adapt Socialtext's license to cover their own wares and can go on displaying logos all over the place.
The debate over CPAL – or at least variants of it – has raged for about nine months via a discussion group led by the OSI. Some members of that group and other OSI observers were miffed to discover that, despite these lengthy proceedings, a modified version of CPAL was shoved through by the OSI board early Wednesday morning. Why would the OSI approve a controversial license with last minute language add-ons before running the changes by the community?
As of this writing, the OSI had failed to display the new CPAL license, although you can find a draft version of it here. As it turns out, The Register has seen the final version of the license and was only able to notice a one-sentence addition, along with a one word switch in an existing sentence. The new sentence is "The size of the graphics image should be consistent with the size of other elements of the attribution information" and was placed in part of the attribution clause in the license.
OSI followers, however, remain upset that they did not get to see this change – no matter how minor.
"(This) was quietly done in a closed 'open source' meeting and we have nothing on how such a decision got around the issues pointed out with various drafts," developer Andrew Oliver, complained to an OSI mailing list. "I'm growing unconcerned with what the OSI thinks is open source anymore."
Oliver subsequently unsubscribed from the OSI mailing list.
Other people here at OSCON, who requested anonymity, voiced concerns over the OSI's behavior.
OSI president Michael Tiemann, however, defends the organization's decision.
"Usually, we don't catch those tufts of hair at the very end," he told us. "Usually, they are caught before.
"But given how long it had taken and how much the board had done and still has to do, we felt in that particular case it would be best to do what we were asked to do."
The OSI board felt that its decision to approve the license remained in keeping with the major issues raised by developers in the previous months. And, in fact, the last minute changes to CPAL are minor and uncontroversial.
One major objection to attribution licenses has been the issue of a "persistent display" where a logo would forever mar an application.
"The new version provides enough different ways to avoid that, including a way of eliminating the logo altogether," Tiemann said.
Customers who use a non-GUI version of a CPAL-governed application need not display attribution at all. In addition, companies can opt not to display a logo.
Those who do display a logo must cause it to vanish after a reasonable amount of time has passed. An attribution phrase must also contain at most ten words.
Overall, Tiemann sees the OSI's approval of CPAL as a great success.
"A year ago . . . the entire community lined up on one side of the boat (against the badgeware), and when the new thing (CPAL) came out most people wound up on the other side of the boat with one person on the far rail and some others who would like to see some changes," he said.
"There's been a great diversity of opinion, but ultimately the tribe has spoken."
Beyond the last minute approval, some open source advocates have objected that the badgeware license still places too many restrictions on the free use of code. For example, what if you only use a portion of a vendor's code? Should you still need to give them full credit via a logo?
Much of this debate will seem moot to us if logos fail to appear all over the place as some expect. Perhaps people will behave themselves and be limited with their badgeware assaults.
In the meantime, we'll keep track of the OSI furor and see if it swells beyond a few, disgruntled voices. ®
Sponsored: DevOps and continuous delivery