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

[Janek Warchoł]

What happened to the formatting of this email?  It looks like section
numbers are in wrong places and generally i'm getting lost while
reading.  If you have it in a text file or something, could you send
it as an attachment?

cheers,
Janek

On Tue, Jun 19, 2012 at 2:32 PM, Graham Percival
<address@hidden> wrote:
> *** 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
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel