Followup on Exhibit B licences

[David Dillard]

One point:

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

That may be true if someone were to fork the entire application.  But
what happens when someone would like to use a small portion of TPL'd
code, perhaps even a single function, and mix it with some other open
source that IS intended to be able to be used in a headless environment?

Exhibit B vendors seem to not care about that kind of reuse.


--- David



-----Original Message-----
From: Christiaan Erasmus [mailto:christiaan at valuecard.co.za] 
Sent: Tuesday, March 06, 2007 6:06 AM
To: license-discuss at opensource.org
Cc: rick at linuxmafia.com
Subject: Re: Followup on Exhibit B licences

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