Difference between revisions of "Free Software Directory:Workflow"

From Free Software Directory
Jump to: navigation, search
(If software is freely licensed but is bundled with artwork that is not, do we consider the program to be free: formatting)
(Reviewing new submissions: about rejecting)
Line 37: Line 37:
* [[:Category:Reviewed]]
* [[:Category:Reviewed]]
If you change the review field to say "yes," then this will happen automatically.
=== Rejecting a submission ===
If you conclude that we can't admit a submission into the Directory, then change the status to reviewed and add your comments explaining why (nicely) below the template. See http://directory.fsf.org/wiki/Review:0_A.D.-REV-ID-1 for an example.
=== Checklist to see if new entry should be added ===
=== Checklist to see if new entry should be added ===

Revision as of 14:07, 13 August 2012

Bugs and suggestions

Requested updates to existing submissions get categorized as "Bug report":

When completed, the category gets changed to "Bug report-done"

Updating existing submissions

To update an existing submission, go to the page and click edit with form.

Some important things to do when updating a submission:

  • In the Documentation note and Version comment fields, make sure all URLs are formatted as external links. Simply pasting the URL is bad because it does not create a clickable link and because long URLs create formatting errors due to poor line wrap support.
  • Make sure IRC channels are formatted as URIs in the formatted like such: irc://irc.gnu.org/channelname — notice that the hash tag of the channelname is optional.
  • The Submitted by and Submitted date should only be edited the first time a project is submitted.
  • If you are making a very minor change, do not bother updating the Last reviewed fields. However, if you are updating the software to indicate a new version has been released or have improved it in other substantial and interesting ways, make sure you updated the Last reviewed by and Last reviewed date. This will add it to an RSS feed of recent updates.
  • The licensing section deserves its own wiki page, but for now:
    • When updating license info for a package, please ask another FSD administrator to review your work. (You can do that either via a checkbox on the review's "Edit with form" tab, or via the Bug update form). Also, if you do update the license info or have confirmed that it is correct in a newer version, be sure to update the License reviewed by and License reviewed date fields for that package.
    • When updating an existing package in the Directory, if you suspect the package has changed and become proprietary software, then this should be flagged for urgent review immediately. Also, contact another administrator letting them know about the situation.
    • If you are having trouble updating or checking the license for a package, don't let this halt updating other aspects of the package's information. Simply update the information you can and then either update the existing Bug in the Review: namespace or create a new Bug that states the package license info needs to be checked and updated.

Reviewing new submissions

New submissions are done through the form "Form:Submit":

Submissions are moved into New submissions get categorized as Review:

When review is complete the category is changed to Reviewed

If you change the review field to say "yes," then this will happen automatically.

Rejecting a submission

If you conclude that we can't admit a submission into the Directory, then change the status to reviewed and add your comments explaining why (nicely) below the template. See http://directory.fsf.org/wiki/Review:0_A.D.-REV-ID-1 for an example.

Checklist to see if new entry should be added

This is the (in progress) checklist for determining whether a submission meets the standard to be included in the Directory.

Code license

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.

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

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


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

Publishing new submissions

Please note: When publishing a new entry to the Free Software Directory, please make sure that it meets our requirements, and that another administrator who is experienced in publishing new submissions to the directory reviews your work.

Moving from Reviewed to published

To move a page from being reviewed to being published, you should move the submission page to a new page within the Main namespace of our wiki (i.e., 'directory.fsf.org/wiki/').

Edit the new submission in the main namespace and make sure that the first template is named "Entry". If the page does not appear to be formatted correctly, you may have to change the line from "{{Entry2" to read "{{Entry". Once you have saved, you should be able to edit this page using the Edit with form tab. At this point you can go through and fill out any fields that were not available for editing through Form:Submit.

Publishing new submissions directly

If a new submission is not being moved from the Review namespace, you can create it through Form:Entry.

Organization of FSD

Here are some of the pages that an admin will find useful.



  • Form:Submit: Anyone with a user account can submit a package for review
  • Form:Entry: Admins can use this to create new project pages

When editing a page, you have the option of using "Edit" or "Edit with Form". The first allows you to see the source code of the page and offers more flexibility, whereas the second one presents you with a convenient form layout, displaying and allowing you to edit current values.

At the top of pages in the Review: namespace is a link that will allow you to create or edit pages without typing URLs. Currently, making changes on official entries involves manually typing in what you have found, or copying and pasting basic info from user-submissions. To avoid copyright infringement, and to allow us to release the directory under the FDL, please use your own wording for program descriptions.

Site development

These links are useful for people working on fixing and brining new features to the directory:

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the page “GNU Free Documentation License”.

The copyright and license notices on this page only apply to the text on this page. Any software or copyright-licenses or other similar notices described in this text has its own copyright notice and license, which can usually be found in the distribution or license text itself.