Graham Percival wrote: > There's a *ton* of other janitorial work to be done, especially by > people who have proven that they're willing to do work (about 50% > of people who say "hey, I want to help out" never do anything!). > And not only that, but you're capable of using git! There's lots > of stuff that needs doing for the new website, for example.
OK. I have not been following those discussions closely but if you can give me a rough todo list I will see what I can contribute in that respect and prioritise it over any copyright work. I also have to get back to the contemporary music documentation, which I've been neglecting ... > If you really want to keep on doing copyright stuff, then I'd > suggest that you look into the licenses of the projects which > lilypond *links* to. Stuff like ghostscript doesn't matter, since > we only call it on the command-line. But it would be good to > know, for example, what license guile 1.8 is under, if they > changed to GPLv3 when did it happen, etc. Yes, I think that's a good idea and will start tracking those things. Guile I think is LGPLv3 although parts may be GPL -- but that's only for the current development release (i.e. 1.9.x). 1.8.x is still under LGPLv2+. > I'm pretty certain that we're fine right now, but as more and more > projects switch to GPLv3, we might suddenly discoved that we can't > link to pango or freetype or something like that. It would be > great if we had a list of such projects, so that if/when we > seriously discover any license switch (again, in a few months) we > have that info handy. That was one of the motivations for tracking who was OK with GPLv2+ -- to have an advance list of people ready for such an eventuality. > There's no dual-licensing of doc contributions. Docs are > currently FDL 1.1 or later (sigh). Code is GPLv2. Exceptions to > this (such as cary.ly) should be remedied. Just tracking willingness, rather than proposing a change. It seemed worthwhile to see who would sign up for the Debian maintainer's proposal of dual-licensing the docs. On the broader scheme of things I'm going to keep tracing the contributors to individual files (but not with incredible speed). Besides any usefulness for Lilypond I have a vested interest which has nothing to do with Lilypond or licensing per se, but relates to a project that stems from my day job: http://project.liquidpub.org/ http://github.com/WebDrake/liquidpub-dvcs https://code.launchpad.net/~webdrake/liquidpub/peer-review ... so learning about tracing/tracking contributions and contributors in a version control system is interesting to me anyway, and since it's unlikely to HURT Lilypond and might be of some use, I might as well follow that interest ... :-) Best wishes, -- Joe _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel