Followup on Exhibit B licences

[Rick Moen]

Comments on things I might be overlooking are welcomed.  (I've had some
correspondence in e-mail with Christiaan, who runs one of the "Exhibit
B" firms.  Christiaan's editorial about vTiger's so-called "theft" is at 
http://www.tectonic.co.za/view.php?id=392 .)


----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 5 Mar 2007 18:29:49 -0800
From: Rick Moen <rick at linuxmafia.com>
To: Christiaan Erasmus <christiaan at valuecard.co.za>
Subject: Re: (forw) Re: Report 5

Quoting Christiaan Erasmus (christiaan at valuecard.co.za):

> Many thanks for the private email, I will not divulge any of it's
> content.

Actually, you're welcome to (as I had removed all personal and company
names).  I was just asking editor Ben Okopnik to please not publish it
in _Linux Gazette_.


> I agree with you but as you know offering an ASP application places us 
> between a rock and a hard place at the moment. 

I agree.  I have a few thoughts that I'm attempting to hammer into a
coherent follow-up article for _Linux Gazette_, that would attempt to
review the problem, and, in a constructive spirit towards ASP firms, 
help them deal with this issue.  (See below.)  Your comments would be
welcome.

It's a subject concerning which one can easily make mistakes, so I'm
attempting to think matters through carefully.

> The only open source licences that would prevent ASP pilfering is GPL
> v3 (not released yet), Affero Public License (not OSI certified) and
> Honest Public License (not OSI certified).

In addition, Apple's licence also has an ASP clause, and _is_ OSI-certified.

> I am sure that this will be sorted out in the next couple of months but 
> in the meantime the only available option is to use an adapted MPL + 
> attribution, even though it has it's own loopholes.

Honestly, in my opinion it would be much better to use something like
Affero and disclose that OSI hasn't certified it, but that you believe
it to meet OSD's criteria -- and you can certainly submit it to OSI, for
certification.  A good-faith effort at an OSD-compliant licence, with or
without certification, would be better received and more useful to ASPs
than just reusing SugarCRM's really abysmally written MPL + Exhibit B
licence, which rather blatantly violates at least two or three of OSD's
ten principles.

Anyhow, some thoughts on which I would value your comments:

1.  For purposes of discussion, I will distinguish between ASP and SaaS
(Software as a Service) scenarios -- though I know the terms are most
often used interchangeably, elsewhere.  In that (invented) distinction,
ASP or "hosted" software is not distributed to customers but rather
merely used by them through network access, while SaaS software is
distributed to customers, e.g., in an appliance.  Thus, for example,
Zimbra software gets deployed on-premises behind the customer's
corporate firewall; that usage model would be dubbed (for purposes of
present discussion) SaaS in contrast to ASP deployment.

2.  In a pure ASP scenario, the reciprocity clauses of conventional
copyleft licences, such as GPLv2 or MPL 1.1, appear to be pointless
because they have no effect.  That is, those licences' obligation to
make available source code is triggered by distribution, which does not
(or at least need not) occur in ASP usage.  Effectively, all such
licences are converted into an approximation of the BSD licence, as long
as code distribution does not occur.

I thus find SugarCRM's choice of MPL (modified or not) in the first
place rather peculiar:  Third-party reusers such as vTiger were _never_ 
obliged to share their modifications, as long as their derivative works 
continued to be developed, deployed, and made available to customers
behind closed doors -- and not embedded into "SaaS" appliances (or
otherwise distributed).

Do you concur, or am I missing something?


Since such licences are, in a functional sense, tantamount to being the
BSD licence, why would one not _use_ the BSD licence for that purpose?
For example, the openCRX enterprise CRM software is published under the
BSD licence:  http://sourceforge.net/projects/opencrx

Why use a blatantly non-open source licence, e.g., MPL 1.1 + Exhibit B, 
and get flamed for falsely and deceptively claiming to be open source, 
when the "copyleft" provisions aren't even functional, giving you the
worst of both worlds?


On the vTiger incident:  I am trying to approach this in a spirit of
empathy and charity, but how can SugarCRM have _not_ known that such a
fork was explicitly permitted by their very choice of licence?  SugarCRM
seem to have been surprised, shocked, and indignant at that particular
turn of events.  Pardon my bluntness, but that seems uncommonly
negligent of them to not understand the functioning of their own licence,
which is after all a key aspect of their business.

(I realise much of the above recapitulates the private mailing list post I
forwarded to you.)



> I keeping a keen eye on the GPL3 as it could be a very good solution for 
> us. It could prevent IP theft on it's own but first prize would be if an 
> basic attribution could be attached to prevent "IP theft". I have no 
> issue when a project is forked for technical reasons, as that is an open 
> source advantage, but consider it detrimental to open source as a whole 
> if done for business grounds.

It is very important to note that the right to fork for _any_ reason
whateover is an absolutely vital principle of open source.  If you
cannot bear the thought of someone else using your software to compete
against your software-based business, then you should not open-source
your software -- and also should not _call_ it open source.  Period.

What vTiger did was not "IP theft", regardless of how much it surprised
John Roberts:  It was reuse that SugarCRM had _explicitly_ permitted, in
its then-current licence (although that licence was, ironically, already
not open source because of OSD#10 violation, if nothing else).

"IP theft" _would_ be if vTiger had violated SugarCRM's copyright property
rights in any way whatsoever.  SugarCRM would then, of course, be
entitled to restitution under tort law, through civil litigation.

It is not "theft" when someone takes your licence seriously and obeys
its terms to the letter -- even if the result is not what you intended
because you weren't paying attention and failed to specify your
licensing terms competently.

When a firm claims perfectly lawful observance of its licensing terms is
"theft", we call that two things:  A bit pathetic.  And dishonest.



John Roberts wrote:

    We do not think it very cool of you to claim ownership to something
    you did not write one line of code for.

I'm confused:  Where precisely did vTiger "claim ownership"?

My recollection (and expectation) is that SugarCRM placed copyright
notices in their source code.  When vTiger created their fork, they
would have been legally required to leave those copyright notices in
place.  Stripping those notices is a serious violation of copyright law,
and would lead to heavy tort damages.

I've seen no showing whatsoever that vTiger did anything of the sort.
I'm betting that, if I were to download "vTiger CRM" and page through
its source code, I would see SugarCRM's copyright (ownership) notices,
exactly as required by law.

If that is the case, then vTiger did not "claim ownership", and
SugarCRM's ownership interest remains fully visible in any copy of the
source code.

Do you concur, or am I missing something?


vTiger _could_ have forked SugarCRM's codebase and done a pure ASP
deployment without ever issuing source code, in which case SugarCRM's 
role might have been invisible.  However, they happen not to have done
that. 


Roberts also stated:

    vtiger is a lie - the legal product is called SugarSales from
    SugarCRM Inc.

I'm gathering that Roberts does not wish to permit anyone the right to
fork his company's code -- since the right to fork, inherent in all open
source software, entails the right to create any derivative work for any
purpose, as long as you honour the licence terms and retain all
extant copyright notices in the source code (per copyright statutes).

That is absolutely his right -- and would mean that he isn't yet
prepared to publish open source.  The open source world has no problem
with such proprietary software companies.  We merely have a problem with
such companies deceptively claiming to be _doing_ open source, when they
are not.


Now, my guess is that Roberts's rather pitiful and melodramatic
complaint about "theft" and "claiming ownership" boils down to this:

"I, John Roberts, am retroactively surprised by our licence's having
granted you permission to reuse our code with the name of _our_ firm
being visible only in the source code of your derivative work.  That's
not good enough for us.  We want you to be required to plaster our
company name all over the displayed program output, as well."

And that is part of what SPL's 1.1.3 and 1.1.4 revisions added.

Restrictions on code _use_ are pretty much never OK in open source.
That idea is encapsulated in OSD provisions #10, 3, 5, and 6.  SugarCRM
and the various badgeware companies that have copied it (including
yours) nonetheless want special dispensation to require specific types
of runtime "attribution" because of problems unique to ASP deployment --
e.g., firms _like_ vTiger forking code but then never issuing source -- 
but also because they simply _want_ to force advertising in derivative
works at runtime, even when (like vTiger) the third parties _do_ issue
source.

Do you concur, or am I missing something?


There is entire division of open source, those who advocate "simple
permissive" licences like BSD or MIT/X (as opposed to copyleft ones),
who would regard this fixation with insisting on runtime credit as
childish:  The BSD community _intentionally_ permits others to create
proprietary forks of their work, if others so wish.  This is why, to
this day, there is BSD code in some Microsoft Corporation proprietary
programs.  Users never see the original BSD coders' copyright notices
concerning the derivative works, because Microsoft doesn't publish the
matching source code, but the BSD coders don't go around crying about
"theft" and "lies":  This sort of third-party re-use is one of the
things they _intended_ to allow, when they specified the BSD licence.

But SugarCRM (and imitatators) don't share that philosophy and
intention, and thus desire to impose runtime restrictions.

All well and good -- but is the result of those runtime restrictions
open source?  I predict that such a model couple pass OSI scrutiny only
if the scope and nature of the restriction on runtime behaviour is
absolutely the minimum necessary to ensure that original-author credit
can be found, in derivative works deployed ASP-style, i.e., without
source code access.  Why?  Because, as I said, restrictions on code
_use_ are pretty much never OK in open source. 

You alleged that forking "for business reasons" should not be OK.
Wrong, sir.  Right to fork for any reason whatsoever, and use for any
purpose, is in fact an _explicit core requirement_ of open source.
Thus, any runtime encumbrance needs to be sufficiently minimal in effect
as to not stand in the way of such use-for-any-purpose.

The way to do that seems pretty obvious to me:  You would require that
the program output, if any, include an "About" screen of specified
information crediting the original developer -- or whatever is the
closest approximation that the output devcie permits (e.g. spoken credit
text for blind-user software).  _Not_ an advertising display with a
mandatory graphical logo on "every user interface screen".



Two last thoughts, on which I'd appreciate your comments before I draft
my article:

1.  Open source entails making possible the future reuse of both code and
licences, by third parties.  SugarCRM's licence, however, is written in
such a fashion as to make it completely SugarCRM-specific.  It cannot be
applied by any other original developer.  Again, as with the blunder
that left Roberts surprised, shocked, and indignant at vTiger's
(explicitly permitted) fork, I cannot help seeing this as fundamental
ineptitude on SugarCRM's part.  Is there nobody there who knows what
he or she is doing?

The same is true of all of the Exhibit B licences that copied
SugarCRM's, including yours.

Do you concur, or am I missing something?



2.  All (I think) of the Exhibit B licences include a clause that
explicitly denies conveyance of a trademark licence -- immediately
before or after the clause that requires third parties to display the
trademarked company name and logo on "every user interface screen".
(As a reminder, trademark encumbers commercial reuse of the names,
styles, images, etc. in question.)

Translating that into everyday language, the net effect is:  "We require
you to festoon our trademark all over your derivative work -- but, by 
the way, we explicitly don't allow you to use our trademark in commerce,
and may sue you if you try it."

This, of course, is pretty much the same as prohibiting commercial
reuse.

Do you concur, or am I missing something?



In conclusion, the Exhibit B solution is garnering you and your 18 or so
fellow... forks of SugarCRM's blunders the worst of both worlds.  If 
I were you, I would not just sit around making the problem worse by 
perpetuating a demonstrably false claim of being open source, and
justify it by saying you're waiting to see if GPLv3 might be a better
solution.  You have a huge public perception problem _now_, and every
day you let it persist is a day lost.

Today, you have your choice of four copyleft licences (cited earlier)
with ASP clauses; one of those (APSL) is even already OSI-certified.
_You_ could adopt and submit for OSI certification any of the other
three[1].  If you're serious about intending to be open source, what are
you waiting for?  I hope it's not leadership from SugarCRM, because
recent events suggest you really should not hold your breath waiting for
that.

[1] Affero Public License, Honest Public License, and the two GPLv3 
"discussion drafts" that have been issued thus far.

Sincerely,
Rick Moen
rick at linuxmafia.com

----- End forwarded message -----