[License-review] Approval request for ZENTAO PUBLIC LICENSE

[Rick Moen]

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:
> https://opensource.org/licenses/CPAL-1.0

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
use.')

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.

http://opensource.stackexchange.com/questions/2622/is-it-possible-to-stop-the-removal-modification-of-my-projects-logo

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[1], 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.[2])

[1] http://linuxgazette.net/159/misc/lg/sugarcrm_and_badgeware_licensing_again.html
[2] https://lists.debian.org/debian-legal/2011/12/msg00045.html 
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
McQ! (4x80)