For Approval: Microsoft Permissive License
Eugene Wee
eugenew at starhub.net.sg
Sun Sep 9 11:21:51 UTC 2007
Hi David,
David Woolley wrote:
> Rick Moen wrote:
>> I contest your premise, and point you to Catherine and Eric Raymond's
>> explanation about why this widely held view is incorrect:
>> http://catb.org/~esr/Licensing-HOWTO.html#id2852366
>>
> bash-3.2$ nslookup www.catb.org
> ;; connection timed out; no servers could be reached
>
> whois indicates that it is a personal web site (organisation: private).
It is a personal web site, namely that of Eric Raymond, who was
president of the OSI at the time of writing (2002-11-09) of the article
linked.
Since you appear unable to access that web site, this is the abstract
and the relevant part of the article:
-----------------------------------------------------------------------
*** Abstract ***
This is a DRAFT of an OSI working paper. It has not yet been formally
approved by OSI's board, though OSI and its legal counsel have approved
the direction of the work.
This document explains how U.S. copyright and licensing law applies to
open-source software projects. It compares the strengths and weaknesses
of the existing open-source licenses, and gives guidance on how to
choose a license for your project. It also explains the legalities of
changing a project's license. It suggests new practice for coping with
today's high-threat legal environment — this part is a must-read for all
project leaders.
*** If no other copyright holder could be harmed by the change ***
First, suppose you are a holder of a registered copyright on a project's
code. The project lead changes the license. What are your options?
To have a legal cause of action against the project lead for changing
the project license, you would have to demonstrate both as a matter of
law that you had the right to block the license change (e.g. a valid
copyright), and that the license change actually did an injury to your
interest. Where there is no injury there is no cause of action. (This
rule is applied everywhere in law, not just in copyright law.)
The strongest possible interest you as a copyright holder can have in an
open-source project is to continue to see it continue to be distributed
with the same grant of rights to licensees that obtained at time of
contribution, and with no more legal risk to yourself than existed at
time of contribution. Your interest might be less specific — for
example, many contributors are indifferent to specific license terms as
long as the license is open-source — but for purposes of figuring
potential injury we will reason about the strict criterion.
Under that criterion, it is harmless to change from one license to
another if doing so merely adds mutual protections for licensors or
licensees (things like an explicit rather than implicit patent grant)
without actually changing the grant of rights. It's also safe to change
clauses that are informational, such as warnings about export
regulations. In software terms, a license change that fixes
implementation details without changing the output cannot be a cause of
action. Neither holders of registered nor unregistered copyright would
have standing to object.
In practical terms, this means that some license upgrades are legally
safe. MIT to BSD, for example: the only change is a no-endorsement
clause that merely affirms that the grantor is not lifting restrictions
that were already present in trademark law. BSD or ASL to AFL; for legal
purposes, AFL is a cleaned-up expression of the rights grant implied in
traditional academic licenses. GPL to OSL for standalone programs
(differing interpretations of whether linkage creates derivation make
the case unclear for libraries).
Note, however, that an `upgrade' from a copyleft license to a
non-copyleft license (or vice-versa) would be a different matter. If you
are a GPL partisan, you would be injured by a move to a non-GPL license,
and vice-versa. These changes are not safe and could be causes of legal
action for copyright infringement by a holder of registered copyright
(who therefore does not have to meet the actual-damages test). Holders
of unregistered copyright would have no standung except by registering
the copyright after the fact of infringement, and then would have to
meet the difficult actual-damages standard.
Thus, the `no harm, no foul' rule does mean that project leaders do have
the discretion to make technical upgrades of licenses without having to
secure the explicit consent of all copyright holders.
-----------------------------------------------------------------------
Regards,
Eugene Wee
More information about the License-discuss
mailing list