GOP-PROP 2-1: LilyPond is part of GNU

[Graham Percival]

Here's the first "main" policy point in GOP 2.  For those
unfamiliar with GOP, here's a quick summary:

- to hopefully avoid or reduce "fluffy" discussions, policy
  questions are only introduced after there's a decent amount
  of gathering background information.
- Topics will be introduced by Graham. He will put an agenda for
  the next month (or so) on http://lilypond.org/~graham/gop/
- Emails about policy questions will begin with GOP-PROP in the
  subject line. Adjust your email filters accordingly, depending
  on whether you are interested or not in such discussions. 
- There should be no surprises, no time pressure, etc. If you are
  particularly concerned about a decision but lack time/energy to
  join the discussion, just say so and we will postponed the
  decision. I want to have clear, final, unambiguous decisions; if
  that takes a long time, so be it. 
- For each policy question, there will be at least one week for
  free-ranging discussion. At that point, Graham will summarize
  the discussion and announce a "probable decision". We will then
  have one more week to let people point out flaws in the summary,
  make additional arguments, etc. 


GOP2-1 - LilyPond is part of GNU
http://lilypond.org/~graham/gop/gop_2.html
(nicer formatting in the html version)

*** 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/maintain.html

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 implications for LilyPond
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)
Hopefully we can automate this process to some degree with git?
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). Using a minimal form (such as
in Emacs and Elisp manuals) is ok. “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). 6.5
This will take at least 10 hours to implement.
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.
keep backups of source files, but git is sufficient for this    10      
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
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    
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.
do not recommend any non-Free programs, nor require a non-free
program to build        13      I’d better check the licenses of
the “Easier editing” programs.
do not refer to any non-Free documentation for Free software    13
I think we’re fine here
do not use the term “open source”, instead of “Free software”
14.1    German website main page not in compliance.
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.


*** Project Recommended

Requirement     Source  notes and questions
assign copyright to FSF (this adds a bunch of obligations not
listed in this document)        6.1     we’re not going to do
this.
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.
use ftp.gnu.org for official source releases    11.3    would
require 10 hours of work; not worth it IMO
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
post release announcements on the savannah project site
would take 5-10 hours to set up
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?
make a diff between releases    11.2    let’s not bother;
interested parties can make a diff themselves from git.
manuals should be listed at http://www.gnu.org/manual as well as
our own website 12.3    points to old website docs; I need to find
out how to update this link.
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.”      (email to new maintainers, not in the
guide yet)      


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