[Coin-discuss] Open-source Modeling Languages

[Lou Hafer]

Folks,

	I've mentioned a couple of times in the past, and will mention again,
that there's an excellent open-source book on open-source licenses,
Open Source Licensing: Software Freedom and Intellectual Property Law,
written by Lawrence Rosen.

Available online at http://www.rosenlaw.com/oslbook.htm

Since these discussions always seem to meander off into `I'm not a lawyer,
but here's my understanding of ...', here's my summary of the analysis of
someone who is a lawyer.

Don't take my word for it! Take a moment and read for yourself.

This book was published in 2004, hence GPL v3 never comes into the discussion.

(Chap. 2) Open source licenses can be divided into four categories:

  * academic licenses: originally created by academic institutions to
    distribute software to the public; allow use for any purpose; no
    reciprocal obligation to distribute source of derivative works (e.g., BSD
    license)

  * reciprocal licenses: allow use for any purpose; require distribution of
    derivative works under the same license (which includes distribution of
    source of derivative works)

  * standards licenses: designed to ensure availability of industry standard
    software and documentation for implementation of standard products.
    Sometimes require that differences from industry standard be published as
    a reference implementation as a means of evolving the standard.

  * content licenses: ensure that copyrightable subject matter (other than
    software) be available for any purpose (e.g., creative commons)

Rosen makes this point: Courts do not deal with the intent or ethical beliefs
of the creators of a license, only what is written in the license.

GPL and CPL are both reciprocal licenses.

(Chap. 6) GPL reciprocity terms for a derivative work, summarised:

You must distribute object code or source under the GPL. If you distribute as
object code, you must tell the licensee how to obtain source for the
derivative work, in a reasonable manner.

How can you evade the reciprocity requirement?

  * GPL requires reciprocity for derivative works (a term of art in copyright
    law, decided in court) and (in one place) attempts to extend it to
    something that looks like collective work (another term of art in
    copyright law), and (in another place) specifically exempts `mere
    collections'. There's an ambiguous middle ground of software that just
    uses some piece of GPL code.

  * One could infer, from the existence of the LGPL, that the GPL is attempting
    to extend itself to software that just uses some piece of GPL'd code. Put
    another way, if your package won't function without the GPL'd code, it's a
    derivative work, even if it just links to the code. [Disclaimer: This
    paragraph is primarily my interpretation, but seems to me to capture some
    of the distinction in copyright law between derivative and collective
    work.]

One of the big problems with GPL is that it gets really ambiguous when it comes
to patent grants.  In general, this seems to be the biggest difference between
GPL and CPL.  Not the terms of reciprocity, which are not all that different
unless your goal is to determine the degree to which you can violate the spirit
of the license without violating the letter of the license.  Rather, the
differences lie with ambiguities in the GPL that are (mostly) dealt with in CPL.


(Chap. 8) CPL reciprocity terms for a derivative work, summarised:

If you choose to distribute your derivative work as object code, you can do
that under your own license, but your license must comply with the CPL, and
must tell the licensee how to obtain source for the derivative work, in a
reasonable manner. If you distribute your derivative work as source code, the
source must be licensed under the CPL.

Which, if you think about it, means that you have to license the source for
your derivative work under the CPL.

How can you evade the reciprocity requirement?

  * Your contribution must be a separate module of software (not defined in
    CPL, left as a software term of art to be decided by courts)

  * Your contribution must not be a derivative work (not defined in CPL, left
    as a copyright law term of art)

Rosen says ``I'm sure most readers of this book will find the concept of a
separate module of software fairly self-evident and will know what steps to
take to ensure that engineers avoid creating Contributions that are subject
to reciprocity.'' Given some of litigation to date (Microsoft and Internet
Explorer come to mind), I'm not so confident that this will be obvious in
court.


And from Chapter 10, Choosing an Open Source License:

  ``If a reciprocal license is desirable, you should consider the scope of
    the reciprocity obligation.  Licenses like the GPL contain vague
    provisions about derivative and collective works; some licensors prefer
    that ambiguity because it results in more software licensee contributions
    licensed under the GPL. Licenses like the MPL have a more narrow
    definition of derivative works, requiring only files that are changed to
    be distributed under the MPL; this can reduce resistance from licensees
    who want to retain the proprietary status of their own contributions. For
    a more balanced approach, the CPL or OSL leave the term derivative works
    to be defined by the courts under copyright law.''

					Lou