aboutsummaryrefslogtreecommitdiffstats
path: root/english/intro
diff options
context:
space:
mode:
authorThomas Lange <lange@debian.org>2023-10-15 13:48:25 +0200
committerThomas Lange <lange@debian.org>2023-10-15 13:48:25 +0200
commitecd4c8136b9bdb164b532fb5179bb8ddfe990942 (patch)
tree75c75f8ec9d4f4ae49adebad77e55e364936f44f /english/intro
parentdee4d6e7c5b7b6c2ae51fede8645ea71c8bae34c (diff)
remove outdated file which we do not link to
Diffstat (limited to 'english/intro')
-rw-r--r--english/intro/license_disc.wml116
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>
-

© 2014-2024 Faster IT GmbH | imprint | privacy policy