APL license - What about the enforced logos?

[Matt Asay]

David:

A few comments (below).  (Incidentally, I'm part of Alfresco, so obviously
have bias on this, but wanted to make sure the company's voice was heard on
this, now that license-discuss is going into intentions....)


> From: David Woolley <david at djwhome.demon.co.uk>
> Date: Sun, 12 Nov 2006 20:03:55 +0000 (GMT)
> To: <license-discuss at opensource.org>
> Subject: Re: APL license - What about the enforced logos?
> 
> What I believe the intended purpose of this licence is would be something
> like this.
> 
>   We are providing this software as a loss leader to promote our
>   commercial offerings (much as Lite versions of concealed source
>   programs are distributed free of charge and with redistribution
>   allowed, and like Wordpad is a loss leader for Microsoft Office).
> 
>   As such, we intend that it be used in a way that it is always
>   recognizable as being a version of our software and makes it very
>   easy for the user to go to our web site where we can try to sell them
>   our commercial product and services.
> 
MNA:  Well, no.  One two levels.  First off, I think it's a bad idea to try
to read into a license's intentions - any license.  A law/license should be
read on its face.  If you start to extrapolate from a license's/law's
intentions, there's no telling where you'll end up (for better or for worse
- if you look at how judges in the US read into laws, you'll get a taste for
just how far "intentions" can take you from the actual text of a law).

In the case of Alfresco, the intention (to me) is very clear:  our Community
and Enterprise versions are LINE FOR LINE EQUIVALENT, with the exception of
the attribution requirement.  Hence, there is no "loss leader" or anything
of the kind.  Instead, we are saying, "If you modify this Community code -
and you have **every** right to do so, we want you to do so knowing that
you, and only you, are responsible for the results.  Don't come complaining
to us if you break the software.

> On this interpretation, a text only version might not be considered
> sufficiently recognizable as the product to effectively advertise it and
> extracting code and using it in an application without a user interface
> might be considered as providing no benefit at all to the licensor.

MNA:  Partly  correct.  Because this is an application with a UI, and
because users, not the administrators, are likely going to be the first ones
complaining if something goes wrong, it makes no sense to bury the
disclaimer in the text accompanying the code *because the end user will
never have the opportunity to see it."

This, in fact, is the big reason that this kind of "public" attribution is
used for end-user applications (Zimbra, SugarCRM, SocialText, etc.), and not
more engineer-oriented software (MySQL, Jboss, and other infrastructure
software).  In the case of applications, it is the end user that cares most
about the user experience.  Attribution simply tells them who to blame
(their IT people) if the software fails because it's been modified, or
because it's unmodified but hasn't come with support of any kind.
> 
> The drafting isn't tight enough to prevent the code being repurposed to
> a large extent, but, in my view, when interpreting the licence in an
> edge case, one needs to take into account whether the interpretation is
> in line with their real intention in distributing the code, and I believe
> that the above is close to what those intentions were.
> 
> I've coined the term "concealed source" to represent the normal binary
> only, may not reverse engineer, case, and distinguish it from both
> "open source" and source provided but OSD non-compliant.

MNA:  I don't think "concealed" is an apt term.  No code is "concealed" with
Red Hat Enterprise Linux, Alfresco, or any other software like this.
Instead, RHEL, Alfresco, etc. simply require a "closed" binary (not really
closed, but perhaps effectively so because if you modify the binary you
violate your support agreement) because it's the only way to provide quality
of service.  If I allow someone to modify the source code of my Enterprise
product, I have *no way* of knowing how best to support them when they call.
At that point we spend minutes to, more likely, hours figuring out what
they've changed and how it has affected the system (probably requiring us to
rebuild our own test system with their modifications) so that we can answer
a simple support question.

Even so, Alfresco goes a step beyond most commercial open source companies
in that we provide the option of developer support.  This allows them to
modify source with our help (basically just means that we need to know what
they're doing so that we can guide them a little in how best to do it), and
we'll assist them when they have problems.