Intellectual Property, Copyright, and related rights

From Helpful

(Redirected from License comparison)

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

These are primarily notes
This is probably not going to be complete in any real sense, but may be useful information nonetheless.

This article is protected, probably because it was spammed repeatedly. To edit protected pages, please register and contact me, or bug me to try to make the spam protection better.

And, just in case those blocks don't make it clear:

This is not legal advice, or necessarily correct. Do not make legal decisions based on just this. It may be a handy first read before before diving into legalese, but may not be accurate. If you're going to do anything with legal implications, check with someone who has actually studied a bit of law.

Contents

1 Copyright
- 1.1 See also
2 (Chain) License comparison

Copyright

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

See also

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

http://copylaw.com/

http://painting.about.com/od/copyrightforartistsfaq/Copyright_for_Artists_FAQ.htm

(Chain) License comparison

Note: Most licenses here are software licenses. Most are also chain agreements, in which you agree to the license contents of the last copy/releaser in a possibly longer chain of agreements.

This is different from how the currently more usual way of dealing with copyright, in which you can only legally use the content based on contact and legal agreements with the copyright holder, which is often the single original creator / releaser of the content.

Potentially confusing points

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

(also sometimes FLOSS or F/OSS)

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 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 classical business license, there is a single content owner

(often its creator or whomever they signed the rights over to)

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. Content with such a license allow you to pick up any derivative version, and use it under the terms of that license and/or release it under the terms of the license. Particularly the latter matters, in that it controls what you must, may, and may not do in the 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.

The GPL is a common example because it is easily explained: Anything GPLed you use 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 as GPL and something else) 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. deveoped GPLed content is almost impossible to multi-license. It is possible, but you need consent of all applicable authors.

This occasionally implies that GPLed content prevents itself from being adopted as/and it 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 entirely non-restrictive (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.

Licenses may be explicitly specific to certain content. They often are implicitly somewhat specific to a medium, and/or to the specific ways something may be reused (consider e.g. code).

Dealing with things beyond source code (and use of source licenses like GPL to apply to non-source) may be more difficult to judge the legal aspects of, as details are often not as explicitly mentioned as details on source code are mentioned in source licenses.

Multi-licensing

Multi-licensing refers to giving the next person a choice of a license.

Multi-licensing is not directly a compatibility thing - you can dual-license under incompatible licenses when a user only agrees with one at a time .

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 can often be part of the point. To take a real-world example, the Qt library 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
under the GPL

the idea is that the source is open, but its licensing implications depends on how you use it, and what you use it in. Basically, you can choose to use it under GPL and have to release that code in GPL, or you can choose to use it in proprietary code and have to pay for that ability.

License compatibility, e.g. GPL compatible

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

When combining two pieces of software/data/whatnot, both licenses need to permit this because effectively enough, both apply at the same time.

It does not mean, as some people assume:

'at least as free as ...' , nor
'usable as an near-equivalent drop-in replacement for ...'

Usually, e.g. in software, the most significant related is releasing the resulting work after combination, for which all applicable licenses' requirements must be met.

This may involve various things, from not allowing the merging of two (differently licensed) modules into one, or one license's specifications about legalities not contained in itself (but implicitly added by having two licenses).

If any of those requirements specifies that may not be further expanding clauses (often to avoid circumventions), this is easily a problem area. This is in fact the case with the GPL; many other licenses violate the no-more-no-less term in the GPL.

(In some cases, licenses may be incompatible both ways)

. This specific case can be seen as a strength to the GPL license as it means the content can't be weaseled out of the license, or as a weakness, for much the same reason, and the resulting inability to combine GPL with various other licenses.

While you can figure out compatibility between any set of licenses, the term most commonly seen in relation to license compatibility is 'GPL compatible', because of this last fact, because of the GPL being common, because of the GPL being a favourite among freedom nerds, and because most non-permissive licenses (such as copyright) tend to be incompatible with anything else almost implicitly, so it doesn't even come up.

Some people use (in)compatibility to refer to related concepts, for example a one-way transfer. For example, in the context of Wikipedia policies, compatibility regularly refers to the answer of whether that transfer can happen. This differs in that it is a one-directional relation where practically only the source's restrictions apply

(and/because the target restrictions are permissive, and a constant)

, whereas the license compatibility described before is a symmetric relation.

For example, while BSD and GFDL are not mutually compatible licenses, BSD content can be added to GFDL resources such as wikipedia, but GFDL content cannot be added to BSD.

In more practical terms, the case of incompatibility matters to coders and to projects in general. It may imply two pieces of source code cannot legally be used in the same product at all, or may have to be kept non-merged even if that's efficient, a pain, or whatnot.

Note that this applies only to code that you do not own, since when you own source, you can release it under as many alternative licenses as you wish (multi-license it). The next person in the chain will choose the license that suits them best, and (only) that will apply in the chain from there.

GPL compatibility is an issue simply because GPL is a very common license (along with LGPL, BSD).

Chances are that at some point, you'll want or have to combine something with code under GPL. If something bigger can't accept you, they'll look for something else. If you can't combine to become more interesting, your project may be abandoned for worse quality ones that won't stagnate, and can be probably be cleaned up over time.

GPL is arguably one of the larger compatibility problem among copyleft licenses, because of its 'strictly no more and no less' rule about other restrictive clauses. {comment|(That rule is there largely to avoid circumventing the GPL; it makes it one of the stronger chain agreements)}}

Of course, the other side of the problem is that people seem to like creating their own license, which is just asking for incompatibilities. Choosing unusual licenses is likely to work against you.

At the same time, the cases of GPL incompatibility are often minor nagging points for its potential users. For example, the old-style 4-clause BSD license is incompatible with the GPL purely because of its advertisement clause, which most coders or users won't care much about in the first place. This is the reason for the new-style BSD license, which is GPL-compatible.

Further notes:

Perhaps the easiest set of compatible copyleft licenses is GPL, LGPL, the MIT / X license, and 3-clause BSD. If you release source under other licenses, it is less likely to be adoptable and/or supportable.

Note this list excludes many others, but perhaps most notably GFDL and CC (though those are content licenses rather than source licenses, it's still annoying that this is incompatible with interesting released under GPL or even LGPL)

Neither GPL nor GFDL are compatible with Creative Commons (some or all?), (even though the idea and implied legalities are much the same with some CC licenses, e.g. Attribution Share-Alike) (verify))

The GPL is not compatible with the GFDL (verify)

Also incompatible with GPL:
- Apache License (That is, Apache License 2.0 is compatible with GPLv3 but incompatible with GPLv2)
- Common Public License 1.0
- MPL (Mozilla Public License)
- Sun Public License

The LGPL causes less incompatibility trouble than the GPL (depending a little on the type of adoption)

http://www.dwheeler.com/essays/gpl-compatible.html http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

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 generally do not apply to personal or hobby use unless that is explicitly stated (and there are legal limits to what may be limited) -- which, note, is also the case for copyrighted materials(verify).

Issues in combining software and licenses

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Patents

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Source code 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". Avoids a lot of double work and wheel reinvention.

Note that technically, this requirement doesn't force use of the same license on the distributed source, but in practice it often does, to avoid fuzzy legalities (and possible abuse).

In practice there are variations of how this applies. Consider for example the the difference between the GPL and LGPL. While the GPL virally forces everyhing open, the LGPL allows for sectioning into libraries, and having each have its own set of implications. Specifically, if you simply use another's LGPL library it has no implications on your source around it. Only if you make changes to the library (or heavily integrate it) you have to distribute.

In BSD / X / style licenses Apache, redistributing modifications is purely optional. It's considered nice and good style and such, of course.

This usually applies when the result is distributed (released, and also often applies when internally distributed within an organisation). In that case, you can only demand the source when software with this restriction has been released, but not before then, or when someone is using for personal use.

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 to GPL

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))

See [1]

Affero General Public License

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

BSD-style 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 because of the clause about advertisements.

The advertisement clause was initially intended for BSD. Once used elsewhere, though, this means licenses were floating about with arbitrary mentions to the University of California, and many licenses with programmers' own names, which causes larger projects (e.g. and merging such software) 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, making it:

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.:

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

This is generally the assumed version when people say 'BSD license', and it is 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

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

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. There is also some more explicit detail related to patents.

Apache License 1 was GPL compatible (by mostly just being a rewritten BSD license), but
Apache License 2
- became incomptible with GPLv2 (and GPLv1) because of the patent details.
- ...but is compatible with GPLv3

Academic Free License (AFL)

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

Meant as a clarifying succession to Apache, MIT, BSD, and UoI/NCSA.

However, AFL-1.2 and AFL-2.1 are not GPL compatible. AFL-3.0 may be GPL compatible.

UoI/NCSA

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Meant as a clarification of BSD/MIT licenses

http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License

Python Software Foundation license

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

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)

Unsorted

Artistic License

Python Software Foundation License ('Python License')

Looks BSD style
http://www.python.org/psf/license/

General / content / non-source licenses

Public Domain

Not a license; mainly a release, a statement of 'no requirements,'and so not too specific to the type of the work.

Things can enter the public domain

via an outdated (not renewed, or not renewable) copyright (example: 1913 version of Webster's dictionary).
by implication, such as by being released by the US government (a few other countries do this too), (example: the CIA world factbook)
by explicit release (though this has been challenged, see below) (example: the Moby lexical resources)

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.

Note that something being in Public Domain is not exclusive with possible restrictions - in some cases, things are explicitly released into the PD but with additional restrictions (see e.g. Gutenberg documents).

Public Domain is not really a license, and is not an universal(ly equivalent) legal concept.

Public Domain in the US exists as something of an addendum to US copyright law, and the concept neither appears in every nation's laws, is certainly not the same even when it does, and seems to vary even within the US.

It is questionable whether you can, in all places that have PD, actively release something into the public domain. US PD law only mentions it as an implication of having been dead for a long time (and having no heirs to lengthen the copyright). (verify)

Note that these two last details are not necessarily a problem. The person who released it under Public Domain is likely to have done so out of reasons that mean it is unlikely they'll try to restrict it, and probably couldn't legally claim retroactive neener-neener either. But if true, there is a difference and it is not the handiest thing to use as a license.(verify)

See also:

http://en.wikipedia.org/wiki/Wikipedia:Public_domain_resources

Do What The Fuck You Want To Public License (WTFPL)

Basically a no-nonsense and less bothersome version of Public Domain.

http://sam.zoy.org/wtfpl/

Creative Commons (CC)

Creative Commons refers to a set of licenses that allow you to choose the gradation of permissiveness.

The basic ones combine the following requirements:

Maintain Attribution (and Disclaimer)
All require the original creator to be named
Option: Share Alike: derivative work must be shared with same license
Option: No Derivative Works (only allowed to distribute unaltered copies of the work) OR derivative works allowed (but imply same license)
Option: Non-Commercial: work may not be used for commercial purposes

CC has since created additional licenses:

Some of these are for more specific cases, say,
- attribution+noncommercial+noderivative for music sharing
- license that have specific allowances, such as sampling from the music, but not reproducing the whole
- ...and more.
Encapsulations (why?(verify)), such as:

There are

See also:

GNU Free Documentation License (FDL, GFDL)

The FDL (a.k.a. GFDL) applies to text rather than source, and was created partly because some GPL terms are specific to source and hard to apply to text. The FDL also pays more attention to the more physical nature that documentation, books and such may 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 the ability to use other FDL'd content. FDL is 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 a Creative Commons license.

See also:

Comments:

Gnu Simpler Free Documentation License (GSFDL)

A license, currently (2009) in draft (2006 version), based on the GFDL, apparently created to serve uses that are restricted mostly by Cover Texts and Invariant Sections requirements.

See also:

FreeBSD Documentation License

A permissive license. Rather like the BSD license, but for text.

See also:

http://www.freebsd.org/copyright/freebsd-doc-license.html

Free art license (Licence Art Libre)

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

See also:

http://artlibre.org/licence/lal/en/

Apple's Common Documentation License

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Lesser General Public License For Linguistic Resources (LGPLLR)

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Meant to keep data for (computational) linguistics open for use, and keep its derivatives similarly open.

Design Science License (DSL)

A license meant for sharing scientific data, images and such rather than text or source.

Open Publication License (OPL)

May be used in free or non-free form, and has some restrictive options.(verify)).

From the Open Content Project, which now seems to recommend CC.

See also:

Open Content License

Somewhat restrictive, mostly monetary.

Arguably replaced by the Open Publication License.

See also:

http://opencontent.org/opl.shtml

Project Gutenberg License

This article/section is a stub.
It is probably here to start gathering information. May contain just a few notes thrown together, is probably incomplete, may mean the writer isn't happy with the quality yet, and parts may well be wrong. Feel free to add notes, suggestions, and/or rewrite sections or the whole into something better, particularly if something doesn't seem clear to the apparently intended audience.

Refers to the overall license applying to Project Gutenberg - which mostly notes that public domain laws differ between countries, and explains copyright details that may apply to some resources -- note that PG has roughly two types of resources:

public domain resources
- which technically come with the non-public-domain Project Gutenberg trademark and license. You either abide by these, or strip any reference to PG from the text (for a fully public domain resource)
- some may have additional restrictions (verify)
copyrighted resources that authors gave to the project (mostly for ease of distribution), which are usually under more specific terms.

The exact details of a resource are explained in a summarizing blurb that comes with the text.

See also:

http://www.gutenberg.org/wiki/Gutenberg:The_Project_Gutenberg_License

See also

Lists of licenses with comments:

Just lists:

Open Source Initiative OSI - Licensing

Wikipedia articles on...

Other discussions, comparisons and comments:

Unsorted:

Retrieved from "http://helpful.knobs-dials.com/index.php/Intellectual_Property%2C_Copyright%2C_and_related_rights"

Views

Personal tools

Create an account or log in

Search

Toolbox