For Approval: Microsoft Permissive License

[Zac Bowling]

Your aggurment has merit for possibly with licenses that don't have
have any text stipulating the license remain the same but in the case
of GPL, it specificly states "the distribution of the whole must be on
the terms of this License". It specificly requires you to release
under this license without change.

Nearly the entire text speaks about making sure that the license is
protected. The Linux kernel has no "GPLv2 or later" clause. Trying to
change it, you would be in direct voliation of the license because the
license text says you have to release under "this License". It's very
clear on that. Everyone that contributed to the project, did so under
the same license for the code that is copyrighted by them. Without
securing permision from everyone that owns a copyright on the code to
release under a different license you can't change the license on that
code.

The author can hold you responable as voliating their license for
changing the license when you redistribute under these licenses. No
actual damages test is required in that case. You own the copyright,
and anyone using it outside the terms of the license you released,
then they are violating it.

Even the FSF has said the same (see the GPL FAQ -
http://www.gnu.org/licenses/gpl-faq.html).

On 9/9/07, Eugene Wee <eugenew at starhub.net.sg> wrote:
> 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
>


-- 
Zac Bowling
http://www.zacbowling.com
---

I support Mozilla Firefox.
http://www.spreadfirefox.com/?q=affiliates&id=12079&t=1