For Approval: Microsoft Permissive License

[Eugene Wee]

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