Followup on Exhibit B licences
Rick Moen
rick at linuxmafia.com
Tue Mar 6 23:59:26 UTC 2007
Quoting Christiaan Erasmus (christiaan at valuecard.co.za):
> 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).
(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 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.
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.
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.
(I don't speak for OSI, however, and the above are merely my inferences.
Like President Zaphod, I'm just some guy, y'know?)
> 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 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.
> 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.)
And of course the OSD#10 contravention is not just a matter of
"contention"; it's plainly so.
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.,
http://www.crynwr.com/cgi-bin/ezmlm-cgi/3/8461 .
> 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.
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.
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:
http://www.opensource.org/advocacy/case_for_business.php
> 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.
Let me give you an example of the latter: SugarCRM, Inc. sends out
representatives to talk to user groups and other public forums -- and
then people like me get to clear up their misstatements of fact. This
keeps happening. Here's the most recent post-lecture clean-up:
> Clint Oram, one of the co-founders of SugarCRM will talk about Open
> Source Software at SugarCRM. http://www.sugarcrm.com/crm/
I'm curious as to whether Clint ever mentioned that their "SugarCRM
Public License" is not, in fact, open source.
It's MPL 1.1 plus a proprietary addendum that deliberately impairs
third-party commercial use (absent a separate commercial licence), plus
holds a legal threat over third-party commercial reuse, by requiring you
to use SugarCRM's trademarked logos but specifically denying you a
licence to the trademark rights.
[later:]
> Yes, he talked about that. From what he said, most of the product (the
> core part) is completely free and open.
The core components actually are not open source either: As mentioned,
they are SPL, which is simply not an open source licence of any sort.[0]
> http://www.mozilla.org/MPL/ is what he said Sugar is based on.... thus
> the SPL license on their Web pages.
SPL "based on" MPL, in the sense that it comprises MPL 1.1 with a rider
(appendix) designed to render its net effect proprietary, by impairing
third-party commercial reuse and holding a trademark legal threat over
such use.
> He mentioned it is very similar to the way MySQL does their licensing.
That is likewise actually false. MySQL AB offers database software under
your choice of GPLv2 or a proprietary "commercial" licence
(http://www.mysql.com/company/legal/licensing/opensource-license.html[1]).
SugarCRM doesn't offer any open source option at all.
> He did mention a competitor of theirs took the core part, created a
> whole product around it, and is selling it in competition with Sugar.
Yes, that would be vTiger CRM.
> One of the main things he did point out is the consultants offering
> Sugar as a solution can customize and integrate to their heart's content,
> and charge for their services.
That is often true of proprietary software. But most proprietary
software firms don't deceptively claim to be open source. It's also
noteworthy that about 19 other firms have copied SugarCRM's licence;
it's likely that many of them believe honestly (but in error) that their
licensing is open source.
> It's an interesting model, that seems to be working well for both
> implementers and company, although not a pure GPL software.
SugarCRM is not merely not "pure GPL" but also no variety of open source
at all.
[0] Or, as OSI Board member Chris di Bona puts it, "SugarCRM is not
flippin' open source." See:
http://egofood.blogspot.com/2007/02/my-outrage-is-quite-present-i-assure.html
(Chris might make a really good speaker for you.)
[1] Plus a special permission grant on their libraries, above and beyond that:
http://www.mysql.com/company/legal/licensing/foss-exception.html
Now, how much credibility do you think SugarCRM, Inc. retains with that
group, after stretching the truth rather severely, and getting caught at
it? Thus my reference to its (and your) PR problem.
> 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.
> >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.
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 Xiph.org 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.
> >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.
> >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).
[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_.
> 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 http://www.tendersystem.com/modules/articles/article.php?id=16.
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 2.2.1.1). Which
should be sufficient commentary without even reading the rest of the
page -- and, in fact, I stopped reading there.
> 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. 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,
http://weblog.infoworld.com/openresource/archives/2007/01/who_will_buy_su.html)
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.
--
Cheers,
Rick Moen "Anger makes dull men witty, but it keeps them poor."
rick at linuxmafia.com -- Elizabeth Tudor
More information about the License-discuss
mailing list