diff options
author | Thomas Lange <lange@debian.org> | 2023-10-15 13:48:25 +0200 |
---|---|---|
committer | Thomas Lange <lange@debian.org> | 2023-10-15 13:48:25 +0200 |
commit | ecd4c8136b9bdb164b532fb5179bb8ddfe990942 (patch) | |
tree | 75c75f8ec9d4f4ae49adebad77e55e364936f44f /english/intro | |
parent | dee4d6e7c5b7b6c2ae51fede8645ea71c8bae34c (diff) |
remove outdated file which we do not link to
Diffstat (limited to 'english/intro')
-rw-r--r-- | english/intro/license_disc.wml | 116 |
1 files changed, 0 insertions, 116 deletions
diff --git a/english/intro/license_disc.wml b/english/intro/license_disc.wml deleted file mode 100644 index 5a0b9894bc1..00000000000 --- a/english/intro/license_disc.wml +++ /dev/null @@ -1,116 +0,0 @@ -#use wml::debian::template title="Comparison of Software Licenses" - -<P><STRONG>******This document is under development*******</STRONG> - -<P>People who have been around Open Software tend to develop very strong -opinions about licenses. Beginners don't worry about them as much -since they are more concerned with finishing the task at hand and -don't understand the long term implications of choosing software with -one license over another (it is doubtful that there -many people who understand the nuances of licensing that don't have -strong opinions on the matter). - -<P>Over the years a number of licenses have gained prominence as they -give software authors the type of control over their creations that -most developers desire. It is still common to find software that has -no copyright visible or contains a unique license developer by the -author. The last can be quite annoying to distributors of software -(both on-line and people who create CDs) as many of these licenses -contain <A HREF="#mistakes">common mistakes</A> which make the software -difficult to distribute. - -<P>What follows is a list of common Free (Open) software licenses and -some good and bad points of each. -Only the points in the license relevant to the discussion are shown. -Also, many points are listed under the heading "GOOD/BAD". -These are points that can be either good or bad, depending on your point of view. - -<UL> -<LI>The <A HREF="https://www.gnu.org/">GNU General Public License (GPL)</A>. - <BR> - <B>SUMMARY:</B> source code must be made available; software may be sold; - derived works must use the same license - <BR> - <B>GOOD:</B> There is good reason this is the most used license for Free (Open) - software. It does a good job of protecting the rights of software developers - and the availability of source code guarantees that users won't have to worry - about losing support in the future. - <BR> - <B>GOOD/BAD:</B> Software released using the GPL cannot be incorporated into - commercial software. - Whether this is actually a bad thing depends on your - point of view. People developing commercial software often feel frustrated - when there is a solution available that can't be used because of conflicts in - licensing. Of course, there is nothing stopping them from - contacting the author and seeing if they can buy a version using a different - license. - Most people who release software using the GPL do not consider these restrictions - bad, because it allows others to use and improve the software while it prevents - (for all practical purposes) others from making money off of their hard work - without their permission. - -<LI>Artistic License - <A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>. - <BR> - <B>SUMMARY:</B> - <BR> - <B>GOOD:</B> - <BR> - <B>BAD:</B> - -<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">BSD style license</A>. - <BR> - <B>SUMMARY:</B> Binaries and source code must contain the license; - advertising must acknowledge the developers listed in the license - <BR> - <B>GOOD/BAD:</B> Companies that want an executable to be generally available - (possibly for free) without releasing the source code often like - this license. A good example is a company that wants to release a driver - for a graphics card. Open Source advocates would prefer that the company - release hardware specifications anyway. If the development of drivers - for XFree86 is indicative, the best drivers are those written with - source available. Companies are only making their products look bad by - releasing proprietary drivers that are slow and buggy. They can also - save development costs by letting others develop the driver for them. - <BR> - <B>GOOD/BAD:</B> Anyone may take the source, modify it, and release the - result without releasing the changes. Whether you think this is good or - bad is a personal preference. -</UL> - -<HR> - -<P><A NAME="mistakes">Some common mistakes in self-written licenses</A>: -<UL> -<LI>Either not allowing, or restricting for-profit sale of the software. - This makes it difficult to distribute the software on CD. People often - make the mistake of using terms that are not well defined, such as 'reasonable cost'. - It is better to simply use one of the licenses mentioned above as they accomplish - the same thing without resorting to such phrases. - For example, by allowing anyone to distribute the software, the GPL keeps the - costs down by the usual market forces. If someone is selling a CD with a high - profit margin it won't be long before competitors enter the market and sell - for a lower price. - <BR>Note: the Artistic License does use the term `Reasonable copying fee', but - qualifies the term in an attempt to make it less vague. -<LI>Not allowing distribution of modified versions of the software. - This hinders distribution of the software by certain groups. For example, since - Debian distributes compiled software, it is often necessary to modify the source - to get it to compile or to make it comply with the - <A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>. - But by doing this, we are then not allowed to distribute it. -<LI>Requiring that all changes to the software be reported to the author. While it is - a good idea to report changes/improvements to the author so they can be more widely - distributed, making it a requirement can cause problems. How many people know - where they will be in 5 years? - Simply change it to 'Any changes to the software should be reported to the author'. - Most people will. - <BR>This clause is usually included to prevent branch projects from developing. - History has shown that, as long as development on the original code doesn't stall, - branches will only succeed if some other force drives the split. -<LI>Stating that the software is public domain, but then adding constraints (such as - not allowing sale for profit). Either something is public domain or it isn't - there - is no middle ground. Such licenses are meaningless and it is likely that the extra - conditions would not be upheld in court. -</UL> - |