[TAG] License Question

[Rick Moen]

Quoting Martin (martin at marcher.name):

> according to your author FAQ[0] under "Copyright Issues" you state
> that you will publish the works sent to you under the Open Publication
> License. The Wikipedia article states that the author of the OPL
> recommends using a Creative Commons License as a replacement. 

Some of the CC licences are, in my view, well suited for _Linux Gazette's_ 
use but have no compelling advantages.  (As you may or may not know,
CC's licences are _highly_ diverse, including both highly proprietary
and free licences, and unfortunately the organisation makes very little
effort to disambiguate the two.)  Some of CC's licences are, in
contrast, entirely unsuitable.  The two proprietary CC licences that you
favour would be in the latter category.

David Wiley (creator of OPL 1.0 with help from Eric Raymond and Tim
O'Reilly) now deprecates OPL because he's not an attorney and because he
thinks the various CC licences will stand up better in court.  He also
mentions in passing Andrew M. St. Laurent's critique in an excerpt from
St. Laurent's O'Reilly book _Open Source and Free Software Licensing_,
at http://www.onlamp.com/pub/a/onlamp/2004/10/07/OSlicenses_part2.html .

Let's look at all of that.  I'm not an attorney, either, but I'm trained
in business law (in preparation for an early career in the accounting
and finance trade) and have about as much experience evaluating software
and documentation licences as anyone in the Linux community, including
many lawyers in that community.  For whatever it's worth, I think Wiley,
Raymand, and O'Reilly did pretty well in OPL 1.0, especially if one
leaves off Options A and B and all other options -- as does _LG_.

Mr. St. Laurent's beefs with OPL 1.0 are as follows:

1.  Any use of "License Options" can create problems.  Maybe, but irrelevant
to _LG's_ usage model, which eschews them.

2.  OPL's definition of "substantive modifications" in terms of whether
a change is sematic or not is, in St. Laurent's view, "dangerously
ambiguous".  Well, that's a matter of opinion, and I soundly differ from
Mr. St. Laurent on that point.  I'm perfectly happy to leave application
of that distinction up to a judge.  Unlike many computerists, I'm aware
of how many debatable distinctions are inherently part of law:  We trust
judges and juries to determine whether an action satisfies the
"reasonable man standard" and whether people who commit the "actus reus"
of a violent acts are accompanying that act with a culpatory "mens rea"
(mental state), i.e., intent to do wrong -- and we're supposed to worry 
about their ability to determine whether a change has semantic effect?

I'm willing to worry about global warming and international fiscal
policies; I don't have nearly enough worry left over for _that_.

(Anyway, all of that is part of one of the optional sections, and _LG_
doesn't use that.)

3.  Similarly, use of the option to control commercial republication
results in what St. Laurent calls further "ambiguities" -- but the
examples he then cites of such don't strike me as being ambiguities at
all.  What he discusses would be more properly termed the result of an
author using OPL with the discussed option without bothering to read it,
and thus failing to comprehend that it only controls _some_ types of
commercial re-use.

I see no actual problem, there, only St. Laurent calling lack of author
attention a problem.  And, again, _LG_ does not use that option in the
first place.

4.  St. Laurent complains that OPL's inclusion of "Policy Appendix" and
the "Good Practice Recommendations" might "confuse licensees".  Awww.  
Poor babies.  I'm really not impressed by that argument, either.

5.  St. Laurent complains that OPL doesn't address how to comply with
its requirement when publishing anthologies of OPL works, or when
dealing with works existing in multiple generations.  However, again, I
simply don't see a problem.  In particular, his claim that there's a
problem concerning anthologies is, to be blunt, nonsense.  He seems to
be saying that the scope of OPL coverage in multiple-work situations is
unclear.  Bollocks.  As anyone who's studied copyright law seriously
will tell you, it extends to the edge of _derivative works_ of the
original OPL-covered works -- that term being a legal term of art within
copyright law, and a long discussion in itself.

I've grown impatient with St. Laurent's writings ever since I bought a
copy in order to review it in comparison to Lawrence Rosen's book on the
same subject for BayLISA.  To my sharp disappointment, I was obliged to
politely pan St. Laurent's book:  It struck me as really shockingly
shoddy work.

Here's my review, which I'll gladly licence to the public under the
reader's choice of OPL 1.0 with no options or Creative Commons BY-SA
3.0.  ;->



 Date: Thu, 7 Apr 2005 20:50:41 -0700
 To: blw at baylisa.org
 Subject: Review
 X-Mas: Bah humbug.
 User-Agent: Mutt/1.5.6+20040907i

ISBN: 0-596-00581-4
O'Reilly and Associates
List Price: US $24.95


Andrew St. Laurent's 2004 volume "Understanding Open Source and Free
Software Licensing" is O'Reilly's attempt to fill a significant need for
good resources on this subject.  It joins OSI chief counsel Lawrence
Rosen's similar volume from Prentice Hall, "Open Source Licensing:
Software Freedom and Intellectual Property Law", published at nearly the
same time, and Rutgers School of Law professor Rod Dixon's hardcover
volume from Artech House/Horizon, "Open Source Software Law".

There's a vital need for such books because businesses have been dipping
their toes into open source for the past decade and immediately
stumbling over legal issues, both real and imaginary.  As a longtime
observer of the resulting fray, I've been longing for a good book on the
subject.

St. Laurent's comes within spitting distance of being that book.  As an
attorney with an interest in intellectual property law, he is able to
give a lucid run-through of about a dozen of the most common open source
licences, explaining what each clause means in detail, and contrasting
them with a typical proprietary-software licence, similarly scrutinised.
That part of the book, which comprises the book's middle 70%, will be
useful for people wondering how licences get their force, and how they
operate in our legal framework.Where the book falls down is in a couple
of places.  First and foremost, it lacks a coherent conceptual overview,
failing to clarify the default rights conveyed by unaided copyright law
and its provisions.  It takes for granted crucial concepts such as
"derivative work":  If work A is derivative of work B, then the second
work's owner's rights (and licensing) determine what can be done with
(encumber) the derivative.  The advantages of registering copyrights
(and consequences of not doing so), revocation of licences by the
licensor, collective works versus joint works, and many other details
important to licensing get no coverage at all.  St. Laurent also doesn't
mention at all a key aspect of licences, that the copyright holder
attaches them to instances of a codebase, such that different instances
may bear completely different terms of usage.

Some of the very common licensing controversies within the open source
community aren't addressed, either:  Is it necessary or desirable to
require a licensee to indicate assent, e.g., through a clickwrap
agreement mechanism?  (St. Laurent states without reservation that
clickwrap licences have been ruled enforceable, but the judicial record
on the matter is actually mixed.)  How extensive should the reach of
licences' patent-defence clauses (if any) be?  (Some licences revoke the
rights of users who bring any sort of patent action, regardless of the
dispute; others are limited in scope to just patent actions concerning
the licensed work.)  Is it possible to donate a work of original
ownership directly to the public domain, despite the lack of any legal
mechanism for doing so?  Is it desirable to have a choice-of-law
provision in one's licence?  Can you as the primary maintainer and
copyright holder of a collective-work project "upgrade" the project's
licence to a better one?  These are important questions, with which the
book simply won't help you.

I was disappointed that St. Laurent takes for granted that the GNU
General Public Licence and Lesser General Public Licence can be
evaluated only as contracts:  Their author, law professor Eben Moglen,
has clarified many times that both contracts are intended as rights
grants under copyright law only, and the licences themselves clearly so
state.   Thus, the question of their enforceability doesn't hinge on
contract formation -- but, even there, St. Laurent's coverage is
lacking:  Given that GPL and LGPL would be unilateral contracts without
any necessary obligation of payment by the licensee, how would the
necessary contract element of "valuable consideration" be found?  (Each
side in a contract must give up something of value; otherwise, there can
be no contract.)  A more-thorough treatment would have discussed that
issue and also the licences' intended status as "bare copyright
licences".

These flaws notwithstanding, the book does include excellent, reasonably
readable yet in-depth analysis of all primary open source licences in
use today, and I do strongly recommend it, to all interested audiences.



-- end review --

I personally _do_ think you have a reasonable point about _some_ of CC's
licences being good -- despite the two particular ones you cite being
just about the worst possible CC licences for _LG's_ purposes.  In my
view, CC BY-SA 3.0 would be a _slight_ improvement over OPL 1.0 sans
options -- but not enough of an improvement to justify switching.

Here's my rough taxonomy of current CC licences for OSI's benefit --
plus a follow-up for the sake of perspective:

 Date: Mon, 4 Aug 2008 20:47:28 -0700
 From: Rick Moen <rick at linuxmafia.com>
 To: license-discuss at opensource.org
 Subject: Re: Creative Commons

Quoting Raj Mathur (raju at linux-delhi.org):
> On Tuesday 05 Aug 2008, Somik Raha wrote:
> 
> > However, some contributions will be in the form of powerpoint
> > templates, and the Create Commons Attribution license seems to be
> > simple enough to allow for commercial and non-commercial usage,
> > while keeping it open. AFAIK, not all CC licenses are OSI-compliant,
> > and I could not find any CC licenses on the OSI list that have been
> > approved. Interestingly enough, OSI's homepage uses a CC license.
>
> The reason you don't find the CC licences on its web site is that OSI
> does not approve any licences other than software licences.  Being the
> Open Source Initiative, their mandate is (at least currently)
> restricted to the software domain.
>
> However, I don't see how you can go wrong using one of the CC
> licences, which are the de-facto standard for open document publishing
> and implicitly approved by the OSI by use.  Any OSI board member (I
> used to be one) would probably advise you to choose the CC licence
> that meets your needs and go ahead with it.

It should be bourne in mind that most of the CC licences are (by design)
proprietary.  That is, some of them intentionally do not grant the right
to create or distribute derivative works, and some of them intentionally
grant that right only for non-commercial re-use.

Applying the OSD as criterion, the current 3.0 licence revisions divide
like this, in my opinion:

Proprietary
-----------
Attribution-NoDerivs
Attribution-NonCommercial-NoDerivs
Attribution-NonCommercial
Attribution-NonCommercial-ShareAlike

Open source
-----------
Attribution
Attribution-ShareAlike

--
Cheers,               Chip Salzenberg: "Usenet is not a right."
Rick Moen            Edward Vielmetti: "Usenet is a right, a left, a jab,
rick at linuxmafia.com                     and a sharp uppercut to the jaw.
                                        The postman hits!  You have new mail."



 Date: Mon, 4 Aug 2008 23:07:00 -0700
 From: Rick Moen <rick at linuxmafia.com>
 To: license-discuss at opensource.org
 Subject: Re: Creative Commons

Quoting Raj Mathur (raju at linux-delhi.org):                                      

> OK, I stand corrected -- thanks for the insight, Rick.  On the other
> hand, I don't know how far we can go applying criteria for software to
> documents -- what you propose appears reasonable and intuitive, but
> I'd still advise caution when applying the OSD directly to
> document licences.

Very good point (and the original answer still pertains, that OSI simply
doesn't have non-software licensing within its bailiwick in the first
place).

Opinions on documentation licensing tend to be surprisingly contentious
(and I wasn't even particularly thinking of the Debian vs. GFDL affair);        
many commentators seem to forget about ways in which documentation tends
to differ fundamentally from software:

o  Getting access to the preferred form really isn't very difficult for
   a motivated re-user.  (We're not talking about contrived DRM/Kindle
   scenarios, but rather ordinary documentation -- but even those succumb
   to screen snapshots and OCR.)   At minimum, the full semantics of the        
   work are available to inspection, i.e., there's nothing like
   software's trait of obscuring through compilation.
o  In part because of the above fact, there's very little barrier to
   creation of a new, equivalent work if an existing one's terms of usage       
   become a problem.                                                            
o  The desire to create a new document as a derivative work borrowing part      
   of an existing document is relatively rarely felt.  (The desire to           
   update an existing poorly maintained document occasionally does arise.)      
o  For various reasons of real-world perception, authors are often              
   concerned that modified variants of their work will make them appear to
   have said something they didn't.  Software people tend to assume that
   this is no more of a problem than it is in software, and yet they are
   not correct.

It's often claimed that documentation's licensing must be compatible            
with (if not the same as) that of the software it concerns, e.g., for           
example code included in the docs -- but that's a pretty contrived
scenario, in my view.                                                           

But, to stress again, all of this is outside OSI's ambit.