Followup on Exhibit B licences

Christiaan Erasmus christiaan at
Wed Mar 7 11:19:13 UTC 2007


Please let me know if we should take these discussions private as we are 
starting to drift to a point were it may not add value to the OSI 
discussion list readers any more?

My responses beneath.

-------- Original Message  --------
Subject: Re:Followup on Exhibit B licences
From: Rick Moen <rick at>
To: license-discuss at
Date: 07/03/2007 01:59

> Quoting Christiaan Erasmus (christiaan at
>> What a long reply to my email. Thanks for sending it to the OSI mailing 
>> list as well so that we can discuss.
> No problem.  I hope this discussion is of some use to ASPs -- though my 
> main motivation, as I mentioned, is to make sure I'm not missing
> something important before attempting to analyse the situation for
> _Linux Gazette_.  (That is:  I'm delighted if your business benefits,
> but my primary concern is writing a relevant and cogent article.)

> The ASP market has aspects unfamilar to most of us syadmins,
> programmers, lawyers, and sundry business types who frequent
> license-discuss, so some caution is needed.  E.g., usually one can
> implicitly assume that use entails distribution, which is not the case
> in your industry (though it is in related appliance markets).

I am glad that you accept the uniqueness to the situation.

> (The aim of speaking carefully of course runs headlong into the desire
> to speak casually and not spend all day composing mail.  C'est un monde
> imparfait.  Il y a également des impôts.)  
>> 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.
> As noted, you can pick either of two OSI-certified licences with ASP 
> language today -- or several others that on their face are obviously
> OSD-compliant, though nobody has yet submitted them (which would take
> you all of 15 minutes).  As long as no third-party encumbrances don't
> interfere, you can later shift to a better licence the very moment a
> better one emerges.

I disagree and as you stated in a previous email "My experience is that
businesses' evolving software licence strategies are often primarily
reactive, and seldom well thought out." 

We want to prevent being just reactive and are looking for a long term 
solution rather than just an intermediate license that we have to change 
again in the short-term.

>> I also doubt if a project specific licenses will be
>> approved, as stated in my blog at
>>, due to
>> proliferation issues.
> 1.  Who said you should adopt a product-specific licence?  (Before you
> reply, please see my explanation, below, that, no, ASPL and MPL 1.1
> without addenda _are_ fully reusable -- as are all well-written
> licences.)  You should not.  Product- or company-specific licences (e.g,
> SugarCRM Public License and imitators) are an obvious blunder to be
> avoided.

In our case we have to change the jurisdiction in the MPL clause 11 from 
the "Northern District of California" to South Africa, where we are 
based, which then results in a new license being created as stated in 
clause 6.3, which will then have to be re-submitted for approval.

This sounds like a small irrelevant change but a litigation in America 
would be extremely costly and software patents are also not recognised 
in South Africa.

APSL goes a step further in clause 7 stating "No one other than Apple 
has the right to modify the terms applicable to Covered Code created 
under this License" so we will not be able to change the jurisdiction in 
that case and can therefore not use the license.

We are therefore currently stuck with the OSL that I am having a look at 
but as stated I think that the better option is to wait for the 
GPL3/LGPL3 finalisation.

> 2.  When OSI says it wishes to curb licence proliferation, it refers to 
> curbing continued proliferation of 
> o  Licences that are redundant with more popular licenses
> o  Licences superceded by improved versions.
> o  Licences that are not reusable.
> o  Licences voluntarily dis-recommended by their authors.
> o  Licences concentrated upon a special purpose and having "unusual 
>    terms and conditons" towards that end, e.g., conformance 
>    to a company-defined API standard.
> The License Proliferation Committee seeks to move such (extant) licences
> to a "not recommended" category (tier 3) on OSI's Web pages, others to a
> deprecated category (tier 2) -- to better guide future licence users.
> They would remain OSI certified.
> If I understand correctly, OSI in _no way_ seeks to discourage new
> licences, especially if they _are_ genuinely innovative, well written,
> and reusable.  So:  Sorry, no -- licence proliferation is not a
> reasonable excuse for sticking with a blatantly proprietary "Exhibit B"
> licence instead of creating or using a real open source licence tailored
> to address the ASP Loophole.

We would rather want to adopt a tier 1 license instead of a tier 2 / 3 
as it would then just become an issue again in the future.

>> We will not adopt a vanity license again, such as Apple or Mozilla's 
>> Public License....
> The mere mention of a firm or product in a licence does _not_
> automatically make it a "vanity licence".  Both ASPL and MPL are useful
> working licences, despite that small misfeature.  What matters is the
> substantive text, not the name.

As stated above we can not use the licenses "as is" due to the jurisdiction.

>> [...] 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 beg your pardon?  The _text_ of ASPL and MPL is reusable.  It does not
> need to be altered before use by third parties.  Ergo, it does not need
> recertification upon reuse.
> If memory serves (and my memory _is_ demonstrably sometimes leaky), IBM
> Public License was an example of a licence that, as originally written,
> included IBM-specific passages in the substantive text.  IBM noted this
> drawback, rewrote it, and issued the new text as "Common Public
> License".  The renaming, however, was not the essential part; the
> rewritten text was.

You are correct here, my mistake as it is explicitly stated in clause 
6.3 that exhibit A changes do not constitute a license change.

>> 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.
> Your implicit assumption of GPLv3 issuance in a couple of weeks strikes
> me as wildly and breathlessly optimistic.  If you're correct, wonderful;
> but, as Damon Runyon said about the race not necessarily being to the
> swift nor the battle to the strong, that's not the way to bet.
>> 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?
> On the contrary, sir:  I was _not_ "knocking you for not using an
> OSI-certified licence".  I was knocking SugarCRM, ValueCard /
> TenderSystem, and about 17 others for using a licence (and minor
> variations thereupon) that on its face is blatantly contrary to the OSD,
> while claiming to be open source.  That action is deceptive in effect,
> sir.
> Let us say that you wish to use an OSI-certified licence, but find that
> none meets your company's needs.  The logical action, then, would be to
> draft a licence that does meet those needs, that you honestly after
> careful attention believe to be OSD-compliant, and submit it for OSI
> scrutiny.
> You could then in good faith tell the public:  "TenderSystem is under
> the Foo Public License 1.0, which is not yet OSI-certified but was
> submitted for certification on 2007-XX-YY, and which we believe is open
> source."
> Nobody could reasonably fault you for that.
>> 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 really hope you don't _seriously_ believe that, but are just trying to
> see if it will fly.  Well, it doesn't.
> TenderSystem Public Licence 1.1, like the other "Exhibit B" licences,
> (apparently by intention) impairs commercial reuse (thus violating
> OSD#6) by requiring a trademarked logo + company name on "every user
> interface screen" while simultaneously specifically denying a trademark
> licence.  Some would say that the effect is to substantively _also_
> violate OSD#3 (allowing derivative works):  The theme that encumbering
> program _usage_ is never acceptable runs through those two provisions
> and elsewhere in OSD.  (Again:  You ASP companies are essentially asking
> for a _small_ break in this area, in order to deal with the ASP Loophole 
> problem.  That is conceivable, but the trademark nonsense plus the bit
> about "every user interface screen" is obviously unreasonable.)

According to the TPL:

"2.1. The Initial Developer Grant. The Initial Developer hereby grants 
You a world-wide, royalty-free, non-exclusive license, subject to third 
party intellectual property claims:

(a) under intellectual property rights (other than patent or trademark) 
Licensable by Initial Developer to use, reproduce, modify, display, 
perform, sublicense and distribute the Original Code (or portions 
thereof) with or without Modifications, and/or as part of a Larger Work; and

(b) under Patents Claims infringed by the making, using or selling of 
Original Code, to make, have made, use, practice, sell, and offer for 
sale, and/or otherwise dispose of the Original Code (or portions thereof)."

Commercial re-use and derivative works are explicitly allowed and the 
trademark usage is covered in the trademark usage policy and fair use is 
also applicable.

> And of course the OSD#10 contravention is not just a matter of
> "contention"; it's plainly so.

Once again being a web based application this should not be an issue as 
I doubt that it will ever be used in a headless environment. But the 
license can be altered to state that if reasonably possible then the 
annexe must be adhered to.

> Sorry if that comes as bad news:  I figure you and most of the 19 other
> firms pretty much just followed SugarCRM down the garden path -- but,
> no, it really doesn't fly.
> [vTiger and similar forkers were _never_ required by SugarCRM's choice
> of copyleft licence -- MPL -- to give back code used solely in ASP
> deployment, so isn't MPL a damned peculiar choice, to begin with?]
>> 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.
> Consider for the sake of discussion a firm that forks TenderSystem and 
> modifies/runs it in a pure ASP deployment.  TPL 1.1 does _not_ require
> such a firm to give back to the community!  You say that was its aim?
> Well, then, it obviously did not succeed:  All it does is impair commerce.
> As noted, there _are_ other licences that could have secured that aim
> for you.  You didn't use any of them, not even the thwo that are
> OSI-certified!
>> 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.
> It's a little academic, but some searching of the list archives suggests
> that OSL was already certified by 2004, e.g.,
> .

As you will see in the OSL "This License is Copyright © 2005 Lawrence 
Rosen." so how could it have been OSI approved in 2004?

As you correctly state this is academic because the point was that it 
did not show up on our radar screens when we were evaluating possible 

>> 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.
> As I had assumed obvious, I cannot agree that any forking compliant
> with one's specified licensing terms could ever qualify as "theft":
> If you accidentally give people more rights to your property than you
> intended, then that is _your error_, not someone else's criminal act.

This is why we are having these discussions. We are looking for the best 
possible license to adopt and know that the word "theft" is incorrect 
but it gets the point across and is easier than saying "having the code 
used in a manner for which it was not intended or contemplated" every time.

> Frankly, that is the sort of rhetoric we expect people to abandon
> some years before leaving elementary school.
> [forking:]
>> 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.
> 1.  What is beneficial to the OS community is irrelevant to the question
> of whether something is open source.  OSI's sun^Wcandle shines on the
> benevolent and malevolent alike, and OSI makes no effort to purify the
> intentions of anyone.

On the contrary, this is about what is to the benefit of the OS 
community and the OSS landscape as a whole.

I also believe that there are many more code bases that will be open 
sourced if a solution can be found.

> 2.  Duplication and confusion are hardly confined to forks for business
> reasons.  (Exhibit A: Theo de Raadt.)
> 3.  The _ability_ to fork for business (among other) reasons is the
> users' assurance that the project can be trusted to persist and not die
> when the sponsoring firm goes kaput or decides to go into beekeeping.  
> Want to retain leadership?  Do a better job than the other guy -- the
> reason why "Unbreakable Linux" is being slowly coaxed out of the ring by
> Papa Darwin.
> Confusion?  We deal with it.  It's the flip side of freedom and choice.
> Now, honestly, I'm having a difficult time believing that you didn't
> already know all that.
>> 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. 
> It ain't not necessarily so (to quote Sportin' Life).  The business case
> for allowing forks, in situations where the economics so dictate, is a
> separate discussion, covered largely here:

It is part of this discussion and the forking issue is not mentioned 
once in the "Open Source Case for Business". As stated previously web 
based applications are in a unique position and we have to determine the 
best way forward.

>> I think that this issue will proliferate in the future, especially for 
>> ASP based application, unless we can find a solution.
> To reiterate, it is not OSI's job (let alone mine) to "find a solution". 
> The problem you're speaking of is _your_ problem -- along with your
> problem of (at present) shooting your PR profile in the foot.

That is why *we* are looking at the various options and will hopefully 
find a solution shortly.

> <cut as this is a SugarCRM / vTiger discussion/> 
>> 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.
> Actually, support is not the only revenue model for embedded
> applications, either -- but that, too, is a separate discussion.
>> I hope that a solution prevents itself in the short term....
> Look, I know this is pretty blunt, but:  This is _you_.  Here.  Now.
> As the Buddhists would say:  "Be here now."  This is not FSF's problem.
> It is not OSI's problem.  It's _your_ problem.  You are, _right now_, 
> saying deceptive things to the public.  You can and should cease doing
> so.  If you wish to adopt an OSD-compliant licence for your codebase
> that has language addressing the "ASP Loophole", nothing's stopping you.
> Two of them are even _already_ OSI certified.  No effort from you is
> required; not even an e-mail to apply for certification.

As stated I do not think that the TPL, if used for a web based 
application, contravenes the OSI definitions or the spirit of open 
source. We are looking at our options as we would prefer adopting an OSI 
approved license, instead of a license that still has to be approved, 
but are evaluating our options as we want to implement a long term solution.

>>> Do you concur, or am I missing something?
>> Attribution is an approved OSI concept so I do not see the problem.
> 1.  The OSI does not "approve concepts".  It certifies licences.

Agreed, but do you agree that attribution clauses are present in some of 
the certified licences?

> 2.  The term "attribution" in this debate has seen a consistently
>     questionable use to obfuscate the OSD issues at hand and make facile, 
>     inaccurate, and irrelevant comparisons to prior licences.  So, we've
>     long ago reached the point where we've asked people to please cut
>     the bullshit.
> If you mean something specific by your term "attribution" in this
> context, please denote/describe that specific thing instead -- assuming
> you have, indeed, thought this through.  But please, no more of these
> meaningless and insultingly polemical handwaves about "an approved OSI
> concept" and such.
>>> 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?
> I'm not sure how I can make my point (above) clearer, but I'll try:
> There are two main schools of thought within open source aka free
> software:  those favouring simple permissive licences (e.g., BSD), and
> those favouring copyleft licences.  (That is a vast oversimplification,
> however, if only because many people will favour each of those in
> different circumstances.  Even FSF has been known to urge coders to
> switch from copyleft to simple permissive licences to advance long-term
> goals, e.g., when FSF urged Foundation to switch from copyleft
> to 3-clause BSD licensing for the Ogg Vorbis libraries.)
> Mr. John Roberts referred to vTiger's actions in creating an entirely
> legitimate, licensed fork as "theft" and "lies".  My point is that 
> the BSD community (and other users of simple permissive licences) would
> regard such forks, whether for "business reasons" or for any other reason
> (and even if proprietary and with no access to source, as vTiger was not)
> as precisely the sort of thing they _specifically intended_ to permit in
> their licensing -- and certainly not as constituting "theft" and "lies".
> And, as mentioned, OpenCRX _does_ in fact use 3-clause BSD licensing for
> its enterprise CRM.

Once again I still do not see your point as there are various ideologies 
and therefore many approved licences depending on the different 
situations, such as the Ogg Vorbis libraries that you mention, which 
goes against the normal FSF recommendations.

Web based applications are also in such a unique situation, which we 
have to address.

>>> 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.
> 1.  You pretty much completely ignored what I said (what you quoted).
>     This is sad -- because that is the only sort of "badge" requirement
>     I see as having a snowball's chance in Hell of passing
>     certification.
> 2.  As noted, OSD#10 is hardly even the biggest problem, just the most
>     readily apparent one.
> 3.  You cannot possibly predict what environment someone might wish to
>     run a derivative work in.  
> An aside:  What is it with you ASP firms' lack of vision?  You write
> product-specific and company-specific licenses, and look at us pole-axed
> when we point out that you've stupidly impaired reuse, and/or that ten
> companies' badgeware logos on "every user interface screen" of a
> derivative work will start looking pretty ridiculous -- and may be
> physically impossible if all of those must be in the "very bottom
> center" (e.g., SugarCRM's licence).  And now, you, for one, cannot
> conceive of someone using code from a Web-based application in a
> non-Web-based derivative work.  What's up with that?
> I can only guess -- struggling to be charitable -- that the notion of
> code and license reuse is a new thought to most of you, as (I would
> guess) open source is, in general.

This is where different ideologies come in to play and why not all OSI 
approved licence applications can be distributed together, most basic 
example being GPL and BSD?

>>> 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 device 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?
> Again, I am surprised that I should be called upon to elaborate on a
> passage I consider quite clear, but I will try:
> ASP firms, as I understand it, assert that they wish to encumber runtime
> program behaviour in order to ensure that their author credit can be
> found by users at runtime.  (I have serious doubts about the necessity:
> Licences with ASP-specific language have alternate ways of enforcing 
> giveback and source access, which strike me as meeting all legitimate 
> needs for author credit.)
> Scrutiny of "Exhibit B" licences such as SugarCRM's reveals a rather
> blatantly large degree of overreaching:  The clauses -- which your firm
> then adopted with minor changes -- enforce the original developer's
> trademarked advertising on "every user interface screen" while
> simultaneously asserting a lack of trademark licence (and thus implying
> a trademark legal threat against commercial reuse).  That requirement is
> way, way, way in excess of what is necessary to make users able to find
> the original developer's authorship role at runtime.
> To the extent that one might reasonably assert a need for the latter
> (for user to be able to find the original developer's authorship role at
> runtime), I would expect the requirement to intrude to the absolute
> minimum extent possible onto runtime usage -- to not constrain
> application behaviour, and not dictate technology.  I therefore outlined
> one general way such a requirement might be specified (via an "About"
> screen).

We will take an "About Screen" option into consideration with our 
evaluation. The problem once again is that if a second company would 
want to give the impression that a derivative work is their own that the 
"About Screen" could be obfuscated or hidden.

> [Open source entails making possible the future reuse of both code and
> licences:]
>> That is the way that the MPL was written and approved and can be seen as 
>> a problem with vanity licences.
> You are mistaken, sir.  MPL 1.1 is fully reusable by third parties.
> Read it.  For gosh sakes, it's _inside your own licence_.

As stated above it is not reusable by a project based outside the USA.

>> 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.
> You "only" added proprietary riders as Exhibit A, yes -- bobbing along
> in SugarCRM, Inc.'s wake.  The point is that those riders render the
> licence company-specific.  Thus my point.
>> I think that this is a completely different issue and not part of this 
>> discussion.
> No.  Wrong.  Read it again, please.
> [Trademark problem:]
>> 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
> 1.  Licences' meaning should be parseable by the terms of those
>     licences, alone.  (Your licence also doesn't refer people to the
>     separate trademark policy.)
> 2.  Your trademark policy is obviously subject to change at your firm's 
>     option.  Are people supposed to think their software licensing
>     rights for commercial reuse hinge on an at-will changeable document
>     entirely separate from the licence itself?
> But, most of all:
> 3.  Your (current) trademark policy grants rights for use that are
>     subject to ValueCard's "sole discretion" (clause  Which
>     should be sufficient commentary without even reading the rest of the
>     page -- and, in fact, I stopped reading there.

A brief Trademark policy could be included in the license.

>> I still believe that the TPL adheres to the OSI definitions and the 
>> spirit of open source
> Again, this is going to be blunt:  Your belief starkly conflicts with
> objective reality, sir.  Please note that various OSD problems have
> already been discussed in detail on this mailing list.
>> 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.
> Honestly, your firm is a respectable small enterprise, but not at all
> prominent.  

As correctly stated we are a small enterprise and are therefore 
evaluating our options very seriously as a small mistake could be very 

We also offer a very niche application which will not become very 
prominent but you sent my email to the OSI mailing list and that is why 
I am here.

> Even SugarCRM, for all its VC funding and shameless
> business puffery about alleged staffing and sales accounts, is pretty
> obscure despite the incessant marketing drumbeat by interested parties
> trying to drive up stock prices.   (See, e.g.:  "Who will buy SugarCRM?" by
> SugarCRM Board of Advisors member Matt Asay,
> However, as I try to point out in the quoted debunking thread, I doubt
> you want to develop, and trail around with you, a reputation for 
> making deceptive claims in public.  And, getting back to brass tacks,
> calling "Exhibit B" code "open source" _is_ attempting to deceive the
> public.  Your firm is doing that _today_.  You should stop doing so.  Today.
Kind regards

Christiaan Erasmus

More information about the License-discuss mailing list