www/licenses license-recommendations.html

[Richard M. Stallman]

CVSROOT:        /web/www
Module name:    www
Changes by:     Richard M. Stallman <rms>       14/09/29 11:29:43

Modified files:
        licenses       : license-recommendations.html 

Log message:
        Reorganize the part about software, grouping exceptions into
        subsections.  Explain better about several issues.
        Say SaaSS, not SaaS.

CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/license-recommendations.html?cvsroot=www&r1=1.27&r2=1.28

Patches:
Index: license-recommendations.html
===================================================================
RCS file: /web/www/www/licenses/license-recommendations.html,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -b -r1.27 -r1.28
--- license-recommendations.html        26 Jun 2014 19:35:03 -0000      1.27
+++ license-recommendations.html        29 Sep 2014 11:29:43 -0000      1.28
@@ -57,11 +57,11 @@
 copyleft</a>.  If you are in this situation, please follow the
 recommendations below for licensing a new project.</p>
 
-<p>If you choose to release your contributions under a different license
-for whatever reason, you must make sure that the original license
-allows use of the material under your chosen license.
-To minimize the impact on others,
-show explicitly which parts of the work are under which license.</p>
+<p>If you choose to release your contributions under a different
+license for whatever reason, you must make sure that the original
+license allows use of the material under your chosen license.  For
+honesty's sake, show explicitly which parts of the work are under
+which license.</p>
 
 <h3 id="software">Software</h3>
 
@@ -73,62 +73,93 @@
 concept of copyleft in more detail, and why it is generally the best
 licensing strategy.</p>
 
-<p>There are only a couple of kinds of projects that we think should
-not have any copyleft at all.  The first is very small projects.  We
-use 300 lines as our benchmark: when a software package's source code
-is shorter than that, the benefits provided by copyleft are usually
-too small to justify the inconvenience of making sure a copy of the
-license always accompanies the software.</p>
-
-<p>The second is projects that implement free standards that are
-competing against proprietary standards, such as Ogg Vorbis (which
-competes against MP3 audio) and WebM (which competes against MPEG-4
-video).  For these projects, widespread use of the code is vital for
-advancing the cause of free software, and does more good than a
-copyleft on the project's code would do.</p>
-
-<p>In these special situations where copyleft is not appropriate, we recommend
-the <a href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License 
2.0</a>.  This is a pushover (non-copyleft)
-software license that has terms to prevent contributors and distributors
-from suing for patent infringement.  This doesn't make the software immune
-to threats from patents, but it does prevent patent holders from setting up a
-&ldquo;bait and switch&rdquo; where they release the software under free
-terms then require recipients to agree to nonfree terms
-in a patent license.</p>
-
-<p>In all other cases, we recommend some kind of copyleft.  If your project is
-a library, and developers are already using an established alternative library
-released under a nonfree license or a lax pushover license, then we recommend 
using
-the <a href="/licenses/lgpl.html">GNU Lesser General Public License 
(LGPL)</a>.  Unlike the case
-discussed earlier where the project implements a standard, here adoption
-for its own sake will not accomplish any particular goal, so there's no
-reason to avoid copyleft entirely.  However, if you ask developers who
-use your library to release their work under a full copyleft, they'll simply 
use one of the
-alternatives available, and that won't advance our cause either.  The
-Lesser GPL was designed to fill the middle ground between these cases,
-allowing proprietary software developers to use the covered library, but
-providing a weak copyleft that benefits users when they do.  If you want to
-learn more about our thinking in these cases, read <a 
href="/licenses/why-not-lgpl.html">&ldquo;Why you
-shouldn't use the Lesser GPL for your next library&rdquo;</a>.</p>
-
-<p>If your project could likely be run on a server after others improve
-it, interacting with its users over a network, and you're concerned
-that fewer developers will contribute to the released versions as a result, we
-recommend the <a href="/licenses/agpl.html">GNU Affero General Public License 
(AGPL)</a>.  The
-AGPL's terms are almost identical to the GPL's; the sole substantive
-difference is that it has an extra condition designed to ensure that
-people who use the software over a network will be able to get the
-source code for it.  This condition doesn't address every problem that
-can arise when users do their computing on a server&mdash;it won't
-stop users from being <a 
href="/philosophy/who-does-that-server-really-serve.html">harmed by Software as 
a
-Service</a>&mdash;but it accomplishes as much as a license can.  To
-learn more about these issues, read <a 
href="/licenses/why-affero-gpl.html">&ldquo;Why the Affero
-GPL&rdquo;</a>.</p>
-
-<p>In all other cases, we recommend that you use the most recent version
-of the <a href="/licenses/gpl.html">GNU General Public License (GPL)</a> for 
your project.  Its
-strong copyleft is appropriate for all kinds of software, and includes
-numerous protections for users' freedom.</p>
+<p>For most programs, we recommend that you use the most recent
+version of the <a href="/licenses/gpl.html">GNU General Public License
+(GPL)</a> for your project.  Its strong copyleft is appropriate for
+all kinds of software, and includes numerous protections for users'
+freedom.</p>
+
+<p>Now for the exceptions.</p>
+
+<h3 id="small">Small programs</h3>
+
+<p>It is not worth the trouble to use copyleft for most small
+programs.  We use 300 lines as our benchmark: when a software
+package's source code is shorter than that, the benefits provided by
+copyleft are usually too small to justify the inconvenience of making
+sure a copy of the license always accompanies the software.</p>
+
+<p>For those programs, we recommend
+the <a href="http://www.apache.org/licenses/LICENSE-2.0";>Apache
+License 2.0</a>.  This is a pushover (non-copyleft) software license
+that has terms to prevent contributors and distributors from suing for
+patent infringement.  This doesn't make the software immune to threats
+from patents (a software license can't do that), but it does prevent
+patent holders from setting up a &ldquo;bait and switch&rdquo; where
+they release the software under free terms then require recipients to
+agree to nonfree terms in a patent license.</p>
+
+<p>Among the lax pushover licenses, Apache 2.0 is best; so if you
+are going to use a lax pushover license, whatever the reason,
+we recommend using that one.</p>
+
+<h4 id="libraries">Libraries</h3>
+
+<p>For libraries, we distinguish three kind of cases.</p>
+
+<p>Some libraries implement free standards that are competing against
+restricted standards, such as Ogg Vorbis (which competes against MP3
+audio) and WebM (which competes against MPEG-4 video).  For these
+projects, widespread use of the code is vital for advancing the cause
+of free software, and does more good than a copyleft on the project's
+code would do.</p>
+
+<p>In these special situations, we recommend
+the <a href="http://www.apache.org/licenses/LICENSE-2.0";>Apache
+License 2.0</a>.</p>
+
+<p>For all other libraries, we recommend some kind of copyleft.  If
+developers are already using an established alternative library
+released under a nonfree license or a lax pushover license, then we
+recommend using the <a href="/licenses/lgpl.html">GNU Lesser General
+Public License (LGPL)</a>.</p>
+
+<p>Unlike the first case, where the library implements an ethically
+superior standard, here adoption for its own sake will not accomplish
+any special objective goal, so there's no reason to avoid copyleft
+entirely.  However, if you require developers who use your library to
+release their whole programs under copyleft, they'll simply use one of
+the alternatives available, and that won't advance our cause either.
+The Lesser GPL was designed to fill the middle ground between these
+cases, allowing proprietary software developers to use the covered
+library, but providing a weak copyleft that gives users freedom
+regarding the library code itself.</p>
+
+<p>For libraries that provide specialized facilities, and which do not
+face entrenched noncopylefted or nonfree competition, we recommend
+using the plain GNU GPL.  For the reasons why,
+read <a href="/licenses/why-not-lgpl.html">&ldquo;Why you shouldn't
+use the Lesser GPL for your next library&rdquo;</a>.
+
+<h4 id="server">Server Software</h3>
+
+<p>If it is likely that others will make improved versions of your
+program to run on servers and not distribute their versions to anyone
+else, and you're concerned that this will put your released version at
+a disadvantage, we recommend the <a href="/licenses/agpl.html">GNU
+Affero General Public License (AGPL)</a>.  The AGPL's terms are almost
+identical to the GPL's; the sole substantive difference is that it has
+an extra condition to ensure that people who use the software over a
+network will be able to get the source code for it.</p>
+
+<p>The AGPL's requirement doesn't address the problems that can arise
+<em>for users</em> when they entrust their computing or their data to
+someone else's server.  For instance, it won't stop
+<a href="/philosophy/who-does-that-server-really-serve.html">Service
+as a Software Substitute (SaaSS)</a> from denying users'
+freedom&mdash;but most servers don't do SaaSS.  For more about these
+issues, read <a href="/licenses/why-affero-gpl.html">&ldquo;Why the
+Affero GPL&rdquo;</a>.</p>
 
 <h3 id="documentation">Documentation</h3>
 
@@ -245,7 +276,7 @@
 
 <p class="unprintable">Updated:
 <!-- timestamp start -->
-$Date: 2014/06/26 19:35:03 $
+$Date: 2014/09/29 11:29:43 $
 <!-- timestamp end -->
 </p>
 </div>