Difference between revisions of "Free Software Directory:Workflow"

From Free Software Directory
Jump to: navigation, search
(Red Flags: formatting)
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
+
'''NOTE: This page is out of date. Please see a note on our latest [[Free_Software_Directory:Participate|approval system]]. This page remains because we are still in the process of cleaning-up the existing bugs and new submissions described below.'''
  
== Bugs and suggestions ==
+
== License concerns ==
Requested updates to existing submissions get categorized as "Bug report":
 
  
* [[:Category:Bug_report]]
+
'''Please note:''' When publishing a new entry to the Free Software Directory, please make sure that it meets our [[FSD:Requirements|requirements]]. If the license is not a free software license, then it should not be added to the directory. Therefore, '''check the license first!''' If you have questions about whether a program should be added, you can ask the directory-discuss@gnu.org mailing list.
  
When completed, the category gets changed to "Bug report-done"
+
* If you conclude that we can't admit a entry into the Directory, then change the status of relevant submissions to "reviewed" and add your (nice) comments explaining why above the template. See [[Review:0_A.D.-REV-ID-1]] for an example.
  
* [[:Category:Bug_report-done]]
+
=== When updating an existing entry ===
  
=== Updating existing submissions ===
+
* When updating license info for a package, please make sure it meets the FSF's [[FSD:Requirements|requirements]], and ask another FSD administrator to review your work. (Either click the right checkbox on a bug report's "Edit with form" tab, or file a bug report with "Problem with this listing?" at the bottom of the project's page). Also, if you update the license info or confirm 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 report, or create a new bug report that states the license info needs to be checked and updated. Note that this applies to ''updating'' a license, not ''adding'' a new project to the directory.
  
To update an existing submission, go to the page and click edit with form.
+
== Types of contribution ==
  
Some important things to do when updating a submission:
+
* [[Form:Entry]]: Admins can use this to create new project pages. (see below.)
 +
* [[Form:Submit]]: Anyone with a user account can ask for a package to be added to the directory.
 +
* Anyone with a user account can file a bug report, using one of the links on entry pages.
  
* 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.
+
== About editing with forms ==
* 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 [http://directory.fsf.org/wiki/Form:Bug_update 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 ==
+
At the top of pages in the Review: namespace is a link that will allow you to create or edit entries without typing URLs or entering a name into [[Form:Entry]]. Currently, to make changes to an entry's content you must type in your own sentences, and copy and paste basic info. To avoid copyright infringement, please use your own wording for program descriptions.
New submissions are done through the form "Form:Submit":
 
  
* [[:Form:Submit]]
+
When you want to edit 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, allowing you to edit current values.
  
Submissions are moved into New submissions get categorized as Review:
+
=== Entry editing tips and guidelines ===
  
* [[:Category:Review]]
+
There is a manual that describes the meaning of each field in Form:Entry: [[FSD:Workflow/Entry|Guide to Form:Entry]]. It also marks which fields are important or required.
  
When review is complete the category is changed to Reviewed
+
== Bugs and suggestions ==
 +
''Requested'' updates to existing submissions get categorized as "Bug report":
  
* [[:Category:Reviewed]]
+
* [[:Category:Bug_report]]
  
=== Checklist to see if new entry should be added ===
+
When completed, the category gets changed to "Bug report-done"
  
This is the (in progress) checklist for determining whether a submission meets the standard to be included in the Directory.
+
* [[:Category:Bug_report-done]]
  
==== Code license ====
+
If you edit a bug report using "edit with form", you can mark the it as having been reviewed. This changes the category automatically.
  
===== Normal Projects =====
+
== Viewing submissions (requests) ==
 +
New entry creation ''requests'' (submissions) are created with "Form:Submit":
  
(edge cases will be dealt with below)
+
* [[:Form:Submit]]
  
* 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.
+
Submissions are in the 'Review' category
  
* 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 
+
* [[:Category:Review]]
  
* 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.
+
After you actually add an entry to the directory through [[Form:Entry]], edit the "Finished review=No" field to say "Yes", to change category to 'Reviewed'.
  
* 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.
+
* [[:Category:Reviewed]]
  
* 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.
+
If you accept the submission and add it to the Directory, it is nice to email the person who submitted it and let them know it is there now. You might mention the weekly IRC meetings and see if they are interested in helping us maintain this entry and others. You can set the reply-to address as <directory@fsf.org> if you like.
 
 
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 <b>option</b>, 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 juridiction for the license and not necessarily guarranteeing 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 ======
 
 
 
The information and policies on edge cases come from several sources; conversations with RMS, with Brett, with Management, from writings on our website, etc. 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.
 
 
 
I expect that cases like this are rare, so if you see one,
 
let's talk about it further. (from RMS, 6/21/2008)
 
 
 
 
 
*  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.
 
 
 
==== Documentation ====
 
 
 
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 [[FSD:Requirements|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|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|Form:Entry]].  
 
  
 
== Organization of FSD ==
 
== Organization of FSD ==
  
Here are some of the pages that an admin will find useful.
+
Here are some pages that an admin will find useful:
  
=== Categories ===
+
=== Categories mentioned above ===
  
 
* [[:Category:Review]]: Submissions for (usually) new packages
 
* [[:Category:Review]]: Submissions for (usually) new packages
 
* [[:Category:Reviewed]]: Submissions that have been processed
 
* [[:Category:Reviewed]]: Submissions that have been processed
 
* [[:Category:Bug report]]: User submitted bugs and suggestions
 
* [[:Category:Bug report]]: User submitted bugs and suggestions
* [[:Category:Bug_report-done]]: Update requests that have been processed
+
* [[:Category:Bug_report-done]]: Processed bug reports
 +
 
 +
=== Not mentioned above ===
 +
 
 
* [[:Category:Alert]]: Packages that have been marked as containing non-free software or using non-free documentation
 
* [[:Category:Alert]]: Packages that have been marked as containing non-free software or using non-free documentation
 
* [[:Category:Alert-done]]: Packages marked as non-free that have been processed
 
* [[:Category:Alert-done]]: Packages marked as non-free that have been processed
Line 182: Line 75:
 
* [[:Category:Documentation]]: All documentation pages
 
* [[:Category:Documentation]]: All documentation pages
 
* [[:Category:Test]]: Test pages
 
* [[:Category:Test]]: Test pages
 
=== Forms ===
 
* [[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 [http://www.gnu.org/copyleft/fdl.html FDL], please use your own wording for program descriptions.
 
  
 
=== Site development ===
 
=== Site development ===
Line 199: Line 84:
 
* [[FSD:Features]]: Potential site improvements
 
* [[FSD:Features]]: Potential site improvements
  
 +
=== Free Software Distros ===
 +
 +
Some places to coordinate work specific to [http://www.gnu.org/distros/free-distros.html free software distros].
 +
 +
* [[FSD:Trisquel]]: Trisquel packages that should be added to the FSD.
 +
 +
Also, see [[FSD:GNU]].
  
 
[[Category:Documentation]]
 
[[Category:Documentation]]

Revision as of 11:36, 12 March 2013

NOTE: This page is out of date. Please see a note on our latest approval system. This page remains because we are still in the process of cleaning-up the existing bugs and new submissions described below.

License concerns

Please note: When publishing a new entry to the Free Software Directory, please make sure that it meets our requirements. If the license is not a free software license, then it should not be added to the directory. Therefore, check the license first! If you have questions about whether a program should be added, you can ask the directory-discuss@gnu.org mailing list.

  • If you conclude that we can't admit a entry into the Directory, then change the status of relevant submissions to "reviewed" and add your (nice) comments explaining why above the template. See Review:0_A.D.-REV-ID-1 for an example.

When updating an existing entry

  • When updating license info for a package, please make sure it meets the FSF's requirements, and ask another FSD administrator to review your work. (Either click the right checkbox on a bug report's "Edit with form" tab, or file a bug report with "Problem with this listing?" at the bottom of the project's page). Also, if you update the license info or confirm 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 report, or create a new bug report that states the license info needs to be checked and updated. Note that this applies to updating a license, not adding a new project to the directory.

Types of contribution

  • Form:Entry: Admins can use this to create new project pages. (see below.)
  • Form:Submit: Anyone with a user account can ask for a package to be added to the directory.
  • Anyone with a user account can file a bug report, using one of the links on entry pages.

About editing with forms

At the top of pages in the Review: namespace is a link that will allow you to create or edit entries without typing URLs or entering a name into Form:Entry. Currently, to make changes to an entry's content you must type in your own sentences, and copy and paste basic info. To avoid copyright infringement, please use your own wording for program descriptions.

When you want to edit 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, allowing you to edit current values.

Entry editing tips and guidelines

There is a manual that describes the meaning of each field in Form:Entry: Guide to Form:Entry. It also marks which fields are important or required.

Bugs and suggestions

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

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

If you edit a bug report using "edit with form", you can mark the it as having been reviewed. This changes the category automatically.

Viewing submissions (requests)

New entry creation requests (submissions) are created with "Form:Submit":

Submissions are in the 'Review' category

After you actually add an entry to the directory through Form:Entry, edit the "Finished review=No" field to say "Yes", to change category to 'Reviewed'.

If you accept the submission and add it to the Directory, it is nice to email the person who submitted it and let them know it is there now. You might mention the weekly IRC meetings and see if they are interested in helping us maintain this entry and others. You can set the reply-to address as <directory@fsf.org> if you like.

Organization of FSD

Here are some pages that an admin will find useful:

Categories mentioned above

Not mentioned above

Site development

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

Free Software Distros

Some places to coordinate work specific to free software distros.

  • FSD:Trisquel: Trisquel packages that should be added to the FSD.

Also, see FSD:GNU.



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.