[License-review] The History of Badgeware Licensing & OSI
mccoy.smith at intel.com
Fri Jun 24 15:29:29 UTC 2016
This discussion has gone way off topic of the ZPL approval and probably deserves its own topic header.
This is a really good summary of the history of badgeware licensing (however you define it) and the OSI. Others might have a different perspective on that history, which I suspect many of us would interested in hearing as well.
For what it's worth, the Black Duck pie chart of "Top Open Source Licenses" (https://www.blackducksoftware.com/top-open-source-licenses) doesn't list CPAL at all amongst the top 20, meaning it has less than 1% usage (behind, of all things, the non-OSI approved "DO WHAT THE F*** YOU WANT TO PUBLIC LICENSE"). Of course, many have criticized Black Duck's methodology in creating those sorts of charts, but they do reflect one measure of "popularity" (terminology which also has its critics).
From: License-review [mailto:license-review-bounces at opensource.org] On Behalf Of Rick Moen
Sent: Friday, June 24, 2016 12:54 AM
To: license-review at opensource.org
Subject: Re: [License-review] Approval request for ZENTAO PUBLIC LICENSE
Quoting Richard Fontana (fontana at opensource.org):
> Possibly. One problem is that an earlier incarnation of the OSI
> approved a license that would probably have to be considered a badgeware license:
You would also want to cite its obscure predecessor, Adaptive Public License (APL). However, I dispute the notion that _either_ is a legitimate reason for more of the same, and will explain why.
> This license was drafted to address concerns that were raised in the
> OSI community regarding earlier badgeware licenses. Nonetheless I
> think it fits your definition of badgeware.
I remember the 2007 CPAL 1.0 discussion extremely well, and so can give my impressions (which of course don't speak for OSI, only for me): CPAL was a compromise badgeware licence deemed minimally noxious, drafted by Socialtext and OSI-approved after intensive lobbying of OSI by a tight-knit group of closely related badgeware firms, and IIRC by a then-Board member who had business connections with some of those firms.
(Those firms all seemed to be Open Source Business Conference regulars, and showed a remarkable tendency to tout each other to investors.)
The general run of badgeware licensing common at that time, e.g., SugarCRM's licence of the day -- seemingly the prototype for all the others -- that required that every user interface screen of any derivative work carry a 106x23 "Powered by SugarCRM" logo and a copyright notice. I was among those who pointed out that such badgeware licences were a powerful disincentive against competing commercial use, and thus, I asserted, in that sense violates OSD #6 (discrimination against persons or groups).
Moreover, such discouragement of third-party commercial use was actually an explicit _goal_ of SugarCRM, Inc.: In direct reaction to the then-recent forking of one of its earlier, MPL-covered code releases by commercial competitor vTiger CRM, SugarCRM, Inc. immediately, and with some public expression of anger and outrage at a competitor daring to fork and use its code in commerce, added to MPL its signature badgeware clause, requiring its big company logo, etc. on every user interface screen, thus launching the badgeware craze.
(Bruce Perens claimed I was 'confusing creation of derivative works with use, which are two separate rights under copyright law'. I rejoined that OSD#6 specifically _does_ concern use. In any event, although Perens disagreed with my analysis on that point, he added that 'The reason to reject [badgeware licensing] is that it complicates simple
The drumbeat of pressure on OSI carried the very strong implication that, if OSI did _not_ certify CPAL, badgeware firms would simply defy OSI's custodianship of open source branding and call what they were doing open source. So, we on license-discuss voiced grudging approval of CPAL as the least-bad badgeware -- only a single 'prominent display of the Original Developer's Attribution Information' without any dictation of minimal point size, as long as it is 'consistent with the size of the other elements of the Attribution Information', and not to exceed '(a) a copyright notice including the name of the Original Developer; (b) a word or one phrase (not exceeding 10 words); (c) one graphic image provided by the Original Developer; and (d) a URL (collectively, the "Attribution Limits")', and no requirement if the derivative work no longer included a suitable UI. Which was miles better than what SugarCRM and its fellow-travellers were requiring.
License Committee chair Russ Nelson said during the protracted license-discuss discussion:
The APL [Adaptive Public License] 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.
And, surprise! CPAL did not achieve that effect. Because nobody used it.
McCoy Smith wrote:
> Interesting. I'd forgotten about CPAL.
Precisely. Everyone did, because, having secured OSI Certified approval for their minimally-obnoxious licence, the badgeware firms quietly dropped it.
I do believe that many of them followed SugarCRM's next move, which I assert was considerably worse and further from open source, and also more deceptive -- twisting of GPLv3 and AGPLv3 licensing via inclusion of very intrusive badgeware clauses, the very same ones they previously bolted onto MPL, claiming them to be merely 'legal notices or author attributions'. About that, permit me to repeat what I said about that on license-discuss in 2014:
Quoting John Cowan (cowan at mercury.ccil.org):
> In the end, certification is just a convenience to the users: it says
> that a group of fairly knowledgeable people are willing to stand
> behind the claim that each certified license conforms to the OSD.
In my opinion, this is a particularly important function because of firms that publish deliberately deceptive licensing, such as sneaking extremely problematic and intrusive badgeware clauses, having the effect of greatly deterring all third-party commercial reuse, into what is publicly claimed to be [A]GPL v3 licensing using the 'legal notices or author attributions' incorporate-by-reference feature in section 7 of [A]GPL v3.
SugarCRM, one of the main drivers of the badgeware model - back in the days when OSI was being arm-twisted by that gang of OSBC regulars in the advocacy effort that resulted in certification of dead-on-arrival minimal badgeware licence CPAL - appear to have pioneered this style of Section 7 hokery: The sponsoring firm behind a Web 2.0 hosted application claim in all the public marketing materials that the software is open source under GPLv3 or APGLv3, disclosing _only_ in obscure, not-easily-noticed places that they actually mean GPLv3 or
APGLv3 with additional restrictions encumbering commercial third-party reuse.
Admittedly, OSI's licence-certification program doesn't do much to stop this sort of chicanery, but at least OSI make clear that their certification program certifies specific licence texts and not also Everyone's Vaguely Similar Imitation Licences with Concealed Anti-Competition Restrictions.
(As an aside, I also think SugarCRM and imitators' use of section 7, when last I checked on that usage, vastly exceeded the permitted scope of notice, e.g., the only notices that may be required to be included somewhere in the interactive user interface display are a copyright notice and warranty disclaimer if applicable: That is made clear in the licence text's definition of Appropriate Legal Notices.
Requiring a company logo on every single user interface screen of the work and all derivative works exceed greatly what section 7 permits, not to mention requiring UI display of legal notices beyond the copyright notice and warranty disclaimer. This misuse is particularly egregious since the section 7 wording was edited to its present state at the request of SugarCRM, Inc., according to Richard Fontana's post to debian-legal a couple of years ago.)
Richard opines in this post that SugarCRM's logo requirement as of mid-2007, in his judgement complied with FSF's intent about how intrusive badgeware might be and still remain free software. I respect Richard highly and of course believe him. By 2009, when I last checked SugarCRM's terms, they were excessive enough that IMO, if FSF still think that's not out of bounds for free software, they've lost their collective minds.
Cheers, "Why struggle to open a door between us,
Rick Moen when the whole wall is an illusion?"
rick at linuxmafia.com -- Rumi
License-review mailing list
License-review at opensource.org
More information about the License-review