Followup on Exhibit B licences

[Christiaan Erasmus]

Rick

What a long reply to my email. Thanks for sending it to the OSI mailing 
list as well so that we can discuss.

As requested please see my replies beneath.

-------- Original Message  --------
Subject: Followup on Exhibit B licences
From: Rick Moen <rick at linuxmafia.com>
To: license-discuss at opensource.org
Date: 06/03/2007 05:23

> 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.

I look forward to your article as all these discussions ensure that we 
adopt the correct license in the future. We have been awaiting the GPL3 
/ LGPL3 release eagerly, as so far it looks like a good fit for 
TenderSystem, being an ASP application, and have therefore delayed a 
version release since September.

> 
>> 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.
>

We will not adopt a vanity license again, such as Apple or Mozilla's 
Public License, as it creates a new license when the copyright holder is 
changed as you are forced to do, which has to be re-submitted to OSI for 
certification. I also doubt if a project specific licenses will be 
approved, as stated in my blog at 
http://www.tendersystem.com/modules/wordpress/archives/9, due to 
proliferation issues.

I will also have a look at the Open Software License (OSL), as pointed 
out in your follow-up email, but am going to wait for the GPL3 / LGPL3 
to be finalised, as we are in this for the long run and can afford to 
wait a couple of weeks.

>> 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.
> 

I do not see the logic in this. One moment we are knocked for not using 
an OSI certified license and the next you recommend it?

According to me the TPL adheres to all the open source definitions and 
the only point that might be contentious is #10, as TenderSystem would 
not be able to run in a headless environment. I doubt if that would ever 
be the case, as it is a web based application, and can be altered to 
state that the attribution clause only has to be adhered to if 
reasonably possible.

> 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 agree and that is the loophole that I mentioned in the email and 
elaborated beneath.

> 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?

I can not speak on behalf of SugarCRM or vTiger and you will have to 
discuss that with them directly. The above mentioned reason is however 
why we released our code under the TPL, to dissuade code use without 
giving back to the community.

We might have released under the OSL, and doubt if it was certified in 
early 2005, as it never came up on our radar screen during the 
evaluation process.

The only license at the time that made sense to us was an adapted MPL + 
attribution, and are now considering alternative options as they arise.

> 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?

Reasoning for releasing under an adapted MPL + attribution is explained 
above.

> <cut as this is a SugarCRM / vTiger discussion/>
> 
>> 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.

You will note 2 instances of the word "IP theft" in my email. The first 
scenario I presume you agree with as it points to the ASP loophole.

The second is the forking issue. As stated I have no problems when a 
project is forked for technical grounds as a new project is created that 
takes the project into another direction.

I do however think that it is detrimental to the OS community when a 
project is forked on business grounds, as it creates duplication and 
confusion. You end up with 2 separate projects that have the same goals 
and the OS community would have been in a better position if their 
combined energy was directed into achieving those same goals. Confusion 
is also cast over the initial projects survival, which can lead to 
developers losing focus and even abandoning the project.

To fork a project on business grounds is also very lucrative as the 
second project does not have to carry the large initial development and 
carrying costs and only jump on-board once a project becomes successful. 
I think that this issue will proliferate in the future, especially for 
ASP based application, unless we can find a solution.

This is not necessarily a threat for embedded applications that are 
released under the GPL; as the second project can only generate income 
from support and not from re-licensing without the GPL's viral effect, 
that some clients require, but is a major risk to ASP based applications.

I hope that a solution prevents itself in the short term as I am sure 
that there are many other code bases that will be open sourced if a 
solution is found, which will be to the advantage of the OSS landscape 
as a whole.

> 
> <cut as this is a SugarCRM / vTiger discussion/>
> 
> 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 --
> 
> <cut as this is a SugarCRM / vTiger discussion/>
> 
> Do you concur, or am I missing something?

Attribution is an approved OSI concept so I do not see the problem. As 
stated above ASP based projects are in a difficult position at the 
moment, which will hopefully be sorted out in the near future due to 
these discussions.

> 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.

I do not see your point as every project has different ideologies and 
that is why there is not just one OSI approved license?

> 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.

As stated above the only contentious issue that I can see is with OSI 
definition #10 if run in a headless environment, which is not the 
scenario for web based applications.

> 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.

Please see above why I think forking for business reasons is detrimental 
to open source.

> 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".

So if I understand you correctly your contention is not regarding an 
attribution clause but against the way that it is executed?

> 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.
>
> <cut as this is a SugarCRM / vTiger discussion/>
> 
> 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?

That is the way that the MPL was written and approved and can be seen as 
a problem with vanity licences.

If I remember correctly the only changes that we made to the license was 
to change Mozilla to TenderSystem, changed the copyright holder to 
ValueCard and the jurisdiction to South Africa, as is required in the 
license, and added the attribution clause for which the license makes a 
provision.

I think that this is a completely different issue and not part of this 
discussion.

> 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?

That is why there is a TenderSystem trademark policy. We did not attach 
it to the license as it would make the license bulky and it can be found 
at http://www.tendersystem.com/modules/articles/article.php?id=16.

I understand your point that trademark usage could be used to prohibit 
usage in specific instances so it might be a good idea to include it 
should the license makes a provision for it.

> 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.

I still believe that the TPL adheres to the OSI definitions and the 
spirit of open source and there is no reason for us to change the 
license now and then again in a couple of weeks. What we have however 
done is to freeze all releases, to see what would be the best way forward.

I also think the "public perception problem" might be exaggerated a bit 
otherwise I would not have openly discussed it in these emails, on my 
blog and in the community forums, but would rather try and hide the fact.

> 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 -----

-- 
Kind regards

Christiaan Erasmus