For Approval: Microsoft Permissive License

[Rick Moen]

Quoting Donovan Hawkins (hawkins at cephira.com):
> On Sun, 9 Sep 2007, Eugene Wee wrote (quoting Licensing HOWTO):
> 
> >In practical terms, this means that some license upgrades are legally safe.
> ...
> >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.
> 
> In other words, you can add restrictions but not remove them...you can 
> move only to a compatible license. That is not the case with GPL v2 -> v3.

No.  That is not exactly what Catherine and Eric wrote.  The legal
heuristic is in terms of economic interests and non-incurrence of torts.
You should read the full analysis, but here is a representative
quotation:

  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.)

  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.

It is clear to me that the example you cite, of a project leader
changing the project's licensing terms from GPLv2 to GPLv3, does qualify 
as protecting the rights of contributors and avoiding injury to them.

> I can't speak for every open source developer, but there is no way in heck 
> I'm getting myself on the hook based on the advice of Internet IANAL's 
> (and the occasional real lawyer), none of whom I can sue for incompetance 
> if they are wrong.

No, you should act on the basis of an elementary understanding of tort
law, which turns out to be not very difficult.

> On top of all that, it's not ethically right to change license terms in a 
> way that you were not granted permission for without asking (especially 
> if you'd like to keep getting contributions). 

Really?  I would think it would be highly unethical, as project leader,
to neglect to change to a better licence that more reliably protects
your contributors' interests against new threats (e.g., burgeoning
patent portfolios) and old ones.

But you're right that the nearly universal acceptance of the wrongheaded
notion you voice makes it "culturally" problematic for a project leader
to take the ethical course of action.  My point is that the open source
/ free software culture is, in that regard, messed up.  (Krishnamurti:
"It is no measure of health to find oneself well-adjusted to a sick
society.")

-- 
Your font is:      Proportional  Monospaced
                                      ^
Matt McIrvin's amazing Font-o-Meter!