License comparison

From Helpful

This is currently very much a collection of notes. Do not make legal decisions based on just this.

This article (or section) is a stub.
It is here because it was planned, created to drop some preliminary notes. Facts may be wrong, and the style and structure may suck. Feel free to add further notes or suggestions, rewrite sections or the whole into something understandable.


Note: Most licenses here are chain agreements - you agree to the license contents with the person who released something, the last one in a chain. (This in contrast with most other licenses, in which you can only legally agree with the original creator)




Contents

Potentially confusing concepts

OSS, FOSS and FS

Free software (sometimes 'FS') deals with liberty of use, sometimes described as 'free as in speech', libre, or similar.

Free software licenses "free the recipient from any legal barriers which would inhibit their freedom to run, study, modify, or redistribute the software - both modified and unmodified."
(source: wikipedia)


Open Source Software (OSS) deals with the availability of source code. Open source implies that you can at least look at the source, and usually also that you can use it and modify it, under varying but usually relatively loose legal conditions.


Free Open Souce Software (FOSS) is both of the above, and is generally what you were thinking of when you are a geeky idealist.


Note that neither freeness nor openness refers to cost as in pricing to the end user (sometimes described as 'free as in beer' or gratis).

Any of the above may well be sold (for profit, or just distribution costs), as long as the applicable licenses do not restrict it, and you have a business model that makes sense. Note that the fact that the source is available (for free) does not mean you can't sell services for or based on something. Consider e.g. helpdesk support sold along with specific linux distributions.


Note that not all licensing applies only to to source and programming. See for example Qt's licensing model.

'Chain agreement' and 'viral license'

In the general business sense, licenses have a singular, original content owner who you have to seek out and sign an agreement with. This is how most intellectual property works.


One way of not having central ownership but still have legal implications is by using chain agreements. You can pick up a version of content with a particular chain agreement license, use it, and when you release a new form, the license controls what you must, may, and may not do in that process.

Generally, each part of a chain agreement is bound by the same terms, which is how the whole can make legal sense without a central owner, without losing


The GPL is a common example because it is easily explained: Anything GPLed you take may only be released under the same terms, no more, no less. In other words, no matter how much GPLed content evolves, adapts and gets adopted, the license will not change.


In the case of the GPL, this can be seen as both a strong and a weak point. Critics call it a viral license: once source is GPLed, it cannot be re-licensed, and it also forces you to GPL most any code you added around the original GPLed code, even if not particularly related.


Only the original author can release the original version under something else - multi-license it - but in practice, this is often a non-solution to the GPL's viral nature as this cannot apply retroactively or otherwise change the license on development already made - which generally made the source interesting in the first place. GPLed content is almost impossible to multi-license. It is possible, but you need consent of all applicable authors, which is often nearly impossible.

The implication is that GPLed source sometimes prevents itself from being adopted, and prevents mingling when any proprietary code is involved. This is one reason there are other common licenses that are more forgiving to specific cases (e.g. the LGPL) or almost entrely unrestrictive (e.g. BSD, MIT).


'Substantial portion'

Various licenses state that they apply when the software/document are used in full, alternation, or use of a 'substantial portion' . This is inherently fuzzy.


Source license / Non-source license

Many source code licenses are source code licenses primarily because they are written with terminology meant for source code.

Recently, various non-source copyleft licenses have appeared, some specific for text, metadata, or video or audio media, and more.


Multi-licensing

Multi-licensing is separate from compatibility - you can dual-license under incompatible licenses when a user only agrees with one at a time - multi-licensing is a disjunction of the two.

(This assumes you are not being bound by incompatible licenses, and that you are not implicitly bound by something else while attempting to dual license)

In fact, incompatibility is often the point. For example, Qt can be used in two ways:

  • under the paid-for QPL, which allows you to use Qt in proprietary programs without having to release anything, or alternatively
  • simply under the GPL

That, the source is open, but whether its practically usable form is depends on how you use it / what you use it in.


'GPL compatible'

GPL compatible does not mean 'at least as free as GPL' nor 'usable as an near-equivalent drop-in replacement for GPL.'

It means the license could apply at the same time as the GPL, meaning GPL'ed software can incorporate it without violating the terms of either license.

In the case of incompatibility, this matters to coders and projects in general: it may imply two pieces of source cannot legally be used in the same product at all.


GPL is the largest compatibility problem among the bunch, stemming from its 'no more, no less' rule about restrictions. This rule is there largely to avoid circumventing the GPL; being a chain agreement it would be fragile without it.

At the same time, GPL incompatibilities can be nagging points. For example, the old-style BSD license is incompatible with the GPL because of its advertizement clause, which most coders or users won't care much about.

When do requirements apply?

Many requirements apply at the point you release, (re)sell or re-license the software (in binary and/or source form(verify)).

They do not apply to personal or hobby use unless that is explicitly stated (and there are legal limits to what may be limited).

General / non-source licenses

Public Domain (PD)

Not a license; mainly a release, a statement of 'no requirements,' and so not too specific to types of work. Things also enter the public domain by implication, by outdated and non-renewed/non-renewable copyright, and involved timespans do depend on type of work.

You can do whatever you want with public domain material. Not even preserving the author's name is required, though this is often considered good style.


Creative Commons (CC)

  • License usually used for creative work, not source
  • Maintain Attribution and Disclaimer
  • In variations: Derivative work → Same license
  • In variations: No inherent commercial license
  • In variations: No derivative works

Source licenses

Explanation of Summarizing one-liners

"Must distribute modified source"

This comes from a mindset central to open source: "if you improve it, the benefits are for all - and not at at the cost of money or restrictions". Things in general use benefit from this as it prevents a lot of wheel reinvention.

In practice there are variations, such as the difference between the GPL and LGPL:

  • GPL virally forces everyhing open
  • LGPL allows for sectioning into libraries. If you merely use another's LGPL library it has no implications; only if you changes to the library (or heavily integrate it) you have to distribute.
  • In BSD / X / Apache, redistributing modifications is purely optional

Note: Technically this requirement doesn't force use of the same license on the distributed source, but it often does to avoid fuzzy legalities and possible abuse.

Any use or library use → Same license

...means no distinction is made between 'you improve our code' or 'you use our code unchanged for a feature'.

For example, if you use a library to open an obscure sound or picture format but that library forces your grand music player/photo editing application to a particular license, or two such licenses contradict, you just can't use it.

LGPL is a variation of the GPL that essentially puts a library you use on its own legal terms. You can use it without it virally changing the licensing for your app, changes to the library have to be opened.

More exactly, LGPL says only direct derivatives are forced to the same license. This feels more comfortable to various people, so some prefer it. GNU suggests you use the GPL when possible as close-sourced apps can use these libraries without anything in return.

Maintain Attribution and Disclaimer

Well, just that.

The disclaimer tends to be inherent in the license that oft-used 'use the same license' guarantees.



GNU General Pulic License (GPL)

  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source (and any source that uses)
  • Same license for derivative work

Upsides:

  • "you improve it, you tell us" is basically a shared-cost continuous development cycle
  • Improvements are necessarily fed back to the community (...on release or sale)

Downsides:

  • The tiniest use of GPLed source forces everything to be open (see also LGPL)
  • Implicitly incompatible with various others

Applicability to documents?(verify)


Version 2 and 3

Version 2 is current. Version 3 updates 2 mostly in the point that it would extend to hardware (apparently, (verify)) and would have a provision there are no DRM-like systems (apparently, (verify)).

Similar/Related licenses

CeCILL

CeCILL is a GPL-compatible adaptation of the GPL to the French legal system.

There are also two variants:

  • CeCILL-B, which is rather like BSD, X11, MIT licenses
  • CeCILL-C, which is rather like LGPL


IBM Public License (IPL)

(related to but not to be confused with IBM's Common Public License (CPL)) A variation of the GPL that:

  • moves liability from contributor to publisher/distributor.
  • terminates the license on patent disputes

Incompatible with but generally very similar to the GPL.

IBM's Common Public License (CPL)

  • Source license
  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source
  • Derivative work → Same license
  • Avoids contributors from sneaking in code with patents and then charing for it.
  • Future reviews could affect earlier software (also true for GPL, though(verify))

BSD-like licenses

BSD licenses (a.k.a. Berkeley licenses)

  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source
  • "Same license for derivative work" - to sustain the attribution requirement.

Simple, permissive: somewhat like public domain, but has the requirement that you copy attribution to the coders programmers, and that the license itself is included in all derivatives.

Upsides:

  • (for coders) you can use this code without strong implications
  • (businesswise) this code can be used in proprietary programs you sell, requiring only attribution

Downside:

  • (program/communitywise) vampirism is easy - anyone can use without doing someting in return, although this only really happens outside the (F)OSS communities. The common examples are Microsoft's IP network stack being directly adapted from BSD's, and Apple's OS X which is strongly based in FreeBSD and mostly closed-source. You can argue about how bad this really is.


For the case of binary distributions, these licenses will require copyright notices to be placed in the documentation.


Note that there are different versions of this license, and that similar (ISC, MIT) and derived (OpenBSD, NetBSD) licenses are often functionally equivalent to one of them. (See also: [2])


4-clause, "Original BSD License", "BSD license with advertising clause"

The original BSD license had four clauses. NetBSD still uses it. The clauses roughly require that:

  • Code (re)distributions must retain the copyright notice, the clauses, and the mentioned disclaimer
  • Binary (re)distributions must retain the copyright notice, the clauses, and all disclaimers
  • Advertisements mentioning this software must acknowledge its origin/contributors (what exactly to mention is stated in each specific license)
  • Names of copyright holders nor contributors may not be used in endorsements of (this/derived) software without permission.

GPL-incompatible(verify) because of the advertizement clause (the third).

The advertizement clause was initially intended for BSD. Once used elsewhere, though, there were both licenses with arbitrary mentions to the University of California, and many licenses with programmers' own names, which causes larger projects (e.g. merging such software into BSD again) to require any ads to mention dozens of names.

3-clause, "Modified BSD License"

The "3-clause", "Modified BSD license" removes the third clause from the 4-clause version:

  • Code (re)distributions must retain the copyright notice, the clauses, and the mentioned disclaimer
  • Binary (re)distributions must retain the copyright notice, the clauses, and all disclaimers
  • Names of copyright holders nor contributors may not be used in endorsements of (this/derived) software without permission.

GPL-compatible.

2-clause

FreeBSD and others use just the first two rules, i.e.:

  1. Code (re)distributions must retain the copyright notice, the clauses, and the mentioned disclaimer
  2. Binary (re)distributions must retain the copyright notice, the clauses, and all disclaimers

This is generally the assumed version when people say 'BSD license', and it is GPL-compatible.

GPL-compatible


MIT license (a.k.a. X11 license and X license)

  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source
  • "Same license for derivative work" (which implies only attribution) (verify)

Basically equivalent to the 2-clause variation of the BSD license: MIT does not prohibit the use of the copyright holder's name in promotion.


Note: When people say 'MIT license', they usually mean the license originally drafted for X11. This is arguably the most major license to come out of MIT, and confusing as there are other licenses used for other MIT software (primarily/only).


Apache licenses

  • Maintain Attribution, Disclaimer
  • Must Distribute Modified Source
  • "Same license for derivative work" (which implies only attribution) (verify)

The Apache Software License 1.0, Apache Software License 1.1, and Apache License 2.0 are rather similar to BSD and MIT style licenses in that use is free, and modifications can be kept secret and sold. The main difference is the requirement of a notice of use of licensed code.


Python Software Foundation license

This article (or section) is a stub.
It is here because it was planned, created to drop some preliminary notes. Facts may be wrong, and the style and structure may suck. Feel free to add further notes or suggestions, rewrite sections or the whole into something understandable.

http://en.wikipedia.org/wiki/Python_Software_Foundation_License

GNU Lesser/Library Public License (LGPL)

  • Fairly specific to source
  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source (but not code that only uses)

LGPL is something like 'GPL when you change, BSD-like when you use.'

You have to publicise alterations to the library, but generally this just improves the library quality (may sometimes create a flurry of use and improvement) and rarely forces you to expose something you didn't want to.

Upsides:

  • Code can used in a (larger) project without having to open the entire project now or later

Downsides:

  • Allows legal reverse engineering (but so do most others)
  • LGPL-licensed software can be used in proprietary software. This is a purist view, noting this gives proprietary development an advantage over free software


In a semi-open world, LGPL (or one of the licenses like it) is a fairly good choice of both making your code useful for most everyone and making it low-implication for the most people.

A critical, pro-FOSS-and-anti-proprietary stance would note that you can be giving a proprietary project an edge by doing this since you can both use the library easily. The FSF takes this stance and suggests you use the GPL.


Open Source License (OSL)

  • Source license
  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source

(to check)




Academic Free License (AFL)

  • Source license
  • Maintain Attribution and Disclaimer
  • Must Distribute Modified Source

Meant to succede Apache, MIT, BSD.

Artistic License


Content licenses

GNU Free Documentation License (FDL, GFDL)

The FDL applies to text rather than source, and was created partly because the GPL's terms are hard to apply to text, and also partly in consideration of the more physical nature of documentation, books and such can take.

(Technically, you 'can' use the GPL for general works, but you need to clarify the meaning of some og the GPL's terms, such as 'source code')

The upsides include copylefting needs, and freely using other FDL'd content. It's used in various open content wikis, including wikipedia.

One downside is the burden introduced when you distribute more than 100 physical copies: you must include the FDL text and the source form for the content (digitally or physically). This is a problem for some formats, like pamphlets.

One common alternative is Creative Commons.

See also:

Comments:


FreeBSD Documentation License

A permissive license, rather like the BSD license for code's relation to the GPL.


Design Science License (DSL)

A license meant for sharing scientific data rather than text.


Open Publication License (OPL)

May be used in free or non-free form.

Open Content License

Somewhat restrictive, mostly monetary.

Creative Commons

Initially, CC referred to a small list of distinct licenses that all require the original creator to be named, and have different combinations of optional extra requirements on derivative works:

  • No Derivative Works: you are only allowed to distribute unaltered copies of the work
  • Non-Commercial: work may not be used for commercial purposes
  • Share Alike: derivative work must be shared with same license

This meant you can choose the gradation of permissiveness. See also:


CC has since created various other licenses, some simply combinations for specific sharing cases, say attribution+noncommercial+noderivative for music sharing. Some licenses have specific allowances, such as sampling music.

See also:


Free art license (Licence Art Libre)

This article (or section) is a stub.
It is here because it was planned, created to drop some preliminary notes. Facts may be wrong, and the style and structure may suck. Feel free to add further notes or suggestions, rewrite sections or the whole into something understandable.

See also:


Apple's Common Documentation License

Unsorted

Python Software Foundation License ('Python License')


See also

Lists of licenses with comments:

Just lists:


Wikipedia articles on...


Other discussions, comparisons and comments:


Unsorted: