Attribution & the Adaptive Public License

Tue Feb 6 06:08:01 UTC 2007

Quoting Timothy McIntyre (tmcintyre at terracottatech.com):

> [Adaptive Public License] necessarily complies with OSD section 10,
> because the APL was approved in 2005, after section 10 was added to
  ^^^^^^^
> the OSD in 2002.

My wife has a standard old joke about the Non Sequitur Society.  
(Their motto:  "We don't make much sense, but we do like pizza.") 
If there is such a group, just wave a printout of the above reasoning; 
I think you just aced their entrance exam.

Seriously, it's not difficult to make a fair case for existence of a
legitimate need for _some_, properly drafted "attribution" (mandatory
runtime credits) licence for Web apps and similar hosted code.  Here,
please let me show you how it's done:

Whether you as the creator of a Web application think there's a problem
_at all_ depends on whether you merely want credit (attribution)
included in the program output of works you create and distribute, or
whether you also wish to require all subsequent derivative works to
display that same output.  If the former, rejoice!  Just put insert your
copyright notice and publish using your choice of simple permissive
licence (BSD, etc.).  Anyone wanting to know who wrote Web app Foo need
only look closely at it, from that point forward.

(So, please, folks, spare us the bafflegab rhetoric about how your
badgeware clauses are supposedly necessary for "attribution".  They're
clearly not.)

The hitch comes when you're interested in shaping how derivatives behave
but find yourself having no leverage -- a problem known among copyleft
partisans as the "ASP Loophole".  Let's say you're SugarCRM, and your
biggest concern is proprietary competitor Salesforce.com.  If you
publish your CRM app's source code under any of the OSI-approved open
source licences (either permissive or copyleft), Salesforce.com could
lawfully scoop up your source code, modify and extend it to suit that
firm's needs, and use it to compete with the SugarCRM company, _without_
the displayed program output even revealing to customers and other
outsiders that it's re-using SugarCRM's work.

This is presumably exactly what Dave Rosenberg (MuleSource) had in mind
when he said

   We have run into multiple issues with public and private companies 
   who have made attempts to skirt the MPL/MSPL/maybe anything and
   essentially take Mule as their own with no recognition of the author,
   copyrights, license agreements etc. Forking is one thing, stealing is
   another.

Just to stress that I do try to listen fairly:  I do agree, Dave.  
It's a real concern.

Without something _like_ MuleSource Public License 1.1.4's Exhibit B, 
third parties could take downloadable copies of Mule ESB and run it or a
derivative behind closed doors but usable over the Web, and not only
never publish their changes but also conceal _completely_ their use of
MuleSource code.

Web apps and similar ASP (application service provider) software (AKA
"SaaS" = Software as a Service) are characteristically subject to this
problem, as re-users neither incur copyleft obligations nor need
distribute code at all:  Their model entails private code use only, with
only the _output_ of execution displayed in public, rather than
redistribution of code itself.

Notice that copyleft provisions, if present, tend to have no traction
for lack of code redistribution.  Several new licences, none yet OSI
approved, have attempted to retrofit that traction.  One is Funambol's
(Fabrizio Capobianco's) Honest Public License = HPL [1].  Similar and
slightly gentler is the Affero Public License = APL[2].  And last, there
are the still-unfinished GPLv3 drafts.[3]  

Aside:  It strikes me as very odd that all 20-odd "Exhibit B" badgeware
companies (MuleSource and others) elected to hang their clauses off a
copyleft licence (Mozilla Public License) whose copyleft provisions
inherently have _zero force_ in their (and their competitors')
no-distribution ASP usage model.  Isn't that a bit like requiring
spelunkers to wear sunscreen?  Don't they realise that about 3/4 of
their chosen licence is a _NO-OP_ for their entire market segment?

In sharp contrast to the MPL + "Exhibit B" licences with their ASP
Loophole-disabled copyleft provisions, HPL, APL, and the GPLv3 drafts 
have, by design, copyleft features that remain _functional_ in ASP
markets.

But getting back to the point, the "Exhibit B" clauses do address the 
entirely real ASP Loophole concern for Web apps -- but do so in a clumsy 
fashion that impairs reuse; in particular, commercial reuse.  For the
most part, this seems to be quite deliberate, for reasons already cited.
Add to those the trademark clauses of most Exhibit B sections, e.g.:

   This License does not grant any rights to use the trademarks
   "MuleSource", "Mule" and the "MuleSource", "Mule" logos even if such
   marks are included in the Original Code or Modifications.

Aside from Larry Rosen's point in this space, that "forking is always
allowed for open source software regardless of the trademarks it bears,
but the licensor should fear that his trademark will become useless [RM:
i.e., generic] if he requires it to be displayed on those forks"[4],
don't trademark clauses such as the one quoted above look a whole lot
like efforts to curtail third-party use in commerce?

Anyway, closing the ASP Loophole if you _don't_ care about functional 
copyleft obligations is pretty easy, and doesn't require mandating 
a bunch of graphical advertising shoved into every user's face, each and
every time the application is launched.  The alternative has been
mentioned here before:  It's a simple About screen, that is required to
be available from the main display.  To ease OSD#10
technological-neutrality concerns, make it be required only where the
derivative has program output and be in whatever supported format best
approximates the desired name + logo + URL display.  E.g., for a
derivative with only spoken-word output for the blind, that "About"
information could then reasonably be the spoken name of the firm + URL.

We've not yet seen such a licence.  If these 20-odd firms really care
about "attribution" and aren't after mandatory advertising, I'd suggest
that we really should.

I'd be glad to write one, as a substitute Exhibit B.  The above almost
qualifies by itself, I'd imagine.  (Unlike the ones we've seen thus far,
with the honorable exception of GAP, mine would aspire to be templated
and usable by anyone.)

[1] http://www.funambol.com/blog/capo/2006/08/honest-public-license.html
[2] http://www.affero.org/oagpl.html   http://www.affero.org/oagf.html
[3] http://gplv3.fsf.org/
[4] http://www.nabble.com/RE%3A--Fwd%3A-FW%3A-For-Approval%3A-Generic-Attribution-Provision--p7847787.html

-- 
Cheers,             "The seminar on Spam Canceling has been canceled again.  The 
Rick Moen           person who supposedly canceled it says it wasn't him." 
rick at linuxmafia.com - Znqr Lbhybbx, Usenet Cabal J.D. Falk jdfalk at cybernothing.org