[License-discuss] Is the OBM License OSD compatible?

Rick Moen rick at linuxmafia.com
Fri Jan 6 04:46:07 UTC 2017

Quoting Marc Laporte (marc at marclaporte.com):

> Hello!
> The OBM license is AGPL 3 + "Additional Terms":

Whenever I see *GPL + 'Additional Terms', I immediately think 'Oh, this
is going to be yet another badgewear licence.  

Back in the middle 2000s when there was a full-court press to badger OSI
into approving popular badgewear licences invented some years ago by a
gang of small, pushy OSBC-attending (Open Source Business Conference)
SaaS companies, the licence-reviewing regulars in/around OSI, in 2007
grudgingly allowed, after much discussion and arm-twisting of the OSI 
including from then-Board member Matt Asay, as how a minimally obnoxious
badgewear licence from Socialtext, Common Public Attribution License
(CPAL), in hopes that these pushy little OSBC-attending SaaS companies
would adopt it and cease trying to hustle OSI.  This was deemed
unobtrusive enough to satisfy various OSD-based objections including my
OSD #6 one, and a reasonable compromise for everyone.  Everyone involved
including a cross-section of the aforementioned pushy little firms
_claimed_ to be happy with this result.

Instead, CPAL -- which unlike standard badgeware licences mandated
_only_ a mandatory advertising notice (euphemised as 'Attribution Notice') 
being shown once at startup time, of modest size, and derivative works 
without a graphical user interface were absolved -- dropped like a rock
out of sight.  Pfft.  Abandoned, after all of that contention.

Instead, a bunch of these companies quietly adopted, first MPL 1.1 +
'Exhibit B' and then  *GPL 3 + "Additional Terms', abusing the language
of section 7 and pretending that a clause specifically intended to
'making exceptions from one or more of its conditions' could be
legitimately used, instead, to pile on external _restrictions_.  And
which restrictions?  Typically those would be exactly the ones everyone
found unacceptably obnoxious (details of which I'll address below), the
ones requiring that a prominent advertising badge for the original
corporate stakeholder be displayed on every user interface screen of all
derivative works.

And where did all of this come from?  In the OSI-affiliated licensing
workshops of the 1990s, we always spent some time talking about the 'ASP
loophole' as copyleft-inclined people called it, or 'that's no loophole;
that's a licence working as specified' as the permissive-licence-inclined 
(BSDish) people tended to reply.  

I.e., people who wish some licences' reciprocal obligation to work as
intended dubbed a 'hole' the ability to withhold changes if you do only
hosted ('ASP' = application service provider) deployment, on grounds of
no distribution:  Popular copyleft licences make the reciprocal
obligation be triggered by distribution, on the then-current assumption 
that substantive reuse would entail distribution.  In the 90s, the
ASP/SaaS industry was in its infancy, but we knew this would change.
And the change hit us in the following decade.

One of the pioneers was SugarCRM, Inc., which invented badgeware in a
fit of pique after Indian company vTiger forked its copylefted codebase
to create competing codebase 'vTiger CRM'.  In response, SugarCRM
shifted to a mandatory-advertising license of its creation, the
ur-badgeware licence, and most of that firm's little friends in the OSBC
club followed suit, landing the problem in OSI's lap and culminating in
the CPAL fizzle.

Discussion during that time:

Typical badgeware terms' mandatory and highly prominent advertising
always get justified as 'attribution', but that's something of a crock,
and the vTiger experience shows why:  IMO, SugarCRM wished to make, and
did make the newly mandatory commercial advertising of itself _so_
obnoxious as to dissuade commercial competitors from deploying
derivative works in the marketplace.  And that, in my opinion, leads to
the OSD problem of typical badgeware licensing:  

  OSD 6. No Discrimination Against Fields of Endeavor

  The license must not restrict anyone from making use of the program in a
  specific field of endeavor.  For example, it may not restrict the program
  from being used in a business, or from being used for genetic research.

Suppressing commercial use is one of the oldest and most traditional
ways of claiming to be open source but not delivering on the substance,
because then you can have a 'community' fork with limited commercial
rights and (if you want) a 'comercial' proprietary one, where the former
serves to feed sales to the latter.

Let's get to today's badgeware example.  
http://obm.org/content/obm-license starts out:

   Linagora wishes its paternity over OBM software to be

So, indeed, we're going exactly where I expected.

   provided that you comply with its requirements, notably [...]
   retaining Appropriate Legal Notices in the source code and the user

I haven't downloaded and examined the sources to OBM Core, but I'll bet
the mandatory advertising is on all, or substantively all, user
interface screens, right?

And there you have the problem.

These sorts of 'Additional Terms' for *GPL 3 (AGPL, GPL) not only are
grossly violative of the intent of Section 7 that is used to hook in
restrictions, but also open up a hole a mile wide to tack on (IMO) OSD
6-violaating proprietary licence terms.   And frankly, the use of
classic software licences for this purpose almost always has deceptive
effects, as presented to the public.

Other people here will of course have their own views.  FWIW, I covered
the badgeware follies of the 2000s for _Linux Gazette_ magazine in a
series of articles, e.g., http://linuxmafia.com/~rick/exhibit-b.html

More information about the License-discuss mailing list