first

1 files changed, 264 insertions, 0 deletions

diff --git a/docs/license-recommendations.md b/docs/license-recommendations.md
new file mode 100644
index 0000000..a518396
--- /dev/null
+++ b/docs/license-recommendations.md
@@ -0,0 +1,264 @@
+---
+Generator: 'texi2html 1.82'
+description: Untitled Document
+distribution: global
+keywords: Untitled Document
+resource-type: document
+title: Untitled Document
+...
+
+1. How to Choose a License for Your Own Work {#how-to-choose-a-license-for-your-own-work .chapter}
+============================================
+
+### Introduction {#introduction .subheading}
+
+People often ask us what license we recommend they use for their
+project. We’ve written about this publicly before, but the information
+has been scattered around between different essays, FAQ entries, and
+license commentaries. This article collects all that information into a
+single source, to make it easier for people to follow and refer back to.
+
+These recommendations are for works designed to do practical jobs. Those
+include software, documentation, and some other things. Works of art,
+and works that state a point of view, are different issues; the GNU
+Project has no general stand about how they should be released, except
+that they should all be usable without nonfree software (in particular,
+without DRM[(1)](#FOOT1)). However, you might want to follow these
+recommendations for art works that go with a particular program.
+
+The recommendations apply to licensing a work that you create—whether
+that’s a modification of an existing work, or a new original work. They
+do not address the issue of combining existing material under different
+licenses. If you’re looking for help with that, please check our GPL
+FAQ.[(2)](#FOOT2)
+
+After you see what we recommend here, if you’d like advice, you can
+write to <licensing@gnu.org>. Note that it will probably take a few
+weeks for the licensing team to get back to you; if you get no response
+in a month, please write again.
+
+@firstcopyingnotice{{@footnoterule Copyright © 2011, 2013, 2014 Free
+Software Foundation, Inc.\
+ {This essay was first published on <http://gnu.org>, in 2011. This
+version of it is part of @fsfsthreecite}
+
+### Contributing to an Existing Project {#contributing-to-an-existing-project .subheading}
+
+When you contribute to an existing project, you should usually release
+your modified versions under the same license as the original work. It’s
+good to cooperate with the project’s maintainers, and using a different
+license for your modifications often makes that cooperation very
+difficult. You should only do that when there is a strong reason to
+justify it.
+
+One case where using a different license can be justified is when you
+make major changes to a work under a noncopyleft license. If the version
+you’ve created is considerably more useful than the original, then it’s
+worth copylefting your work, for all the same reasons we normally
+recommend copyleft. If you are in this situation, please follow the
+recommendations below for licensing a new project.
+
+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.
+
+### Software {#software .subheading}
+
+We recommend different licenses for different projects, depending mostly
+on the software’s purpose. In general, we recommend using the strongest
+copyleft license that doesn’t interfere with that purpose. Our essay
+“What is Copyleft?” (@pageref{Copyleft}) explains the concept of
+copyleft in more detail, and why it is generally the best licensing
+strategy.
+
+For most programs, we recommend that you use the most recent version of
+the GNU General Public License (GPL) (@pageref{GPL}) for your project.
+Its strong copyleft is appropriate for all kinds of software, and
+includes numerous protections for users’ freedom.
+
+Now for the exceptions.
+
+#### Small Programs {#small-programs .subsubheading}
+
+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.
+
+For those programs, we recommend the Apache License 2.0.[(3)](#FOOT3)
+This is a pushover (noncopyleft) 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 “bait and switch” where they release the
+software under free terms then require recipients to agree to nonfree
+terms in a patent license.
+
+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.
+
+#### Libraries {#libraries .subsubheading}
+
+For libraries, we distinguish three kind of cases.
+
+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.
+
+In these special situations, we recommend the Apache License 2.0.
+
+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 GNU Lesser General Public License (LGPL) (@pageref{LGPL}).
+
+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.
+
+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 “Why You Shouldn’t Use the
+Lesser GPL for Your Next Library,” at
+<http://gnu.org/licenses/why-not-lgpl.html>.
+
+#### Server Software {#server-software .subsubheading}
+
+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 GNU Affero General Public License
+(AGPL).[(4)](#FOOT4) 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.
+
+The AGPL’s requirement doesn’t address the problems that can arise *for
+users* when they entrust their computing or their data to someone else’s
+server. For instance, it won’t stop Service as a Software Substitute
+(SaaSS) from denying users’ freedom[(5)](#FOOT5)—but most servers don’t
+do SaaSS. For more about these issues, read “Why the Affero GPL,” at
+<http://gnu.org/licenses/why-affero-gpl.html>.
+
+### Documentation {#documentation .subheading}
+
+We recommend the GNU Free Documentation License (@pageref{FDL}) for
+tutorials, reference manuals and other large works of documentation.
+It’s a strong copyleft license for educational works, initially written
+for software manuals, and includes terms which specifically address
+common issues that arise when those works are distributed or modified.
+
+For short, secondary documentation works, such as a reference card, it
+is better to use the GNU all-permissive license,[(6)](#FOOT6) since a
+copy of the GFDL could hardly fit in a reference card. Don’t use CC-BY,
+since it is incompatible with the GFDL.
+
+For man pages, we recommend the GFDL if the page is long, and the GNU
+all-permissive license if it is short.
+
+Some documentation includes software source code. For instance, a manual
+for a programming language might include examples for readers to follow.
+You should both include these in the manual under the FDL’s terms, and
+release them under another license that’s appropriate for software.
+Doing so helps make it easy to use the code in other projects. We
+recommend that you dedicate small pieces of code to the public domain
+using CC0,[(7)](#FOOT7) and distribute larger pieces under the same
+license that the associated software project uses.
+
+### Other Data for Programs {#other-data-for-programs .subheading}
+
+This section discusses all other works for practical use that you might
+include with software. To give you some examples, this includes icons
+and other functional or useful graphics, fonts, and geographic data. You
+can also follow them for art, though we wouldn’t criticize if you don’t.
+
+If you are creating these works specifically for use with a software
+project, we generally recommend that you release your work under the
+same license as the software. There is no problem in doing so with the
+licenses we have recommended: GPLv3, LGPLv3, AGPLv3, and GPLv2 can all
+be applied to any kind of work—not just software—that is copyrightable
+and has a clear preferred form for modification. Using the same license
+as the software will help make compliance easier for distributors, and
+avoids any doubt about potential compatibility issues. Using a different
+free license may be appropriate if it provides some specific practical
+benefit, like better cooperation with other free projects.
+
+If your work is not being created for use with a particular software
+project, or if it wouldn’t be appropriate to use the same license as the
+project, then we only recommend that you choose a copyleft license
+that’s appropriate for your work. We have some of these listed on our
+license list.[(8)](#FOOT8) If no license seems especially appropriate,
+the Creative Commons Attribution-ShareAlike[(9)](#FOOT9) license is a
+copyleft that can be used for many different kinds of works.
+
+<div class="footnote">
+
+------------------------------------------------------------------------
+
+### Footnotes
+
+### [(1)](#DOCF1)
+
+@raggedright See our campaign against Digital Restrictions Management,
+at [DefectiveByDesign.org](DefectiveByDesign.org). @end raggedright
+
+### [(2)](#DOCF2)
+
+@raggedright At <http://gnu.org/licenses/gpl-faq.html>. @end raggedright
+
+### [(3)](#DOCF3)
+
+@raggedright See <http://apache.org/licenses/LICENSE-2.0> for the full
+text of the license. @end raggedright
+
+### [(4)](#DOCF4)
+
+@raggedright See <http://gnu.org/licenses/agpl.html> for the full text
+of the license. @end raggedright
+
+### [(5)](#DOCF5)
+
+@raggedright See “Who Does That Server Really Serve?” for more on the
+issue of SaaSS. @end raggedright
+
+### [(6)](#DOCF6)
+
+@raggedright See
+<http://gnu.org/licenses/license-list.html#GNUAllPermissive>. @end
+raggedright
+
+### [(7)](#DOCF7)
+
+@raggedright See <http://creativecommons.org/about/cc0> for more on the
+license. @end raggedright
+
+### [(8)](#DOCF8)
+
+@raggedright See
+<http://gnu.org/licenses/license-list.html#OtherLicenses>. @end
+raggedright
+
+### [(9)](#DOCF9)
+
+@raggedright See <http://gnu.org/licenses/license-list.html#ccbysa> for
+more on using this license. @end raggedright
+
+</div>
+
+------------------------------------------------------------------------
+
+This document was generated by *tonghuix* on *March 25, 2016* using
+[*texi2html 1.82*](http://www.nongnu.org/texi2html/).\