User:Svetlana

Please note that this page is still under development.

Software needs to meet the free software definition to be listed at the Free Software Directory. Rules of thumb:

• All links and homepages of projects should point to free software and free documentation.
• If a software program runs on proprietary operating system, then the version of the program that runs on free software operating system should be as good or better.
• The software program itself should not package any program-data, art assets loaded by the program, or software which is under a nonfree license. If art or data is available for the game under a nonfree license but not packaged directly with it, that is a different matter and one we should be more flexible about.
• Contact address for contributors should only be listed if they also appear publicly in a prominent and public manner on a website directly related to the project — we don't want generate more spam for free software authors.

Below is the (in progress) checklist for determining whether a submission meets the standard to be included in the Directory. There are two steps involved:

1. Code licence check (including authorship and dependencies)
2. Documentation licence check

1. Code license

Note: MAME's license prohibits commercial use. This means that nothing which depends on MAME should be added to the Directory. This is also true for xmame and sdlmame.

Normal Projects

(edge cases will be dealt with below)

• If there is one, take a look at the README file. It often contains dependency notes, project history, licensing policy and other info that can tell you right away whether or not you are dealing with free software. The same can be true for files like RELEASE or RELEASE NOTES.

• Look for a license. Hopefully, it will be right at the top of the program's directory in a file called "LICENSE" or "COPYING" or even "GPL" but this is merely convention. Developers can put the license anywhere and call the file containing it anything. If it's not at the top look for a directory called doc (short for documentation.) If you have a file that you believe is GPL'ed but you can't find the license and want something more precise to grep than the word 'copyright' you can try 'coon' for GPL2 or 'affero' for GPL3

• If it is one of our licenses, look it over to make sure it's complete. A word count is a good way to catch altered or truncated licenses. If it has been altered, you can ask the maintainers if they edited the license on purpose, (usually they didn't.) They'll probably offer to fix it and then you can list the project. Of course, you can also skip the correspondence and just not list the project.

• If it's not one of our licenses, check it against our list here, http://www.gnu.org/licenses/license-list.html to see if it's a free software license. You'll also be able to check to see if it's compatible with any of our licenses.

• After you seem to have a piece of software under a free license, then you'll want to check that the whole program is actually using that license or some combination of free and compatible licenses. It is not OK to use non-free software modules and then just slap a GPL on the top of the package.

Here are a few ways to check for problems:

look for a subdirectory called lib, this is where libraries reside. Libraries are often added in toto from other projects and that means they often come with their own license. (Although less common, the same goes for any subdirectories entitled "resources" "tools" "plugins" or "modules.") If the lib license is free and compatible, then there's no problem. If it's not compatible or it's a proprietary license, then we have a problem.

look in the file called src, there may be other licenses in there too.

grep for 'copyright' to see what some of the program headers say. A typical header will reference the license and may mention how you're allowed combine it with other files and if you may upgrade the license. If the headers reference non-free licenses then we have a problem.

try grepping 'java' or 'commercial' or 'proprietary' just for fun.

What about a whole bunch of binary files that you can't open? Try grepping the name of the file or subdirectory and you may find a license that only pertains to the binary files.

Red Flags

These issues make a program non-free.

• Unlicensed sources files.

• Restrictions on private use, ie: you can only use this software with our other software, with our online service or to do one specific task/or anything EXCEPT one specific task or type of task

• "non-transferrable" any license that says you may not share the software is non-free. An "exclusive" license is also a red flag.

• Not mentioning sharing or changing. A free license must proactively say you are allowed to share or redistribute, convey, give to others, etc. It must also proactively say that you are allowed to modify it, change it, etc.

• Loads of binary files in what is supposedly "source" without the files to create those binaries.

• "non commercial or academic purposes only" any license that prevents you from charging $$ for distribution (modified or not) is not free.

• Central control ie: requiring notification or publication of changes

• Possibility of revocation, including clauses that cover any time someone makes an accusation of patent or copyright infringement.

• Forcing acceptance of future license changes or upgrades without the consent of the user. This is why we use "or at your option, any later version"

Red Herring

These things may seem odd but they don't actually impact the freeness of a program.

• No mention of the copyright holder (necessary to report copyright violation).

• Requiring money, email sign-up or some other hurdle to getting the software in the first place.

• Expressing the wish for some kind of notification or documentation of changes, but not requiring it.

• Weird opinions about the GPL or random advice included in the header don't make the software unfree as long as they are merely opinions and not additional restrictions

• Claiming a jurisdiction for the license and not necessarily guaranteeing portability. This kind of CYA is OK, esp. since we don't know of any problems with specific jurisdictions.

• It is OK to ask people to mark and date their modifications when redistributing and even to ask people to say why they've made their modifications, ie: Qhull's license

Edge Cases

This is not static information. Policies about adding non-free code obviously don't change, however the way projects are licensed or the way they interact each other is definitely subject to change.

• Free programs for accessing specific non-free data that ought to be free: There are programs that are designed for access to specific network services. In most cases that is not a bad thing. But there is one kind of case which we should not list. This is for programs designed to access a server to look at a specific collection of data which we could envision as a published, free work. A dictionary is an example of this. You could very well have a copy of a free dictionary on your machine. Thus, a program to access a non-free dictionary on a web site is a way of making a non-free dictionary seem acceptable. So please don't list programs like that. If more cases like this come up, we should talk about them.

• If software is freely licensed but is bundled with artwork that is not, do we consider the program to be free? From RMS "Images and sounds need to be free if they are essential parts of the software. But if they are just decoration, and easily replaced, then they do not have to be free." Sound and artwork fall into the category of essential for interactive games. Logos on otherwise utilitarian projects do not.

• Export clauses. It is OK for the copyright-holder to disclaim responsibility for any problems the user encounters in attempting to export the software. It not OK for the copyright-holder to require compliance with export laws as a condition of use. There are lots of sneaky ways to phrase things and the interpetations of these stipulations are evolving so if you have any question about an export clause, take it to the compliance officer.

• Indemnify? It is OK for a license to require distributors, who are offering some kind of warranty to their recipients, to indemnify the program's other developers. See the Apache License version 2, Common Public License, and Eclipse Public License. It is not OK for a license to require all users to indemnify the developers; the original Squeak License does this.

• Requiring the preservation of logos in redistributions/derivative works is a tricky issue. We're okay with it to a limited extent, but we don't want that preservation to become so difficult that it interferes with the four freedoms. It's a good sign if the license puts limits on the logos' display: the Common Public Attribution License is a good example of something along those lines that we accepted. It is not OK if the license just says that you have to preserve the logo, without any additional conditions or explanations. If you see something like this that's unfamiliar, take it to the compliance officer.

2. Documentation license

1. We don't include projects that contain non-free documentation.
2. We can include projects that have links to non-free documentation on their websites, but we don't include those links in our entry
3. Documentation that doesn't claim a specific license is assumed to be "generic copyright" which is non-free
4. Short notes that are included in the package and are not preceded by a copyright notice, ie: README files are OK