OSS Watch Licence Differentiator

This tool attempts to help its users understand their own preferences in relation to free and open source software licences. It is no substitute for reading the licences themselves, and before placing any of your property under one of these licences, it is essential that you fully read and understand your chosen licence. The classifications of licence type that enable this tool to work are by necessity somewhat reductive, and therefore output of this tool cannot and must not be thought of as legal advice.

Choice One

Do you want to limit the results to licences that the Open Source Initiative describe as being "popular and widely used or with strong communities"? This will guarantee that the licence will be 'mainstream' at the possible expense of some more esoteric but possibly useful characteristics.

Choice Two (a)

All Free and Open Source licences will allow others to make modified versions of your code, and to make these modified versions available to others. Your licence can make conditions about how this happens - specifically what licences can be used on these modified versions. These conditions can help keep your code free, but they can also put some people off reusing your code.

Do you want to include licensing conditions on reuse? If not, your licence will be one of the so-called 'permissive' licences.

Choice Two (b)

This question is only if you chose to include licensing conditions on reuse.

You chose to include specific licensing conditions on reuse. Sometimes these are called 'copyleft'. Copyleft comes in two basic varieties:

Strong Copyleft: When a software project contains some of your code, the project as a whole must be distributed under your licence, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available.

Weak Copyleft: When a software project contains some of your code, the parts of the project you originated must be distributed under your licence, if it is distributed at all. Other parts may be distributed under other licences, even though they form part of a work with is - as a whole - a modified version of your code. The effect of this will be that the source code to some additions made to the code may not be available.

In case you chose to include licensing conditions in the previous question: Which form of copyleft do you want?

Choice Two (c)

This question is only if you answered 'Weak Copyleft' in the previous question.

We defined 'Weak Copyleft' - as a reminder - this way:

Now we need to decide which parts of the modified version we will allow to bear a different licence:

Module Level: Each functional sub-section ('module') of code within the project is considered separately. Where a module contains some of your code, it must bear your licence. Where it does not, the author of that code gets to choose their own licence.

File Level: Each collection of code and data that is distinct according to the computer's file system ('file') within the project is considered separately. Where a file contains some of your code, it must bear your licence. Where it does not, the author of that code gets to choose their own licence.

Library Interface Level: Your code is a software library - a collection of software functionality which is usable by other programs via an agreed interface. Modifications of your library must bear your licence, if they are distributed. Programs that use your library, and are perhaps distrbuted with it included, need not use your licence.

In case you chose 'Weak Copyleft', which form of weak copyleft do you want? We need to decide which parts of the modified version we will allow to bear a different licence.

Choice Three

A 'jurisdiction' refers to a specific location or territory and its system of law. Where a licence specifies a jurisdiction, the licensor and the licensee(s) agree that the terms in the licence are to be understood in reference to that jurisdiction's law and that legal action resulting from breach of the licence's terms will take place in that jurisdiction. So, for example, if a UK person licenses some of their code under the Mozilla Public License v1.1 and then discovers that someone is using that code without abiding by the licence conditions, they would have to bring a legal action against that person in "the Federal Courts of the Northern District of California, with venue lying in Santa Clara County, California". Note, though, that traditionally free and open source software owners do not tend to seek monetary damages from those who infringe their licensing terms, but instead to request that the infringer either starts abiding by the terms or terminates their use of the code in question. For these purposes it is often unnecessary to resort to actually taking an infringer to court, particularly if they have a public profile and reputation to protect. Often simply requesting compliance can be effective, and if that fails, publicising the infringement can help achieve compliance.

Not all free and open source software licences specify a jurisdiction. In fact most are silent on the subject. In these cases any jurisdiction can be selected when and if necessary, although it is quite possible that the person you are trying to take to court will either ignore you or dispute your choice of location if it does not suit them.

Finally some free and open source software licences state that the jurisdiction is either up to the licensor or automatically that of the licensor (where they reside or principally do business).

How would you like your licence to handle the issue of jurisdiction?

Choice Four (a)

Do you or your institution own any software patents? If you do, and you release some code that embodies them under a free or open source software licence, then you are very likely granting rights to use the relevant patent (in connection with that code) to a large group of people - even if the licence does not explicitly say so. In many jurisdictions, for example the UK and the US, licensing someone to take a particular action (like copying or adapting your code) also impliedly licenses them to take all other steps necessary to take that action. These impliedly licensed steps would almost certainly include use of your embodied software patent. It should be noted that people who adapt your code cannot expand its functionality to capture other software patents of yours - you grant rights only to the patents embodied in the code you released, not any subsequent form the code may take.

Some free and open source software licences say nothing on the subject of patent grants - although as noted above this may not mean that they grant no patent rights.

Some free and open source software licences explicitly grant patent rights necessary to use, adapt and distribute the software.

What is your attitude to the issue of patent grants in relation to your desired licence?

Choice Four(b)

Your free or open source software licence can include what is sometimes called a 'patent retaliation' clause. These sections of a licence essentially say that anyone who brings legal action alleging that the licensed software embodies one of their software patents will lose the licence you have granted to copy, use, adapt and distribute the code. It is intended to dissuade people from bringing this kind of legal action.

What is your attitude to patent retaliation in your desired licence?

Choice Five

All free or open source software licences specify that anyone who distributes or adapts the software must give credit to the original authors of the software somewhere in their distribution. Some free or open source software licences go further than this, and specify that the credit must take a particular form and appear in specific instances, for example on the software's user interface every time it is run. This kind of stipulation is sometimes called 'enhanced attribution' or 'badgeware'.

Do you want your licence to specify enhanced attribution?

Choice Six

If someone uses your code to create an online service or an in-house solution, perhaps adapting and improving it, most free and open source software licences do not specify that the source to the adapted or improved version must be released. Most free and open source software licences make it a condition of distribution that source code be released, and generally neither making services available over a network using the code or deploying the code within a single institution are defined as distribution within these licences. Some within the free and open source software community feel that this phenomenon, sometimes called the 'ASP (application service provider) loophole' or 'privacy loophole' needs to be fixed. Their argument is that fairness dictates that all those who benefit from the code must contribute their work back to the world, even if they are not strictly speaking distributing the code.

To address this issue, some free or open source software licences make release of the source code a condition not only for distribution but also for internal deployment and/or making services available over a network using the software. These kind of conditions are therefore particularly suited to code which is likely to be used in-house or as a basis for a networked service.

Do you want your licence to address the 'privacy loophole'?

Choice Seven

Some free and open source software licences explicitly forbid the use of the authors' names to promote a product or service based upon the authors' code.

Do you want your licence to include such a 'no promotion' feature?

Summary

This is your selection:

You haven't made any choices yet.

Licence differentiator