| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
LilyPond has been a member of the GNU project for longer than I’ve been involved (2001), but there’s a few policies for which we aren’t in full compliance. We should remedy this.
Some of these policies may raise questions from LilyPond developers, but I’d like to eliminate certain questions or debating positions right off the bat. LilyPond is GNU software. Meeting the requirements of GNU software is not optional (at least, it should not be optional). I realize that we haven’t always done this, so I’m suggesting that we should only enforce these after 2.16 is out. But they definitely should be enforced. We’ve benefitted from GNU hosting, mailing lists, publicity, and GSoC umbrella organization-ness.
I am very option to suggestions that I (or Mike, who helped me with this) misread or mis-summarized their policy document, or suggestions that we can meet the obligations in other means. But I think we should start from the basis of “is this an accurate reflection of their policy document?” and “what is the best way to follow these requirements?”, not “do we want to bother?”.
http://www.gnu.org/prep/maintain/ http://www.gnu.org/prep/standards/ |
In case somebody has the most extreme disagreement with GNU policies, I will clarify that LilyPond is published under the GPLv3 (and FDL 1.3+), which gives you the freedom to fork the source code and run a separate project not affiliated with GNU, provided that you abide by the copyright licenses. Nothing in this list impinges on your Freedom to do so – in fact, one of the underlying themes of these policies is to maximize people’s ability to do so.
I’ve separated the policies into project Requirements, project Recommended, and maintainer Requirements.
| Requirement | Source | questions and comments | Work required? |
|---|---|---|---|
| All authors of more than 15 lines of code need to be listed somewhere. | 6.3 | can we cover this requirement by pointing people at the git
history? (answer: maybe for full source, but not for tarball)
It is acceptable to auto-generate this for the tarball; emacs uses a small elisp function to generate AUTHORS based on the Changelog. git shortlog or git log --all --format='%aN' | sort
-u looks like a good starting point. | Yes, auto-generate this for tarball |
| Must have a copyright notice for all files longer than 10 lines, including documentation, supporting files, images and sound files (if the metadata allows this, or in a README or similarly-named file in the same directory if not). | 6.5 | Using a minimal form (such as in Emacs and Elisp manuals) is ok: @c This is part of the GNU Emacs Lisp Reference Manual. @c Copyright (C) 1990-1994, 1999, 2001-2012 Free Software Foundation, Inc. @c See the file elisp.texi for copying conditions. “Recursive” permissions (i.e. “everything in this directory
tree” are not ok.
| Yes, at least 10 hours. |
| All features must work on GNU/Linux; other operating systems are optional | 8 | nothing stops us from also requiring features to work on other operating systems, so Windows and OSX users don’t need to panic. | no |
| keep backups of source files, but git is sufficient for this | 10 | no | |
| on self-hosted websites, ensure that the site runs on Free software alone. (unreleased custom software is ok) | 12.2 | AFAIK lilypond.org is ok | no |
| don’t link to a website about lilypond, which the public might perceive as connected with it and reflecting the position of its developers, unless it also runs on free software. (unreleased custom software is ok) | 12.2 | no | |
| avoid patented technologies as specified by GNU. For example, mp3. | 13 | There is no definitive list of such patent-crippled things, rather this is a general reminder to avoid things which are known to be crippled. | no |
| do not recommend any non-Free programs, nor require a non-free program to build. Do not grant legitimacy to non-free programs by discussing them. | 13, coding standards 8 | I’d better check the licenses of the “Easier editing” programs.
More context.
“A GNU program should not recommend, promote, or grant legitimacy to the use of any non-free program. Proprietary software is a social and ethical problem, and our aim is to put an end to that problem...” “When a non-free program or system is well known, you can mention it in passing... However, you should give only the necessary information to help those who already use the non-free program to use your program with it -— don’t give, or refer to, any further information about the proprietary program, and don’t imply that the proprietary program enhances your program, or that its existence is in any way a good thing.” “If a non-free program or system is obscure in your program’s domain, your program should not mention or support it at all...” FIXME: I’m currently checking if this applies to “web software”. | maybe |
| do not refer to any non-Free documentation for Free software | 13, coding standards 8 | I think we’re fine here.
Exception to the rule: “...So GNU packages should never recommend non-free documentation. By contrast, it is ok to refer to journal articles and textbooks in the comments of a program for explanation of how it functions, even though they are non-free.” | no |
| do not use the term “open source”, instead of “Free software” | 14.1 | German website main page not in compliance. | yes |
| do not write “Linux”, instead write “GNU/Linux” (unless we are specifically talking about the kernel) | 14.2 | the download pages on the website need to be fixed. | yes |
| Do not refer to proprietary programs | coding standards 2.1 | This seems aimed at the algorithms and implementations of proprietary programs. | no |
| Do not include any trademark acknowledgements. | coding standards 2.3 | “What is legally required, as regards other people’s trademarks, is to avoid using them in ways which a reader might reasonably understand as naming or labeling our own programs or activities.” | no |
| Do not use trigraphs in C code. | coding standard 3.4 | :-) | no |
| Requirement | Source | notes and questions | Work required? |
|---|---|---|---|
| assign copyright to FSF (this adds a bunch of obligations not listed in this document) | 6.1 | we’re not going to do this. | no |
| Thank everybody who reports a bug, but no requirement to help users directly instead of improving code | 9.3 | I think the Bug Squad already does this, but maybe add it to the
Bug Squad checklist? :)
Also, remind the two grumpy developers that they shouldn’t reply to bug reports unless they feel amazingly un-grumpy that day. | maybe |
| use ftp.gnu.org for official source releases | 11.3 | would require 10 hours of work; not worth it IMO | no |
| announce stable releases on info-gnu | 11.6 | do-able if somebody makes a list of places to announce new stable releases. http://code.google.com/p/lilypond/issues/detail?id=1719 | yes |
| post release announcements on the savannah project site | would take 5-10 hours to set up | no | |
| web pages should include manuals in HTML, DVI, Info, PostScript, PDF, plain ASCII, and Texinfo format (source) | 12.3 | Ouch. dvi, postscript, and plain ASCII? | no |
| make a diff between releases | 11.2 | let’s not bother; interested parties can make a diff themselves from git. | no |
| manuals should be listed at http://www.gnu.org/manual as well as our own website | 12.3 | no | |
| if feasible, use Guile for extensions, although “For some programs there’s a reason to do things differently, but please use GUILE if that is feasible.” | coding standards 3.1 | no |
These apply to the GNU maintainer(s) personally, not for normal project members.
Role of GNU maintainer (section 5):
... you cannot expect all contributors to support the GNU Project, or to have a concern for its policies and standards. So part of your job as maintainer is to exercise your authority on these points when they arise. No matter how much of the work other people do, you are in charge of what goes in the release. When a crucial point arises, you should calmly state your decision and stick to it.
| Requirement | Source | notes and questions |
|---|---|---|
| get an account on fencepost.gnu.org | 3 | |
| inform GNU when stepping down | 4 | |
| if using savannah, subscribe to savannah-announce mailing list | 10 | |
| in interviews and speeches in your role as GNU maintainer, don’t include advertisements for any company, product, or service. (previous rules about “open source” still apply) | 15 |
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Graham Percival on September 22, 2012 using texi2html 1.82.