Re: Overview of copyright issues + Debian
On Fri, Sep 11, 2009 at 01:05:35AM +0200, Joseph Wakeling wrote: > Graham Percival wrote: > > Docs have always been FDLv1.1 or later. I was thinking about > > unilaterially changing them to FDLv1.3 or later, as soon as I've > > got GUB working. > > Great, that should simplify matters A LOT. Where in the source tree is > the explicit statement of the 'or later' ... ? The beginnings of the manuals. In my restructuring, that's now in macros.itexi, although this may well move to a third macro file. Hmm, I just noticed that the copyright years are messed up... I'll fix that fairly soon. It's also visible on the first page of the pdf manuals, as comments in the HTML, etc. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortcut for creating new Staff "subclass" context?
On 2009-09-09, at 08:59 , Kieren MacMillan wrote:
Hi Dan, Neil, et al.:
Does the following help?
SoloVoice is a kind of Voice. UpperVoice and LowerVoice are kinds
of SoloVoice.
That's [relatively] self-evident. What isn't crystal clear — either
in my mind, or (IMO) in the documentation — is why the following
wouldn't work (or, perhaps better put, *what* wouldn't work if the
following were used):
\context {
\Voice
\name SoloVoice
%% \alias "Voice"
}
or alternatively
\context {
%% \Voice
\name SoloVoice
\alias Voice
}
If I understand parser.yy and output-def.cc files, it looks like
"\Voice" starts you off with a copy of the previously defined Voice
settings. If "\Voice" is absent, you start from scratch.
The context settings are saved by name. If you do not change the
name, the modified settings replace the previous settings of the
\Voice context. If you change the name, a new kind of context is
created.
I haven't looked into \alias.
--
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
2009/9/11 Francisco Vila : > Those stats are very old now. They are now up to date, just in case. http://paconet.org/lilypond-statistics/ A pity that the .mailmap file is of no effect here. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
I came up with a .mailmap file for our project that might be of help on identifying unique contributors from git log even if they have multiple email addresses. I think it is not appropriate to show it pubic[ahem] publicly; I'll send you it if you want. Main contributors are graphically visible from http://paconet.org/lilypond-statistics/authors.html Those stats are very old now. It is easy to update them, ask for it if you like them for something. Are translations in the "or later" game? -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Fri, Sep 11, 2009 at 12:47 AM, Graham Percival wrote: > wrapper code under v2/v3 to expose the pubic interface or whatever > it is that people who do this kind of stuff do. I don't have that > kind of a hobby. :) What's that for a hobby? "Exposing the pubic interface"? Sounds a bit hairy to me... :-) By the way, how do you want your comic book? :-p Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Thu, 10 Sep 2009, Graham Percival wrote: > On Wed, Sep 09, 2009 at 03:36:39PM -0700, Don Armstrong wrote: > > (There are a significant number of files distributed in lilypond which > > are under v2 or later, or v3 or later, as well as things like > > input/mutopia/claop.py, which isn't even Free Software, as it cannot > > be modified.[2]) > > I'm not aware of any "v3 or later" items. tex/txi-en.tex et al. > As for claop.py, I'm quite willing to ditch it. Yes, it's a cool > example, but it doesn't need to live in the actual lilypond sources. > A link to some webpage would be sufficient. There's also ./input/cary.ly: copyright = "Copyright 2006 Trevor Bača - all rights reserved." [I should note that I pulled all of these up using grep -Ri copyright; they're certainly not exhaustive.] Don Armstrong -- "Ban cryptography! Yes. Let's also ban pencils, pens and paper, since criminals can use them to draw plans of the joint they are casing or even, god forbid, create one time pads to pass uncrackable codes to each other. Ban open spaces since criminals could use them to converse with each other out of earshot of the police. Let's ban flags since they could be used to pass secret messages in semaphore. In fact let's just ban all forms of verbal and non-verbal communication -- let's see those criminals make plans now!" http://www.donarmstrong.com http://rzlab.ucr.edu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Graham Percival wrote: > Docs have always been FDLv1.1 or later. I was thinking about > unilaterially changing them to FDLv1.3 or later, as soon as I've > got GUB working. Great, that should simplify matters A LOT. Where in the source tree is the explicit statement of the 'or later' ... ? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: > Mao, I missed the flamewar. I'm very disappointed that this > happened without me. :( :-) > The manuals include the FDL, so I'd argue that it's clear that the > sources are under the same license. I'd argue the same about the > source files, actually. This is basically about good (unambiguous) practice as far as I'm concerned (see e.g. GNU project guidelines). > Yes. Including people for whom we lost contact 10 years ago, and > including the heir(s) of Rune Zedeler, who passed away last year. > > Are you offering to track down those people? And write to his > family to find out who owns his software (I'm sure they won't > know), and ask for their permission? How good's your German, by > the way? I have no clue if his family speaks English well enough > to understand the nuances of GPLv2 vs. GPLv3. Or at least the > notation of changing a software license, where both licenses > essentially say the same thing[1]. > > [1] yes, you and I know the differences, but normal people have a > hard enough concept with "I'll share this software with you if you > share it with others". Yes, I'm prepared at some point to attempt this task. That's not a cop-out; it's just that I want to see how much we can do _without_ that tracking-down before I go down that particular difficult route. More on that to follow. > Really? Line 22 says "Version 2, June 1991" to me. How exactly > do you propose to change the COPYING file? I propose to add text closer to the statement recommended by the FSF/GNU foundation and by the GPL itself: GNU Lilypond is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. ... plus some further explanatory text that will probably be close to what the existing file says. Perhaps also a line emphasising the licensing situation (i.e. v2 only) as the Linux kernel COPYING file does, and a note explaining how we are attempting to change the licensing situation. >> (v) the link on the main page which (still) points to the >> text of GPLv3 on gnu.org (and has ever since v3 was >> released -- the first message pointing out this >> discrepancy was sent to the -devel mailing list over >> 2 years ago!). > > This is fixed on the new website. But not on the current one, which is still live ... :-) >> In addressing this there are several policies that can be put in place NOW: >> >>(1) All new files added to the code or docs must contain an >>unambiguous copyright AND licensing notice: I suggest in this >>case GPLv2 or later for code, and the GFDL 1.1 or later for docs. > > I really don't see why we MUST do this. Is there any legal > requirement that every single file contain the license? I'm not > aware of any. Material is copyright by default. Sure; this is just a useful policy to have (and maintain) because it clarifies the licensing situation on a file-by-file basis. >>(2) Contributors of new material to existing files should add >>copyright/licensing notices *for their contributions*, again with >>appropriate 'or later' bits. > > That's going to get ridiculous. We should add a name for each > one-line bugfix? No. My statement was not clear enough. There are guidelines on this in the 'Information for Maintainers of GNU Software': http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when. >>(1) How well have the copyright notices for individual files been >>maintained? > > Not. > >> Do they refer only to original authors of files >>or all authors over that file's history? (More precisely: is >>there not just a list of who contributed to LP but also who >>wrote exactly what?) > > Original authors of files. Look at the git log for more details. Yup, as I discovered after a few sessions with git annotate. :-) >>(2) Is there a preference for transferring copyright to some third >>party (either the FSF or some LP-dedicated organisation)? If >>not, it seems a good idea for future contributions to LP to be >>'or later', as it avoids a repeat of this issue in the future. > > This has been discussed privately, and might occur if the > copyright-fixing issue is undertaken seriously. Personally I'm not in favour of copyright-transfer agreements, I
Re: Overview of copyright issues
On 9/10/09 4:47 PM, "Graham Percival" wrote: > On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote: >> >> On 9/10/09 4:02 PM, "Graham Percival" wrote: >> >>> On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: >>> >>> 3) If we can't find some people, or if they don't agree to >>> whatever relicense/assignment, then we eliminate their patches and >>> rewrite that material. >> >> The main reason for having the GPL, IMO, is to prevent somebody from taking >> the LilyPond codebase and selling a proprietary package. And v2 seems to do >> that sufficiently well. > > Yes, but then the FSF went and royally screwed us by making GPLv3 > incompatible with v2. For an organization that's supposed to > encourage openness and collaboration, this was MONUMENTALLY > stupid. At some point, we'll have to spend hours and hours either > working around the license, or abandoning working code+docs just > because it was written 10 years ago under the then-best license > (i.e. v2). Amen to that. If only they had made some kind of an accomodation clause that would have allowed projects with mixed v2 and v3 licenses to go forward, as long as the v3 license terms were followed on the combined package (e.g. no tivoization, and following the patent stuff). But they don't. > > Ok, the ghostscript GPLv3 isn't an issue. But what if guile > switches to v3? And what if guile 1.10 or 2.0 or 3.0 (or > whatever) had some nice bugfixes, runs five times as fast, and > washes your car as well? It would suck if we had to ignore all > those bugfixes (and clean cars) because it was v3 and we couldn't > link to it. It would suck slightly less if we had to write some > wrapper code under v2/v3 to expose the pubic interface or whatever > it is that people who do this kind of stuff do. I don't have that > kind of a hobby. :) I guess this means that we should thank Joe for being willing to give this a shot, and offer whatever help we can to make it come to pass. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote: > > On 9/10/09 4:02 PM, "Graham Percival" wrote: > > > On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: > > > > 3) If we can't find some people, or if they don't agree to > > whatever relicense/assignment, then we eliminate their patches and > > rewrite that material. > > The main reason for having the GPL, IMO, is to prevent somebody from taking > the LilyPond codebase and selling a proprietary package. And v2 seems to do > that sufficiently well. Yes, but then the FSF went and royally screwed us by making GPLv3 incompatible with v2. For an organization that's supposed to encourage openness and collaboration, this was MONUMENTALLY stupid. At some point, we'll have to spend hours and hours either working around the license, or abandoning working code+docs just because it was written 10 years ago under the then-best license (i.e. v2). Ok, the ghostscript GPLv3 isn't an issue. But what if guile switches to v3? And what if guile 1.10 or 2.0 or 3.0 (or whatever) had some nice bugfixes, runs five times as fast, and washes your car as well? It would suck if we had to ignore all those bugfixes (and clean cars) because it was v3 and we couldn't link to it. It would suck slightly less if we had to write some wrapper code under v2/v3 to expose the pubic interface or whatever it is that people who do this kind of stuff do. I don't have that kind of a hobby. :) If it was an incompatibility of BSD-software wanting to use a GPL-library, there's no contest. Obviously the BSD-software either relicenses to GPL, or finds/writes their own library. But an incompatibility between GPLv3 and v2 like this is just stupid. :/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
On Thu, Sep 10, 2009 at 11:07:06PM +0100, Anthony W. Youngman wrote: > In message <200909101742.10364.reinh...@kainhofer.com>, Reinhold > Kainhofer writes >> ... So we'll have the same problem again in some years... By then it will be >> even harder tracking down all contributors, who submitted a patch years >> ago... >> > Hopefully we won't. Hopefully contributors will use the "or later" > version. Oops, in my excitement over my *awesome* comic idea, I forgot the serious answer. One option would be to ask contributors to assign their copyright to a LilyPond Foundation, under the assumption that this foundation would choose the best license for LilyPond. Potentially even a non-GPL license, if a nicer license with similar terms comes along. This would avoid the relicensing issue. Of course, this plan is also weak against the "assassinate all members of the (lilypond) foundation" plot. Cheers, - Graham "maybe I should stop watching spy thrillers" Percival ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 9/10/09 4:02 PM, "Graham Percival" wrote: > Mao, I missed the flamewar. I'm very disappointed that this > happened without me. :( > > > On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: > > 3) If we can't find some people, or if they don't agree to > whatever relicense/assignment, then we eliminate their patches and > rewrite that material. > > This could involve a non-trivial amount of extra work, but at > least it's legally sound. This also gives you an order to ask > people -- identify the most active / biggest contributors, and get > them on board first. If 95% of the code+docs is covered, then > it's more feasible to undertake the project. I mean, if worst > comes to worst, we can just rewriting the stuff from the missing > people. > It seems to me that there's a very easy, low-risk way to get started on a potential move to 2+ (or 3+): First ask the current active developers if they are willing to license their contributions under 2+. If any are not, then it's basically a dead end path, and there's no sense going down it (although it may be beneficial to clean up copyright and license statements). Realistically, I see that there is no chance that somebody will sue over LilyPond -- there's nobody with any assets and there is a long record (archived in mail lists) of the public development of LilyPond. The main reason for having the GPL, IMO, is to prevent somebody from taking the LilyPond codebase and selling a proprietary package. And v2 seems to do that sufficiently well. But if this is something that Joe is willing to take a stab at, I say good for you, Joe. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
On Thu, Sep 10, 2009 at 11:07:06PM +0100, Anthony W. Youngman wrote: > In message <200909101742.10364.reinh...@kainhofer.com>, Reinhold > Kainhofer writes >> ... So we'll have the same problem again in some years... By then it will be >> even harder tracking down all contributors, who submitted a patch years >> ago... >> > Hopefully we won't. Hopefully contributors will use the "or later" > version. > > But the problem with *demanding* "or later" is that you are *forcing* > potential contributors to give the FSF carte blanche to relicence their > work. Why should I, having given long and careful thought to the licence > I want for my code, allow other people to change those terms without as > much as a "by your leave"? I'm not saying I agree with Linus, but he has > his reasons for licencing Linux as "v2 only", and I'm sure there'll be > people who think he has a valid point! Sweet Mao, I actually agree with Anthony about something! :) Yeah, I've always been troubled by this. I think[1] that technically, if somebody assasinated enough FSF members, and/or bought a million FSF memberships or whatever... whatever would be required to replace the current board with their minions... they could release a GPLv4 that states "all your base are belong to us, and that source code can be used by SCO in any way they see fit". [1] I haven't looked into the actual mechanisms behind the "or later" clause, or the exact process by which the FSF chooses new board members. It would make an *awesome* webcomic, though... maybe I should so some research into this, find somebody to draw the thing, and create an *awesome* comic about valient open-source developers fighting against such a take-over of the FSF. I could write an *awesome* story for that comic. Hey, Valentin? You're not really busy these days, are you? And your little lilypond note icon is cute. Want to make a webcomic together? ;) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Thu, Sep 10, 2009 at 7:02 PM, Graham Percival wrote: > Mao, I missed the flamewar. I'm very disappointed that this > happened without me. :( The reason that I am against changing anything beyond making existing terms clearer is that it generates a huge amount of legal hypothesizing by non-lawyers, distracting people that actually produce contributions. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
On Thu, Sep 10, 2009 at 03:10:53PM +0200, Joseph Wakeling wrote: > > (There are a significant number of files distributed in lilypond which > > are under v2 or later, or v3 or later, as well as things like > > input/mutopia/claop.py, which isn't even Free Software, as it cannot > > be modified.[2]) > > If I'm not mistaken, isn't that file only used for a regression test? > How does that affect the situation? It's still in the source tree, and thus should be removed before Debian redistributes it. > > I'd personally prefer it if documentation was at least licensed under > > the same license as the code to allow for easily inclusion of code > > examples (and to obviate the problems I [and Debian] have with > > specific aspects of the GFDL.) It certainly can be dual licensed under > > GFDL >= v1.1 + GPL >= v2, though. > > AFAIK the docs have always been GFDLv1.1 -- I don't think we can > unilaterally relicense them. Docs have always been FDLv1.1 or later. I was thinking about unilaterially changing them to FDLv1.3 or later, as soon as I've got GUB working. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Switching to Waf instead of SCons?
On 9/10/09 3:10 PM, "John Mandereau" wrote: > Le mardi 08 septembre 2009 à 19:53 +0100, Graham Percival a écrit : >> The most important two factors, in my mind, are "how interested >> are you?" (very interested), and "will you have enough time to >> finish it?". I'm not so concerned about using waf for everything, >> but do you think you can get the docs using waf before you become >> busy again? > > I hope so. I read through the Waf book and put a quick draft of a > migration plan at http://wiki.lilynet.net/index.php/Switching_to_Waf > This plan mainly aims at helping me putting ideas in good order and > informing you of the goals and progress of the migration, but it would > be wonderful if it could also motivate some developers to help with this > migration :-) I'd be willing to give a hand if I can. I read your wiki page, but didn't get anything from it in terms of how I could help. Give me a ping if you get to the point that you can carve out some kind of task for me to try. I actually think that the build system is the current biggest weakness in LilyPond; it's hanging out there just waiting to crash, and not very many people understand it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Wed, Sep 09, 2009 at 03:36:39PM -0700, Don Armstrong wrote: > (There are a significant number of files distributed in lilypond which > are under v2 or later, or v3 or later, as well as things like > input/mutopia/claop.py, which isn't even Free Software, as it cannot > be modified.[2]) I'm not aware of any "v3 or later" items. As for claop.py, I'm quite willing to ditch it. Yes, it's a cool example, but it doesn't need to live in the actual lilypond sources. A link to some webpage would be sufficient. I've already nixed several nice examples for the new website by demanding that they be either FDL or Creative Commons. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Thu, Sep 10, 2009 at 12:36:08AM +0200, Joseph Wakeling wrote: > Han-Wen Nienhuys wrote: > > I think having to sign paperwork (esp. having your employer sign > > something) is something that puts a big barrier up for potential > > contributors. I am not sure it is worth the effort. > > I would not want to see users in general having to sign a contributor > agreement or any such. What does seem like a good idea is moving > existing code from 'v2 only' to 'v2 or later' (or v3 if desired), Not users, but contributors. The problem is "if somebody emails a patch to a file, can we assume that they're willing to license their patch under that license?" Morally, yes we can. By current practice in most open-source projects, yes we can. By current practice in *some* open-source projects (IIRC bison and gcc), no we cannot. By actual strict legality... who knows? It's possible that a one-line bugfix that adds a missing ; (if somebody changed a C file without even trying to compile it) still counts as copyright material, and would strictly speaking require a signed paper letter licensing that intellectual property under the GPL. Honestly, I'm sure that not even lawyers know the answer to the above question. And I'm *also* sure that the answer depends on which country you're in. Or rather, which countries the contributor lives in, reviewer lives in, or maybe which countries they are current residing or visiting, where the source is hosted, files are downloaded... honestly, international copyright law is a total mess, and is woefully unprepared for the kinds of collaboration that the internet allows / promotes. In some ways, I hope this *doesn't* get resolved in the near future. The longer we wait, the more (current) youth will be around, and thus the more liberal the copyright will be. It's no coincidence that the Pirate Party does so well with younger voters! People who have grown up with the internet generally have a different view of copyright than those over 40. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
In message <200909101742.10364.reinh...@kainhofer.com>, Reinhold Kainhofer writes Am Donnerstag, 10. September 2009 17:12:42 schrieb Anthony W. Youngman: In message <4aa8fadd.5050...@webdrake.net>, Joseph Wakeling writes >Now, future policies -- I would suggest new contributions be requested >to follow these rules: > >-- for code, GPLv2 or later or a more liberal compatible license; NO NO NO. Some people are likely to be unhappy with "or later". The requirement should be "compatible with GPLv2 *AND* GPLv3". ... So we'll have the same problem again in some years... By then it will be even harder tracking down all contributors, who submitted a patch years ago... Hopefully we won't. Hopefully contributors will use the "or later" version. But the problem with *demanding* "or later" is that you are *forcing* potential contributors to give the FSF carte blanche to relicence their work. Why should I, having given long and careful thought to the licence I want for my code, allow other people to change those terms without as much as a "by your leave"? I'm not saying I agree with Linus, but he has his reasons for licencing Linux as "v2 only", and I'm sure there'll be people who think he has a valid point! >-- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or > more liberal compatible license); GFDL must be "with no invariant sections". While the FSF may want invariant sections, it's meant for political diatribes. Do we *really* want chunks of documentation that we can't update as lilypond changes? There is NO REASON WHATSOEVER for having invariant sections in what is real documentation, and every reason for NOT having them. Huh? nobody ever spoke of adding invariant sections. I though it was clear that our docs would not have invariant sections.. Not to me it wasn't! The original proposal was "GFDL for documentation" with no reference whatsoever to invariant sections, for or against. >-- when altering a file that already exists, use the same license > as for the rest of that file (so if someone contributes a code > file under a BSD/MIT-esque license, anyone who adds to that file > uses the same); Yup. Use the word "should" rather than "must", however - see below. See the introduction before the list: ... "be requested to follow these rules"... >-- patches that make a significant alteration to a file should add > the author's name to the copyright notice Along with the author's licence - if the "significant alteration" is tantamount to a major rewrite, they might want to change the licence. And if the resulting file is mostly their work, then why shouldn't they? Because they are not allowed by copyright law. They cannot change the license if the file is only "mostly" their work. They can only change the license if the file is SOLELY their work. Sorry - you're wrong there. If the original licence is MIT, and the rewrite is GPL, then copyright law DOES allow them to change the licence DESPITE the file not being all (or even mostly!) their own work. I don't think we should allow a minor GPL change to change the licence for a MIT/BSD file, but it's okay if it's actually a major rewrite. Going back to an earlier point of yours - "See the introduction before the list: ... "be requested to follow these rules"..." - that wasn't clear. I think we should drop that "be requested" (I never saw it ...) and write the rules in rfc-style-speak. Eg "Licencing: the licence on any contribution MUST be compatible with GPLv2 and GPLv3. The PREFERRED licence is "GPLv2 or later" or something more liberal such as MIT/BSD" Otherwise it will be perfectly okay - because it says "be requested" - for people to STILL TODAY contribute GPLv2-only code! And where will the move to v3 go then? Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Mao, I missed the flamewar. I'm very disappointed that this happened without me. :( On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: >(3) Individual code files contain copyright notices but not licensing >notices. It's not clear if these notices have been maintained >beyond updating the date -- have author names been persistently >added where appropriate? No. >(4) Individual documentation source files (.itely files) in general >contain neither copyright notices nor licensing notices. The manuals include the FDL, so I'd argue that it's clear that the sources are under the same license. I'd argue the same about the source files, actually. >(5) We have a full list of contributors to Lilypond but need to have >PAPER documentation giving their permission to change the license >of the code/documentation they wrote. Yes. Including people for whom we lost contact 10 years ago, and including the heir(s) of Rune Zedeler, who passed away last year. Are you offering to track down those people? And write to his family to find out who owns his software (I'm sure they won't know), and ask for their permission? How good's your German, by the way? I have no clue if his family speaks English well enough to understand the nuances of GPLv2 vs. GPLv3. Or at least the notation of changing a software license, where both licenses essentially say the same thing[1]. [1] yes, you and I know the differences, but normal people have a hard enough concept with "I'll share this software with you if you share it with others". > (i) a Debian copyright file for the package, apparently last > updated in 2004, stating that Lilypond is 'v2 or later' Mispresenting a license is a serious issue, but evidently the Debian maintainer is aware and is fixing it. > (ii) the fact that the Lilypond COPYING file, while describing > the licensing situation accurately, does so in non- > standard language (people expect to see the statement > recommended in the GPL appendix, which allows for > unambiguous distinction between 'vN or later' or 'vN') Really? Line 22 says "Version 2, June 1991" to me. How exactly do you propose to change the COPYING file? > (v) the link on the main page which (still) points to the > text of GPLv3 on gnu.org (and has ever since v3 was > released -- the first message pointing out this > discrepancy was sent to the -devel mailing list over > 2 years ago!). This is fixed on the new website. > In addressing this there are several policies that can be put in place NOW: > >(1) All new files added to the code or docs must contain an >unambiguous copyright AND licensing notice: I suggest in this >case GPLv2 or later for code, and the GFDL 1.1 or later for docs. I really don't see why we MUST do this. Is there any legal requirement that every single file contain the license? I'm not aware of any. Material is copyright by default. >(2) Contributors of new material to existing files should add >copyright/licensing notices *for their contributions*, again with >appropriate 'or later' bits. That's going to get ridiculous. We should add a name for each one-line bugfix? > Questions: > >(1) How well have the copyright notices for individual files been >maintained? Not. > Do they refer only to original authors of files >or all authors over that file's history? (More precisely: is >there not just a list of who contributed to LP but also who >wrote exactly what?) Original authors of files. Look at the git log for more details. >(2) Is there a preference for transferring copyright to some third >party (either the FSF or some LP-dedicated organisation)? If >not, it seems a good idea for future contributions to LP to be >'or later', as it avoids a repeat of this issue in the future. This has been discussed privately, and might occur if the copyright-fixing issue is undertaken seriously. > OK, I think that's the lot. Thoughts/disagreements/comments anyone? Yes, I disagree. You've done a lot of demanding. Tracking down everybody, especially getting informed consent from the families of deceased contributor(s), will be a huge amount of work. I repeat what I said to somebody (maybe you) on -user a day or two ago: are you prepared to do something like 50 hours of work on this? Or are you just blowing smoke? If you're willing to spend the time to organize everything, then I'll do my part. This will be a long, hard, painful process. First you need to figure out how contributed stuff. After doing the obvious stuff from git and old CVS changelogs, you'll probably start asking various people for email addresses. I'm willing to look for those, but I'm not going to treat it
Re: .ily extension
Hi Graham, Thanks for the info! Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: .ily extension
On Wed, Sep 09, 2009 at 11:02:41AM -0400, Kieren MacMillan wrote: > 1. Has the 'Pond made a final decision on the "standard" file extension > for non-compilable (i.e., "include" only) Lilypond files? Since we haven't started the "standarding" project, no. That said, I can't imagine why we wouldn't go with .ily. > 2. If so, when will the [Mac OS X] version actually open said files? > (e.g., right now it won't recognize or open .ily files) There are currently absolutely no plans on changing any of the lilypad editors. Once we have regular releases again, and once we've consolidated the lilypad sources, you could try asking Christian Hitz (the guy who fixed lilypad on 10.5) to add this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Switching to Waf instead of SCons?
Le mardi 08 septembre 2009 à 19:53 +0100, Graham Percival a écrit : > The most important two factors, in my mind, are "how interested > are you?" (very interested), and "will you have enough time to > finish it?". I'm not so concerned about using waf for everything, > but do you think you can get the docs using waf before you become > busy again? I hope so. I read through the Waf book and put a quick draft of a migration plan at http://wiki.lilynet.net/index.php/Switching_to_Waf This plan mainly aims at helping me putting ideas in good order and informing you of the goals and progress of the migration, but it would be wonderful if it could also motivate some developers to help with this migration :-) You'll see my first experiments on dev/waf branch when I push it (I haven't really started any development yet). > If somebody is interested in it and is willing > to spend time working with the waf developers, great! I think the > texi2html work last year was very useful, both for us and > texi2html. I'm not sure. If Waf proves to be well-designed enough so that all we'll have to do is writing Waf tools to support builds that use Texinfo, LilyPond executables, Metafont and a few other custom building tools we have, then using these tools and Waf tools provided for C++ and Python scripts in wscripts. > I absolutely do not want to have a half-completed switch to waf > for documentation. [snip] > But I don't want to end up fumbling around in waf > because no active developers are familiar with it. Is this complaint an attempt at discouraging us from switching to another build system? Our current build system for the documentation sucks so much that even a half-finished set of Waf tools and wscripts will provide better building conditions. If the new build system with Waf proves to be maintainable, you'll have little difficulty to "fumbling around" in it even if it's still a draft :-) Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
On Thu, 10 Sep 2009, Joseph Wakeling wrote: > Don Armstrong wrote: > > (There are a significant number of files distributed in lilypond > > which are under v2 or later, or v3 or later, as well as things > > like input/mutopia/claop.py, which isn't even Free Software, as it > > cannot be modified.[2]) > > If I'm not mistaken, isn't that file only used for a regression > test? How does that affect the situation? It doesn't really change the situation for me, as I have to strip it out of the tarball, but it presumably doesn't affect the binary packages that I distribute. That's because everything Debian distributes has to satisfy the DFSG; whether that's an issue for you all is for you all to decide. [What would be really super for me is if during this process, those files which had non-free licenses were identified (and a conscious effort was made to identify any new ones) so that I could easily remove them.] > > I'd personally prefer it if documentation was at least licensed > > under the same license as the code to allow for easily inclusion > > of code examples (and to obviate the problems I [and Debian] have > > with specific aspects of the GFDL.) It certainly can be dual > > licensed under GFDL >= v1.1 + GPL >= v2, though. > > AFAIK the docs have always been GFDLv1.1 -- I don't think we can > unilaterally relicense them. Can you clarify the particular issue > with GFDL? I thought the Debian consensus was that GFDL is OK as > long as there are no invariant sections. Right. There are some other bits of the GFDL that I personally don't like too, but so long as there aren't invariant sections it's ok. > What does GPL imply for docs? Would it mean e.g. that someone who > distributes a PDF of the Learning Manual would have to also be > prepared to provide Texinfo sources? What I'm suggesting is that they be dual-licensed, so that someone who wanted to comply with the GFDL could do so, and alternatively, they could comply with the GPL instead. If they were *only* under the GPL, you're correct that someone distributing a PDF would also have to be prepared to provide the source code. [Though, under the GFDL, you may need to if you are copying in quantity, since the PDF is probably "Opaque".] Don Armstrong -- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill http://www.donarmstrong.com http://rzlab.ucr.edu ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Travis Briggs wrote: > The source material could be public domain, but the snippet itself is > a 'derivative work' and is thus under the copyright of whoever made > it. What I recall from submitting to LSR was that I was asked to agree that by submitting this snippet, I was (a) consigning it to the public domain and (b) had the right to do so. As Valentin says, public domain is not a license, but public domain is arguably the optimal copyright status for most musical examples given in the documentation. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Reinhold Kainhofer wrote: > Because they are not allowed by copyright law. They cannot change the license > if the file is only "mostly" their work. They can only change the license if > the file is SOLELY their work. Well, technically they can release their bit of the file under their own license, as long as it is compatible with the original. What they can't do is unilaterally rewrite the license for the whole file (see the whole mess last year when some guy working on the Linux kernel rewrote the licensing notice for a file copied from the BSD kernel). Having a 'one license per file' rule just makes things simpler, is all. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 10. September 2009 17:12:42 schrieb Anthony W. Youngman: > In message <4aa8fadd.5050...@webdrake.net>, Joseph Wakeling > writes > > >Now, future policies -- I would suggest new contributions be requested > >to follow these rules: > > > >-- for code, GPLv2 or later or a more liberal compatible license; > > NO NO NO. > > Some people are likely to be unhappy with "or later". > > The requirement should be "compatible with GPLv2 *AND* GPLv3". ... So we'll have the same problem again in some years... By then it will be even harder tracking down all contributors, who submitted a patch years ago... > >-- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or > > more liberal compatible license); > > GFDL must be "with no invariant sections". While the FSF may want > invariant sections, it's meant for political diatribes. Do we *really* > want chunks of documentation that we can't update as lilypond changes? > There is NO REASON WHATSOEVER for having invariant sections in what is > real documentation, and every reason for NOT having them. Huh? nobody ever spoke of adding invariant sections. I though it was clear that our docs would not have invariant sections.. > >-- when altering a file that already exists, use the same license > > as for the rest of that file (so if someone contributes a code > > file under a BSD/MIT-esque license, anyone who adds to that file > > uses the same); > > Yup. Use the word "should" rather than "must", however - see below. See the introduction before the list: ... "be requested to follow these rules"... > >-- patches that make a significant alteration to a file should add > > the author's name to the copyright notice > > Along with the author's licence - if the "significant alteration" is > tantamount to a major rewrite, they might want to change the licence. > And if the resulting file is mostly their work, then why shouldn't they? Because they are not allowed by copyright law. They cannot change the license if the file is only "mostly" their work. They can only change the license if the file is SOLELY their work. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKqR5QTqjEwhXvPN0RAmB8AJ9xnIdSnF9RXOq9uLUB1lgINNBTAgCgqtjJ Y4En0Ombch2wVII20T/NCDQ= =MykT -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
In message <4aa8fadd.5050...@webdrake.net>, Joseph Wakeling writes Now, future policies -- I would suggest new contributions be requested to follow these rules: -- for code, GPLv2 or later or a more liberal compatible license; NO NO NO. Some people are likely to be unhappy with "or later". The requirement should be "compatible with GPLv2 *AND* GPLv3". But *don't* demand "compatibility with licences yet to be written" ie GPLv3.1, GPLv4 etc. By all means ask for it, but don't demand it. -- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or more liberal compatible license); GFDL must be "with no invariant sections". While the FSF may want invariant sections, it's meant for political diatribes. Do we *really* want chunks of documentation that we can't update as lilypond changes? There is NO REASON WHATSOEVER for having invariant sections in what is real documentation, and every reason for NOT having them. -- when altering a file that already exists, use the same license as for the rest of that file (so if someone contributes a code file under a BSD/MIT-esque license, anyone who adds to that file uses the same); Yup. Use the word "should" rather than "must", however - see below. -- patches that make a significant alteration to a file should add the author's name to the copyright notice Along with the author's licence - if the "significant alteration" is tantamount to a major rewrite, they might want to change the licence. And if the resulting file is mostly their work, then why shouldn't they? Or they might add a completely new function that belongs in that file, but is self-contained and worthy of its own licence. Or if the file is "v2 or v3", the author might want to use the more lax "v2 or later". Obviously, the licence applied to the patch MUST be fully compatible with the main licence applied to the file. If the "patch author" wants to apply a GPL patch to a BSD-MIT file, that would only be acceptable under the "major rewrite" reasoning because it's actually changing the main licence on the file. -- new files should be required to carry a copyright and licensing notice when added to the source code. Yup. Basically, any code more significant than bug-fixes, for which the author can reasonably claim copyright, then copyright should be claimed (or explicitly disclaimed). Note that if all this goes OK, we should then be OK to unilaterally upgrade to GPLv3 (if that's desired). Makes sense. Does this sound good to everyone? Pretty much. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 10. September 2009 16:21:34 schrieb Jan Nieuwenhuizen: > Op donderdag 10-09-2009 om 15:28 uur [tijdzone +0200], schreef Valentin > > Villenave: > > On Thu, Sep 10, 2009 at 3:10 PM, Joseph Wakeling > > > > wrote: > > > What would be good is if as many contributors as possible can reply to > > > this email just to OK (i) my putting copyright/licensing notices in the > > > files they have contributed to and (ii) their licensing preferences for > > > their contributions: > > > > OK for my contributions. "or later" clause OK as well. > > OK for my contributions. "or later" clause OK as well. OK my contributions, "or later" clause OK as well. (For Documentation/lilypond-texi2html.init I'm already using GPL v2+, btw). Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKqRBqTqjEwhXvPN0RAgg7AKCHOUxz6Un2dvb39mPI95CurdE15ACgsDFV mB80cP2YjHwddLRORM1G+mA= =gIMT -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Op donderdag 10-09-2009 om 15:28 uur [tijdzone +0200], schreef Valentin Villenave: > On Thu, Sep 10, 2009 at 3:10 PM, Joseph Wakeling > wrote: > > What would be good is if as many contributors as possible can reply to > > this email just to OK (i) my putting copyright/licensing notices in the > > files they have contributed to and (ii) their licensing preferences for > > their contributions: > > OK for my contributions. "or later" clause OK as well. OK for my contributions. "or later" clause OK as well. > Joseph> More particularly, does anyone object to me adding a GFDL 1.1 > Joseph> or later notice to the doc files I have written? > Yes. ? The docs already use GFDL 1.1, so that's no problem. > It may then be undistributable by Debian --- see > http://www.debian.org/vote/2006/vote_001 We do not use cover texts, so that should be ok. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
The source material could be public domain, but the snippet itself is a 'derivative work' and is thus under the copyright of whoever made it. -Travis On Thu, Sep 10, 2009 at 9:28 AM, Valentin Villenave wrote: > On Thu, Sep 10, 2009 at 3:10 PM, Joseph Wakeling > wrote: >> What I propose is that I maintain a separate branch of the code (but >> keep pulling/rebasing against the Lilypond master) to insert appropriate >> copyright and licensing notices. git blame should help to give a better >> idea of who has contributed to what, so I can fire of queries to authors >> where necessary. > > Good luck with that :) > >> What would be good is if as many contributors as possible can reply to >> this email just to OK (i) my putting copyright/licensing notices in the >> files they have contributed to and (ii) their licensing preferences for >> their contributions: > > OK for my contributions. "or later" clause OK as well. > >> I think that snippets are already public domain since it's a condition >> of submission to LSR. > > public domain is not a license. That would be > http://en.wikipedia.org/wiki/WTFPL :-) > > Regards, > Valentin > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
On Thu, Sep 10, 2009 at 3:10 PM, Joseph Wakeling wrote: > What I propose is that I maintain a separate branch of the code (but > keep pulling/rebasing against the Lilypond master) to insert appropriate > copyright and licensing notices. git blame should help to give a better > idea of who has contributed to what, so I can fire of queries to authors > where necessary. Good luck with that :) > What would be good is if as many contributors as possible can reply to > this email just to OK (i) my putting copyright/licensing notices in the > files they have contributed to and (ii) their licensing preferences for > their contributions: OK for my contributions. "or later" clause OK as well. > I think that snippets are already public domain since it's a condition > of submission to LSR. public domain is not a license. That would be http://en.wikipedia.org/wiki/WTFPL :-) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Anyways, as a contributor (!), I definitely support "or later" because it allows for things like the Wikipedia re-licensing. It would have been quite a mess if Wikipedia wasn't under an "or later" clause. I'll volunteer to add GPLv2 text to the top of all the files. Just let me know when you want it done. I'd also be willing to volunteer for the pester-contributors-to-allow -for-the-'or later'-clause-committee. As far as I understand, copyright law is awful and there are no allowances or time limits for making 'reasonable attempts' at contacting copyright holders. So until permission is secured from every contributor, the move to 'or later' cannot be made. Similarly, if even one contributor withholds permission, then the conversion could not succeed without discarding/re-writing those contributions. As far as the GFDL is concerned, I'm in agreement with Debian. It's a problematic license...it's less ambiguous to just license the docs under the same license as the code (or a less restrictive one...). -Travis On Thu, Sep 10, 2009 at 9:16 AM, Hans Aberg wrote: > On 10 Sep 2009, at 14:46, Joseph Wakeling wrote: > >>> In GNU projects, the normal thing is that contributors sign a paper >>> which is sent in to GNU that they donate the code to GNU. >> >> Nope. >> >> "For a program to be GNU software does not require transferring >> copyright to the FSF; that is a separate question. If you transfer >> the copyright to the FSF, the FSF will enforce the GPL for the >> program if someone violates it; if you keep the copyright, >> enforcement will be up to you." >> >> from: >> http://www.gnu.org/help/evaluation.html#whatmeans > > You do not have to have to sign it over to FSF, obviously, since nobody can > force you to give away what you own. > > But that is how it is done on projects like Bison. Whenever new contributors > show up, they are asked to sign a paper and send it in to FSF. > > Hans > > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 10 Sep 2009, at 14:46, Joseph Wakeling wrote: In GNU projects, the normal thing is that contributors sign a paper which is sent in to GNU that they donate the code to GNU. Nope. "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you." from: http://www.gnu.org/help/evaluation.html#whatmeans You do not have to have to sign it over to FSF, obviously, since nobody can force you to give away what you own. But that is how it is done on projects like Bison. Whenever new contributors show up, they are asked to sign a paper and send it in to FSF. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Don Armstrong wrote: > This is now my problem,[1] so I'll attempt to get it addressed at some > point in the future. [I'd certainly like to see Lilypond at least > clear up some of the issues so that the above can become correct.] Hmm, I noted you were listed as the Debian maintainer on Launchpad's Lilypond page, and brain went off: "The same Don Armstrong as ... ?" Nice to have you involved in this discussion (and congratulations on getting your PhD). Disclaimer: I'm a relatively new contributor to (but long-time user of) Lilypond, so what I say are my own thoughts and I don't speak for the Lilypond developer community. But, since I'm putting myself forward to try and deal with some of this, any advice you can give would be very welcome. From my point of view the DFSG are a very nice benchmark against which to test code and doc licensing and compatibility is an important aim. > (There are a significant number of files distributed in lilypond which > are under v2 or later, or v3 or later, as well as things like > input/mutopia/claop.py, which isn't even Free Software, as it cannot > be modified.[2]) If I'm not mistaken, isn't that file only used for a regression test? How does that affect the situation? > Furthermore, the licensing statement in COPYING is immensely > ambiguous, as it only states "GNU PUBLIC LICENSE" without specifying a > version, or anything. > >> (1) All new files added to the code or docs must contain an >> unambiguous copyright AND licensing notice: I suggest in this >> case GPLv2 or later for code, and the GFDL 1.1 or later for >> docs. > > I'd personally prefer it if documentation was at least licensed under > the same license as the code to allow for easily inclusion of code > examples (and to obviate the problems I [and Debian] have with > specific aspects of the GFDL.) It certainly can be dual licensed under > GFDL >= v1.1 + GPL >= v2, though. AFAIK the docs have always been GFDLv1.1 -- I don't think we can unilaterally relicense them. Can you clarify the particular issue with GFDL? I thought the Debian consensus was that GFDL is OK as long as there are no invariant sections. What does GPL imply for docs? Would it mean e.g. that someone who distributes a PDF of the Learning Manual would have to also be prepared to provide Texinfo sources? >> (1) How well have the copyright notices for individual files been >> maintained? > > As near as I can tell, they haven't been maintained at all. Very few > of them actually have the boilerplate that they should have, which > makes this kind of thing very difficult. > > But by all means, please help work on this. It'll certainly make my > life easier when I have to go through and audit the code for inclusion > in Debian (which I naïvely assumed had already been done before I took > over maintenance.) What I have noted is that copyright dates have been updated but I'm not clear whether author names have. What I propose is that I maintain a separate branch of the code (but keep pulling/rebasing against the Lilypond master) to insert appropriate copyright and licensing notices. git blame should help to give a better idea of who has contributed to what, so I can fire of queries to authors where necessary. What would be good is if as many contributors as possible can reply to this email just to OK (i) my putting copyright/licensing notices in the files they have contributed to and (ii) their licensing preferences for their contributions: -- for code, GPLv2 only or GPLv2 or later; -- for docs, GFDLv1.1 or later and/or GPLv2 or later; -- freer licenses (BSD/MIT-style, or donated to the public domain). I think that snippets are already public domain since it's a condition of submission to LSR. I have Han-Wen's OK already for his contributions, but would like others. :-) Now, future policies -- I would suggest new contributions be requested to follow these rules: -- for code, GPLv2 or later or a more liberal compatible license; -- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or more liberal compatible license); -- when altering a file that already exists, use the same license as for the rest of that file (so if someone contributes a code file under a BSD/MIT-esque license, anyone who adds to that file uses the same); -- patches that make a significant alteration to a file should add the author's name to the copyright notice -- new files should be required to carry a copyright and licensing notice when added to the source code. Note that if all this goes OK, we should then be OK to unilaterally upgrade to GPLv3 (if that's desired). Does this sound good to everyone? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > In GNU projects, the normal thing is that contributors sign a paper > which is sent in to GNU that they donate the code to GNU. Nope. "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you." from: http://www.gnu.org/help/evaluation.html#whatmeans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 10 Sep 2009, at 11:20, Anthony W. Youngman wrote: You can't simply go around and change licenses, unless you are the copyright holder! But you are the copyright owner of the LilyPond code. Copyright belongs to the person who wrote the code (sometimes). Unless explicitly signed over to somebody else. There is no ONE owner of lilypond - it is spread amongst many. Indeed I personally MIGHT own some copyright in lilypond! There's a good argument I do, it's a grey area! In GNU projects, the normal thing is that contributors sign a paper which is sent in to GNU that they donate the code to GNU. That's the paperwork that is needed: Every contributor, who has until now contributes as GPL v2only, needs to agree to change his/her contributions to GPL v2+. Unless you track down every substantial contributor (git helps in that regard), LilyPond can't switch to GPL v2+. Why? Is there a GNU requirement? - My cursory reading of v3 did not find anything like that. Where does this idea come from? It's nothing to do with GNU. It's the law. Sorry. I thought you meant code from other projects. But the situation is still the same: even if you haven't individually donated the code (i.e. signed over the copyright) to the collective GNU project called LilyPond, you can change the conditions of each part as the individual copyright owners give permission. When you distribute it, you need to make sure that the conditions of each part is fulfilled. So say somebody (to make an explicit example) wants to make tivoized distribution of LilyPond. They then need to replace the v3 parts with something else, but can keep the v2 parts. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
In message , Hans Aberg writes You can't simply go around and change licenses, unless you are the copyright holder! But you are the copyright owner of the LilyPond code. Copyright belongs to the person who wrote the code (sometimes). There is no ONE owner of lilypond - it is spread amongst many. Indeed I personally MIGHT own some copyright in lilypond! There's a good argument I do, it's a grey area! That's the paperwork that is needed: Every contributor, who has until now contributes as GPL v2only, needs to agree to change his/her contributions to GPL v2+. Unless you track down every substantial contributor (git helps in that regard), LilyPond can't switch to GPL v2+. Why? Is there a GNU requirement? - My cursory reading of v3 did not find anything like that. Where does this idea come from? It's nothing to do with GNU. It's the law. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 10 Sep 2009, at 09:42, Reinhold Kainhofer wrote: Am Donnerstag, 10. September 2009 09:30:57 schrieb Hans Aberg: I'm not a lawyer, but if I came across "v2 or latest" wording, my advice would be to treat it as "v2 only" because to do anything else IS TOO DANGEROUS. So your wording is self-defeating because no sane distributor would dare take advantage of the "or latest" clause. That seems to be the case: at least for new restrictions, "or later" essentially useless. No, it's rather essential. Imagine someone wants to create a fork of LilyPond, where he directly links to gs instead of calling the binary. He'll be out of luck, because gs is GPL v3(+?), while LilyPond is GPL v2only. The "or later" allows to link GPL v3 libraries... He link as he wish, as long as the distribution does not violate any individual terms. So it is probably simplest to just update the license when you have time. All these GPLs are probably reasonable for LilyPond You can't simply go around and change licenses, unless you are the copyright holder! But you are the copyright owner of the LilyPond code. That's the paperwork that is needed: Every contributor, who has until now contributes as GPL v2only, needs to agree to change his/her contributions to GPL v2+. Unless you track down every substantial contributor (git helps in that regard), LilyPond can't switch to GPL v2+. Why? Is there a GNU requirement? - My cursory reading of v3 did not find anything like that. Where does this idea come from? Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 10. September 2009 09:30:57 schrieb Hans Aberg: > > I'm not a lawyer, but if I came across "v2 or latest" wording, my > > advice would be to treat it as "v2 only" because to do anything else > > IS TOO DANGEROUS. So your wording is self-defeating because no sane > > distributor would dare take advantage of the "or latest" clause. > > That seems to be the case: at least for new restrictions, "or later" > essentially useless. No, it's rather essential. Imagine someone wants to create a fork of LilyPond, where he directly links to gs instead of calling the binary. He'll be out of luck, because gs is GPL v3(+?), while LilyPond is GPL v2only. The "or later" allows to link GPL v3 libraries... > So it is probably simplest to just update the license when you have > time. All these GPLs are probably reasonable for LilyPond You can't simply go around and change licenses, unless you are the copyright holder! That's the paperwork that is needed: Every contributor, who has until now contributes as GPL v2only, needs to agree to change his/her contributions to GPL v2+. Unless you track down every substantial contributor (git helps in that regard), LilyPond can't switch to GPL v2+. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKqK3LTqjEwhXvPN0RAjczAKCUASOZgW6wFuxTVp3kyoA7qxtfRgCeMzjA uLc390K5rJ1bP8JKOVPjKlE= =zUrD -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 10 Sep 2009, at 08:35, Anthony W. Youngman wrote: "Or later" will admit later restrictions, "or latest" will impose them quietly on old sources. BINGO! And this is EXACTLY the problem with your suggestion. You are RETROACTIVELY CHANGING THE LICENCE! As has been pointed out elsewhere, this will have the effect of making what was legal, illegal. What happens if v4 comes out and Joe Bloggs never hears about it? He was happily distributing under v3 perfectly legally, now he's happily distributing under v3 ILLEGALLY. As with all copyrights, one will have to check with the owner of the copyright the conditions valid at the distribution conditions are at the time of distribution. Recall that nowadays copyrightable material becomes copyrighted without any copyright notice or registration. The idea with a copyright license is to simplify the procedure. I'm not a lawyer, but if I came across "v2 or latest" wording, my advice would be to treat it as "v2 only" because to do anything else IS TOO DANGEROUS. So your wording is self-defeating because no sane distributor would dare take advantage of the "or latest" clause. That seems to be the case: at least for new restrictions, "or later" essentially useless. So it is probably simplest to just update the license when you have time. All these GPLs are probably reasonable for LilyPond Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
