GOP2-1 - LilyPond is part of GNU (probable decision)

[Graham Percival]

Much nicer formatting in the online html:
http://lilypond.org/~graham/gop/gop_2.html


*** Summary

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.


*** Not optional

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.


*** Project 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.
Copy ranges are only acceptable if every year is really a
“copyrightable” year and if the README file details this usage.
Must use the “or any later version” license.
Copyright headers for each file do not need to include everybody
who edited the file, only the main copyright holder(s).
        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


*** Project Recommended
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


*** Maintainer required

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      


- Graham