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

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

Quoting Christiaan Erasmus (christiaan@...):

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

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

[Rick Moen]

Correcting my recent post:

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

My apologies for forgetting that Lawrence Rosen's excellent "Open
Software License (OSL) v. 1.1 _also_ has language addressing ASP scenarios,
and likewise is already OSI-certified
(http://www.opensource.org/licenses/osl.php).

It grants rights for performance and display (clause 1) of the upstream
work.  Clause 5 requires licensee to stipulate that any "external use"
(use or distribution so that the work is accessible to others) by
licensee qualifies as "distribution" of the software for purposes of the
licence, tying clause 1c's copyleft obligation to such usage.

--
Cheers,                Emacs is a good operating system, but I prefer Linux.
Rick Moen
rick@...

[Brian Behlendorf]

On Mon, 5 Mar 2007, Rick Moen wrote:
> Date: Mon, 5 Mar 2007 18:29:49 -0800
> From: Rick Moen <rick@...>
> To: Christiaan Erasmus <christiaan@...>
> Subject: Re: (forw) Re: Report 5
>
> Quoting Christiaan Erasmus (christiaan@...):
>
[...]
>> 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.

Also, the Open Software License has an "External Deployment" clause.

  Brian

[Brian Behlendorf]

On Mon, 5 Mar 2007, Brian Behlendorf wrote:
> Also, the Open Software License has an "External Deployment" clause.

Gah!  Sorry, missed your update before sending this.

  Brian

[Andrew C. Oliver-2]

Rick Moen wrote:

>
> My apologies for forgetting that Lawrence Rosen's excellent "Open
> Software License (OSL) v. 1.1 _also_ has language addressing ASP scenarios,
> and likewise is already OSI-certified
> (http://www.opensource.org/licenses/osl.php).
>
> It grants rights for performance and display (clause 1) of the upstream
> work.  Clause 5 requires licensee to stipulate that any "external use"
> (use or distribution so that the work is accessible to others) by
> licensee qualifies as "distribution" of the software for purposes of the
> licence, tying clause 1c's copyleft obligation to such usage.
>
>  

Which is great.  We need more "IP theft" in open source, such clauses just
make sure that "IP theft" is bidirectional. :-)

-Andy
Habitual open source IP Theft perpetrator/victim

--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Matthew Flaschen]

Rick Moen wrote:
> Comments on things I might be overlooking are welcomed.

I'm a bit confused.

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

It appears version 1.1.2 of SPL (the version governing the code vTiger
forked)  does not have these problems, as it only denies the right to
use SugarCRM trademarks, and does not require logos be displayed.  It's
still not a OSI-approved license, but it probably could be.

I think it is only 1.1.3 and later that has such problems.  Is that correct?

> 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

However, that's a bit irrelevant, since vTiger *is* distributing.

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

Perhaps they thought 1.1.3 applied retroactively to all code.  It seems
clear that version would block what vTiger is doing.

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

Again, I don't think 1.1.2 has OSD #10 violations

>
> "IP theft" _would_ be if vTiger had violated SugarCRM's copyright property
> rights in any way whatsoever.

Copyright law doesn't recognize intellectual property rights of any
sort, nor does it consider copyright infringement theft.

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

Is there really a 1.1.4?  http://www.sugarcrm.com/crm/SPL is still
showing 1.1.3.

> Users never see the original BSD coders' copyright notices
> concerning the derivative works, because Microsoft doesn't publish the
> matching source code

The BSD notice is still supposed to be in the documentation somewhere
("disclaimer in the documentation and/or other materials provided with
the distribution.").  See e.g. http://support.microsoft.com/kb/306819
for such a notice.  It's true that this requirement isn't always
satisfied by redistributors.

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

That is pretty close to the GPL, which says, "If the modified program
normally reads commands interactively when run, you must cause it, when
started running for such interactive use in the most ordinary way, to
print or display an announcement including an appropriate copyright notice"

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

I think they are attempting to block reuse, and that they are doing so
deliberately.

Matt Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> It appears version 1.1.2 of SPL (the version governing the code vTiger
> forked)  does not have these problems....
> Is there really a 1.1.4?  http://www.sugarcrm.com/crm/SPL is still
> showing 1.1.3.

That part (only) was from my (seemingly) inaccurate recollection of my
reading the older licence terms, which reading was around two months ago.
Sometimes, you take a chance on memory and miss.  Sorry about that.

> > "IP theft" _would_ be if vTiger had violated SugarCRM's copyright property
> > rights in any way whatsoever.
>
> Copyright law doesn't recognize intellectual property rights of any
> sort....

Is the word "ownership" in 17 U.S.C. 201-205 unclear?  (Perhaps I should
let it pass, as this digression is fundamentally irrelevant to the
topic, but really, Matthew.)

> [...] nor does it consider copyright infringement theft.

Obvious John Roberts theatrics.  Not otherwise worthy of comment, really.


> The BSD notice is still supposed to be in the documentation somewhere
> ("disclaimer in the documentation and/or other materials provided with
> the distribution.").

_If any_ such documentation and other materials, yes, there must be
something buried therein.  But this quibble doesn't really affect my point.


[SugarCRM being surprised, indignant, etc., at vTiger fork reflecting,
IMVAO, the former's ineptitude:]

> I think they are attempting to block reuse, and that they are doing so
> deliberately.

I was trying to be, I guess, charitable:  My experience is that
businesses' evolving software licence strategies are often primarily
reactive, and seldom well thought out.

It may seem strange to envision a firm literally not realising that its
licence permits commercial forks, but I can definitely see the
possibility.

--
Cheers,            
Rick Moen                 "Anger makes dull men witty, but it keeps them poor."
rick@...                                   -- Elizabeth Tudor

[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@...>
To: license-discuss@...
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@...> -----
>
> Date: Mon, 5 Mar 2007 18:29:49 -0800
> From: Rick Moen <rick@...>
> To: Christiaan Erasmus <christiaan@...>
> Subject: Re: (forw) Re: Report 5
>
> Quoting Christiaan Erasmus (christiaan@...):
>
>> 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@...
>
> ----- End forwarded message -----

--
Kind regards

Christiaan Erasmus

[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@...]
Sent: Tuesday, March 06, 2007 6:06 AM
To: license-discuss@...
Cc: rick@...
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@...>
To: license-discuss@...
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@...> -----
>
> Date: Mon, 5 Mar 2007 18:29:49 -0800
> From: Rick Moen <rick@...>
> To: Christiaan Erasmus <christiaan@...>
> Subject: Re: (forw) Re: Report 5
>
> Quoting Christiaan Erasmus (christiaan@...):
>
>> 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@...
>
> ----- End forwarded message -----

--
Kind regards

Christiaan Erasmus

[Rick Moen]

Quoting Christiaan Erasmus (christiaan@...):

> 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@...                                   -- Elizabeth Tudor

[Matthew Flaschen]

Rick Moen wrote:

> Quoting Matthew Flaschen (matthew.flaschen@...):
>
>> It appears version 1.1.2 of SPL (the version governing the code vTiger
>> forked)  does not have these problems....
>> Is there really a 1.1.4?  http://www.sugarcrm.com/crm/SPL is still
>> showing 1.1.3.
>
> That part (only) was from my (seemingly) inaccurate recollection of my
> reading the older licence terms, which reading was around two months ago.
> Sometimes, you take a chance on memory and miss.  Sorry about that.

No problem.  I didn't know about that version before either.
>
>>> "IP theft" _would_ be if vTiger had violated SugarCRM's copyright property
>>> rights in any way whatsoever.
>> Copyright law doesn't recognize intellectual property rights of any
>> sort....
>
> Is the word "ownership" in 17 U.S.C. 201-205 unclear?  (Perhaps I should
> let it pass, as this digression is fundamentally irrelevant to the
> topic, but really, Matthew.)

Point taken (I forgot they used that phrase), but ownership of a limited
term copyright is not the same as owning an idea.  I consider this an
important, though subtle, distinction.  The law doesn't say
"intellectual property" or "piracy"; this is invented rhetoric.

> [SugarCRM being surprised, indignant, etc., at vTiger fork reflecting,
> IMVAO, the former's ineptitude:]
>
>> I think they are attempting to block reuse, and that they are doing so
>> deliberately.
>
> I was trying to be, I guess, charitable:  My experience is that
> businesses' evolving software licence strategies are often primarily
> reactive, and seldom well thought out.

I'm willing to charitable, but this seems pretty blatant.  I think these
licenses are well-(or at least long) considered, but not by the right
people.

Matthew Flaschen

[Timothy McIntyre]

These are interesting points.  Earlier in this thread, there was mention that licensees who use "MPL + attribution" -style licenses have overlooked the so-called 'ASP loophole.'  I work for Terracotta, and we distribute our software under the Terracotta Public License, which is MPL w/ attribution (i.e., redistributed software must contain 'Powered by Terracotta' text in any UI).  When we were deciding on our license, we wanted to address the ASP loophole, so we ended up revising the original language of the MPL.  Wherever software distribution is mentioned in the license, we added the phrase "or otherwise makes available," in order to cover passive types of distribution, such as with ASPs.  This modification to the MPL also appears in the CDDL.


Rick Moen wrote:

Correcting my recent post:

  

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.
    

My apologies for forgetting that Lawrence Rosen's excellent "Open
Software License (OSL) v. 1.1 _also_ has language addressing ASP scenarios, 
and likewise is already OSI-certified
(http://www.opensource.org/licenses/osl.php).

It grants rights for performance and display (clause 1) of the upstream
work.  Clause 5 requires licensee to stipulate that any "external use"
(use or distribution so that the work is accessible to others) by
licensee qualifies as "distribution" of the software for purposes of the
licence, tying clause 1c's copyleft obligation to such usage.

  

[Matthew Flaschen]

Timothy McIntyre wrote:

> When we were deciding on our license,
> we wanted to address the ASP loophole, so we ended up revising the
> original language of the MPL.  Wherever software distribution is
> mentioned in the license, we added the phrase "or otherwise makes
> available," in order to cover passive types of distribution, such as
> with ASPs.  This modification to the MPL also appears in the CDDL.

The relevant clause is:

"ANY COVERED CODE THAT YOU DISTRIBUTE OR OTHERWISE MAKE AVAILABLE IS
GOVERNED BY THE TERMS OF THIS LICENSE, INCLUDING WITHOUT LIMITATION
SECTION 2.2. THE SOURCE CODE VERSION OF COVERED CODE MAY BE DISTRIBUTED
ONLY UNDER THE TERMS OF THIS LICENSE"

I think "otherwise make available" is just supposed to mean putting on a
 server for *download* or similar.  I've never heard of someone using
CDDL to require code distribution in an ASP situation.  However, the
CDDL clause is slightly different:

"Any Covered Software that You distribute or otherwise make available in
Executable form must also be made available in Source Code form and that
Source Code form must be distributed only under the terms of this License."

The extra "Executable form" may change things, but I don't think so.

Matt Flaschen

>
>
> Rick Moen wrote:
>> Correcting my recent post:
>>
>>  
>>>> 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.
>>>    
>>
>> My apologies for forgetting that Lawrence Rosen's excellent "Open
>> Software License (OSL) v. 1.1 _also_ has language addressing ASP
>> scenarios, and likewise is already OSI-certified
>> (http://www.opensource.org/licenses/osl.php).
>>
>> It grants rights for performance and display (clause 1) of the upstream
>> work.  Clause 5 requires licensee to stipulate that any "external use"
>> (use or distribution so that the work is accessible to others) by
>> licensee qualifies as "distribution" of the software for purposes of the
>> licence, tying clause 1c's copyleft obligation to such usage.
>>
>>  
>
>

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> Point taken (I forgot they used that phrase), but ownership of a limited
> term copyright is not the same as owning an idea.  I consider this an
> important, though subtle, distinction.  The law doesn't say
> "intellectual property" or "piracy"; this is invented rhetoric.

Reminder:  My exact phrase was "copyright property rights".  I.e., I
did not use either of those terms to which you object, nor did I speak
of owning an "idea".  So, I'm guessing you were having flashbacks to
other debates entirely.  Too much LDS in the 60s?  ;->


[Is impairing of commercial reuse accidental or not??]

> I'm willing to charitable, but this seems pretty blatant.  I think these
> licenses are well-(or at least long) considered, but not by the right
> people.

Speaking in a spirit of charity is, in my experience, useful regardless
of what one thinks -- where feasible.  It elevates the tone of
discussion, and averts otherwise-obligatory trotting out of everyone's
good intentions, thereby letting you move on and deal with facts that
matter.

--
Cheers,                   Now, it's time to hack the real world, and let other
Rick Moen                 people write Web sites about it.
rick@...                                   -- Donald B. Marti

[Lawrence Rosen]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Timothy McIntyre wrote:

Wherever software distribution is mentioned in the license, we added the phrase "or otherwise makes available," in order to cover passive types of distribution, such as with ASPs.  This modification to the MPL also appears in the CDDL.

 

I'm curious why you believe that the phrase "or otherwise makes available" is sufficient to plug the ASP loophole and to require that the source code of internal modifications of licensed software must be disclosed simply because the software is accessed over a network? Is that phrase clearly defined in the CDDL? Or is there some commonly understood meaning that is found in legal authorities? Your interpretation may be surprising to Sun (who owns the CDDL) and its customers, who probably do not expect that CDDL-licensed software is subject to an ASP provision. Perhaps one of Sun's attorneys here can clear this up.

 

There is already before the courts a case dealing with the meaning of "distribution" in the context of music downloads. I found the following article by Ray Beckerman informative: "Is 'Making Available' Copyright Infringement?" http://www.hollywoodreporteresq.com/thresq/spotlight/article_display.jsp?vnu_content_id=1003535810. I'm not sure how relevant this point is, but it may be that your interpretation of the phrase comes closer to the RIAA position than that of EFF, which would be unusual for open source. Perhaps it would avoid confusion if the CDDL and similar licenses defined what they mean by "otherwise makes available" and not leave it to interpretation.

 

That is why OSL 3.0 is explicit:

 

5) External Deployment. The term "External Deployment" means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

 

/Larry Rosen

 

---

From: Timothy McIntyre [mailto:tmcintyre@...]
Sent: Tuesday, March 06, 2007 5:52 PM
To: Rick Moen
Cc: license-discuss@...
Subject: Re: Followup on Exhibit B licences

 

These are interesting points.  Earlier in this thread, there was mention that licensees who use "MPL + attribution" -style licenses have overlooked the so-called 'ASP loophole.'  I work for Terracotta, and we distribute our software under the Terracotta Public License, which is MPL w/ attribution (i.e., redistributed software must contain 'Powered by Terracotta' text in any UI).  When we were deciding on our license, we wanted to address the ASP loophole, so we ended up revising the original language of the MPL.  Wherever software distribution is mentioned in the license, we added the phrase "or otherwise makes available," in order to cover passive types of distribution, such as with ASPs.  This modification to the MPL also appears in the CDDL.


Rick Moen wrote:

Correcting my recent post:

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.

My apologies for forgetting that Lawrence Rosen's excellent "Open

Software License (OSL) v. 1.1 _also_ has language addressing ASP scenarios, 

and likewise is already OSI-certified

(http://www.opensource.org/licenses/osl.php).

It grants rights for performance and display (clause 1) of the upstream

work.  Clause 5 requires licensee to stipulate that any "external use"

(use or distribution so that the work is accessible to others) by

licensee qualifies as "distribution" of the software for purposes of the

licence, tying clause 1c's copyleft obligation to such usage.

-- 

____________________________________________________

Timothy McIntyre // Corporate Counsel

Terracotta // Open Source Clustering for Java

web: www.terracotta.org

tel: [phone]

fax: [phone]

This email incorporates Terracotta's confidentiality policy, which is online at http://www.terracottatech.com/emailconfidentiality.shtml

[Richard Fontana]

Lawrence Rosen wrote:

> Timothy McIntyre wrote:
>
> Wherever software distribution is mentioned in the license, we added the
> phrase "or otherwise makes available," in order to cover passive types of
> distribution, such as with ASPs.  This modification to the MPL also appears
> in the CDDL.
>
>  
>
> I'm curious why you believe that the phrase "or otherwise makes available"
> is sufficient to plug the ASP loophole and to require that the source code
> of internal modifications of licensed software must be disclosed simply
> because the software is accessed over a network? Is that phrase clearly
> defined in the CDDL? Or is there some commonly understood meaning that is
> found in legal authorities?

Indeed, I would take "making available" in any such licenses to have the
meaning it has in the 1996 WIPO copyright treaty, which is approximately
the right of distribution of copies under US copyright law:

Article 6
Right of Distribution

(1) Authors of literary and artistic works shall enjoy the exclusive right
of authorizing the making available to the public of the original and
copies of their works through sale or other transfer of ownership.

[John Cowan]

Rick Moen scripsit:

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

I think this is an over-interpretation on your part.  In general,
if X compels Y to do Z, X is estopped from also enjoining Y from
doing Z, particularly in the same breath lik this.  In effect,
the requirement to use the trademarks is tantamount to a limited
license to use them.

Furthermore, there is an analogue of fair use for trademarks.
I can speak of drinking Coke, and a novelist can say that his
protagonist drives a Ford, without stepping on trademarks.

And as for intention, "the devil himself knoweth not the mind of man"
(Blackstone).  Legal intent must be judged by objective evidence.

--
John Cowan    http://ccil.org/~cowan  cowan@...
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker

[Rick Moen]

Quoting John Cowan (cowan@...):

> Rick Moen scripsit:
>
> > 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.  
>
> I think this is an over-interpretation on your part.  In general,
> if X compels Y to do Z, X is estopped from also enjoining Y from
> doing Z, particularly in the same breath lik this.  In effect,
> the requirement to use the trademarks is tantamount to a limited
> license to use them.

Oh, I concur, that in the event of dispute it would likely come down
that way -- depending, of course, on particulars.  Until then, at the
bare minimum there is a chilling effect that one cannot help suspecting
is intentional -- and deliberate imposition onto third-party reusers of
the burden of verifying that they have simultaneously used the marks as
required and avoided creating the impression, through their use of those
marks, that the original developer produced or endorsed their competing
product or service.

You may recall that Lawrence Rosen had some further shrewd thoughts on
this matter:  that the trademarked-logo requirement, as stated, might
well endanger the licensors' trademarks, in any subsequent infringement
actions.

> Furthermore, there is an analogue of fair use for trademarks.
> I can speak of drinking Coke, and a novelist can say that his
> protagonist drives a Ford, without stepping on trademarks.

I'm well aware of what does and doesn't constitute trademark
infringement in commercial use.  Ditto the tort of dilution.  Ditto
disparagement/tarnishment.  (I really do need to finish the article on
trademark law, too.)

> And as for intention, "the devil himself knoweth not the mind of man"
> (Blackstone).  Legal intent must be judged by objective evidence.

I spoke _not_ of intention, in that particular.  I said merely that it
impairs commercial reuse.

It is sometimes useful to speculate on what someone's intentions are,
as it may help find where the bodies are buried, but those would be
ultimately the booby prize where judging OSD-compliance is concerned.
(As I've said before, code and licensing, licensing and code.)

--
Cheers,
Rick Moen                                    Frater Magnus vos spectat.
rick@...

[Lawrence Rosen]

John Cowan wrote:
> I think this is an over-interpretation on your part.  In general,
> if X compels Y to do Z, X is estopped from also enjoining Y from
> doing Z, particularly in the same breath lik this.  In effect,
> the requirement to use the trademarks is tantamount to a limited
> license to use them.

Whether it is an explicit or an implicit trademark license, this results in
a very different legal problem. A trademark license that doesn't give the
licensor control over the quality of the downstream goods bearing that
trademark leads to loss of the trademark. Yet with open source, the licensor
cannot control the quality of derivative works. Oops! Legal contradiction!

An open source license cannot (should not!) contain a trademark license.

/Larry Rosen

> -----Original Message-----
> From: John Cowan [mailto:cowan@...]
> Sent: Tuesday, March 06, 2007 8:03 PM
> To: Rick Moen
> Cc: license-discuss@...
> Subject: Re: Followup on Exhibit B licences
>
> Rick Moen scripsit:
>
> > 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.
>
> I think this is an over-interpretation on your part.  In general,
> if X compels Y to do Z, X is estopped from also enjoining Y from
> doing Z, particularly in the same breath lik this.  In effect,
> the requirement to use the trademarks is tantamount to a limited
> license to use them.
>
> Furthermore, there is an analogue of fair use for trademarks.
> I can speak of drinking Coke, and a novelist can say that his
> protagonist drives a Ford, without stepping on trademarks.
>
> And as for intention, "the devil himself knoweth not the mind of man"
> (Blackstone).  Legal intent must be judged by objective evidence.
>
> --
> John Cowan    http://ccil.org/~cowan  cowan@...
> 'Tis the Linux rebellion / Let coders take their place,
> The Linux-nationale / Shall Microsoft outpace,
> We can write better programs / Our CPUs won't stall,
> So raise the penguin banner of / The Linux-nationale.  --Greg Baker

[Rick Moen]

Quoting Lawrence Rosen (lrosen@...):

> An open source license cannot (should not!) contain a trademark license.

A possible compare-and-contrast item:  A gentleman named Larry Ozeran
wrote to me, this evening, to ask my view of the Medsphere Public
Licence (http://medsphere.org/license/MSPL.html) -- which task I
approached with no enthusiasm, because I expected it would be more of
the same.  It wasn't.

Quoting Larry Ozeran (lozeran@...):

[...]

> My question to you: is the "MSPL" license (apparently a form of
> badgeware) which they are requiring a valid open source license? Is
> there such a thing as "valid" or is the better distinction OSI
> compliant license vs. not?

[...]

I find myself pleasantly surprised and impressed by Medsphere Public
License (MSPL) Version 1.0.  Having encountered a number of other MPL
1.1 + "Exhibit B" licences, I expected the same sort of meddlesome
overreaching exemplified by the originator of such licences, SugarCRM,
Inc.  Medsphere Systems Corporation didn't do that.

MPSL's Exhibit B is a reasonable, minimal, well-worded provision
intended to ensure that the original developer (in this case,
Medsphere) continues to have publicly verifiable author credit that can
be read at runtime by all users, even on derivative works deployed
ASP-style with no distribution of source code to anyone.  The ASP
market is a challenging one for would-be publishers of open source code
in this regard, in that -- if using a conventional copyleft or
simple-permissive open-source licence -- competitors can fully reuse
your works in their derivative work without either giving back their
changes nor leaving signs of your authorship visible to users.

Other Exhibit B sections I've seen very definitely violate OSD#10
(the requirement for technological neutrality).  MSPL carefully avoids
that pitfall by saying the splash-screen credit must appear on the
graphical user interface screen _if any_.  

Again, in sharp contrast to other Exhibit B licences, MSPL doesn't
require credit on "every user interface screen", but rather speaks of a
splash screen (only) displayed "for sufficient duration to give
reasonable notice to the user of the identity of the Initial Developer"
-- with escapes to cover technology variations (e.g., no graphical
display) or if for various other reasons the requirement is
inapplicable.

Likewise as a very pleasant surprise, the MSPL's Exhibit B is worded in
a templated fashion, so that the licence can be reused for other works.

Last, the trademark clause, so excessive and problematic in other
Exhibit B examples, is perfectly reasonable:  Licensee acknowledges
licensor's trademark title, and says that using them requires either
owner's permission _or_ any other entitlement created by law or by the
terms of the licence.

I find all of the above refreshingly reasonable.  The question you
asked is:  In my opinion, is it open source?

At the risk of being guilty of quibbling, a two-part answer:  (1)
Traditionally, restrictions on usage are seen as being inherently not
permissible in open source.  All restrictions.  This is seen as being
implied in a number of the Open Source Definition's provisions (e.g., #3
on derivative works, #6 on fields of endeavour, and #10 on technological
neutrality), even though it hasn't been called out as an explicit
prohibition in stark terms.  Strictly speaking, the requirement of a
splash screen in the graphical disply _if any_ is a restriction on use.

(2)  However, that restriction is of such a fleeting, minimal, and
reasonable nature that I think it should not raise objection.

The above is based on about an hour (only) of study and comparison --
and I have certainly made mistakes in such matters before.  However, I
am reasonably confident in my view.

Fair disclosure:  I was once employed at a firm then headed by Medsphere
former CEO and current Board member Larry Augustin, and knew him
personally for many years before that.  I esteem Mr. Augustin highly,
but hope and believe that my view of him personally has not coloured my
assessment of his firm's licence.

--
Cheers,                                      "Reality is not optional."
Rick Moen                                             -- Thomas Sowell
rick@...