Re: Overview of copyright issues
Graham Percival wrote Sunday, September 20, 2009 8:26 PM I was confused because Joseph keeps on talking about wanting to copy code from the documentation, and Trevor Daniels recently said you know what? you guys are nutters. Do whatever you want with my stuff, now shut up and do work. ... ok, he didn't say that. But it would have been awesome if he *had* said that. Not quite my style, but it does clarify my meaning ;) For example, we seem to have lost Joseph's really promising work to document contemporary music. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Trevor Daniels wrote: For example, we seem to have lost Joseph's really promising work to document contemporary music. Not lost. :-) Actually, the delay came at least in part because I was looking through problems of functionality related to my docs. I'll post about this on -user. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 07:45:46PM +0100, Anthony W. Youngman wrote: In message 1253377160.11679.1824.ca...@localhost, John Mandereau john.mander...@gmail.com writes On the opposite, note that snippets from LSR are public domain, not FDL. Aarrgghh. The snippets are [insert incorrect information here] Ahh, sweet irony. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 11:28:11PM +0100, Anthony W. Youngman wrote: The snippets are taken from the LSR and a condition of submission to the LSR is that you consign your work to the public domain (and that you have the right to do so). I know, because I submitted a couple of snippets to the LSR and they later made it into the Lilypond docs' selection of snippets. What happens if you're German :-) (I don't know, but there's been a fair bit of discussion, on and off, on debian legal as to whether it is even *possible* for some people to consign their work to the public domain - the *law* apparently says they *can't*) public domain in germany (and maybe other european countries) doesn't exist in the sense that an author can't drop authorship and decline all responsibility for his work. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Similarly, the validity of This work is released by me, the author, into the public domain in the US is under debate, because US law allows authors to retain the right to redact licenses to their copyright works. There is an argument that the moment you put something in the PD, you lose the redaction right. There is also an argument that the redaction right cannot be waived. So really, it is impossible as Valentin points out. But in practice, there is clear intent when you say public domain and I doubt any judge would rule against someone who used such a work. -Travis On Sun, Sep 20, 2009 at 4:36 AM, Matthias Kilian k...@outback.escape.de wrote: On Sat, Sep 19, 2009 at 11:28:11PM +0100, Anthony W. Youngman wrote: The snippets are taken from the LSR and a condition of submission to the LSR is that you consign your work to the public domain (and that you have the right to do so). I know, because I submitted a couple of snippets to the LSR and they later made it into the Lilypond docs' selection of snippets. What happens if you're German :-) (I don't know, but there's been a fair bit of discussion, on and off, on debian legal as to whether it is even *possible* for some people to consign their work to the public domain - the *law* apparently says they *can't*) public domain in germany (and maybe other european countries) doesn't exist in the sense that an author can't drop authorship and decline all responsibility for his work. Ciao, Kili ___ 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 Sat, Sep 19, 2009 at 09:19:35PM +0200, John Mandereau wrote: Le samedi 19 septembre 2009 à 18:34 +0100, Graham Percival a écrit : I'd rather not keep track of individual licenses in the source tree. Since he's stated that his work is in public domain, there'd be no problems with people extracting it for any CC stuff. ... err wait, are we talking about Trevor Daniels, or Trevor Baca? Bloody mao, we're talking about the autor of cary.ly :-) I was confused because Joseph keeps on talking about wanting to copy code from the documentation, and Trevor Daniels recently said you know what? you guys are nutters. Do whatever you want with my stuff, now shut up and do work. ... ok, he didn't say that. But it would have been awesome if he *had* said that. HOWEVER, I'm quite willing to re-open the debate about licenses or relicensing or whatever -- as long as it's done at a convenient time. Right now is not convenient. Sure, so right now isn't convenient either to remove cary.ly and other so-said problematic files. I'm fine for replacing cary.ly as soon as somebody makes a replacement. Should take about 15 minutes, which makes this Yet More Job Wherein We Spent Longer Talking About It Than It Would Take To Actually Do It (tm). ... of course, has anybody actually asked Trevor Baca if he'd be willing to put those two bars under the FDL? If he _was_ willing, it could save much gnashing of teeth. As for input/, that's waiting for the new website and build system to be read. And _that's_ on hold while I deal with GUB during university hours, and deal with this copyright garbage in non-university hours. where the most restrictive search pattern selects the license. We already stamp each snippet in Documentation/snippets public domain, and state it at the beginning of Snippets document, so it shows up in PDF, Info and HTML. We could protect the first page of the document under FDL, but would that make any sense? Good point; I'll dump something to that effect in snippets.tely. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 06:23:06PM +0200, Joseph Wakeling wrote: Graham Percival wrote: This is fixed on the new website. But not on the current one, which is still live ... :-) Patches accepted. I'll see what I can do. (Depending on the timeline for launch of the new site. Not much point patching the current one if you're going to launch the new one in a couple of weeks' time.) I'm glad you see it my way. OK, well. Perhaps I should say 'credit on a per-file basis' rather than licensing[1]. The reason I can see is this: if I decide I want to use a file from Lilypond in my own piece of code, it's helpful to me to know exactly who the authors and copyright holders are for that particular file. With such a notice I immediately know who I have to contact if I need/want further permissions, I know who I have to credit in my AUTHORS file, etc. etc. But since the notices will be out of date, you'll need to look in the git log anyway. So, I see maintaining good file-by-file contribution records as being both helpful to Lilypond (it helps us track who did what) and courteous to people receiving the code (it helps facilitate the process of adapting parts of the code for other projects). Unless we have a dedicated legal secretary spending 5 hours a week maintaining such notices, they will be out of date and therefore useless. [1] Where the licensing issue might be important is this: what if someone forks Lilypond and adds a bunch of their own code with a different but compatible license statement -- like GPLv2+? Huh? If somebody forks lilypond, that's their problem. The other motivation is if there _is_ a desire to alter the license it might be useful to be able to do this incrementally, e.g. move to (say) GPL2+ all those files where the authors give permission as soon as that permission is given. No. Changing the license will be an all-or-nothing affair. No. If there's a detailed file-by-file, Copyright 2003, 2008 by X who wrote 38 lines, copyright 2005 by Y who wrote 123 lines, then that creates pressure to maintain it. That wastes *everybody's* time. I think there are good reasons for wanting to maintain such documentation (see above), and I don't think it's so hard to sustain it -- most files are worked on by relatively few people (so the author list stays constant) and it's not so difficult for contributors to change the year of copyright or just add their name to an author list. It doesn't need to be as detailed as 'wrote X lines' or 'wrote functions A, B, C', just a list of major (i.e. justifiably copyright-owning) contributors and year(s) of their contributions, as in the sample patch I put forward. (I mentioned tweaks as well, but that was just a courtesy to the tweakers rather than something that needs to be tracked.) You severely underestimate the effort involved in the documentation. For example, I recently moved the command-line info from the AU into the new website. At a complete guess, - 5-30 lines came from Han-Wen - 5-30 lines came from Mats - 5-20 lines were corrected by Werner - 5-20 lines had a correction sent to a mailist by random users, and were added by Graham or Mats. - 20-50 lines had English grammatical fixes by Graham, but no actual content changes Now, if 15 lines is the magical cut-off, who gets their name added to Documentation/general/download.itely ? I'd have to hunt through the git log for all these lines -- looking at both grammatical/spelling fixes *and* content fixes -- to decypher whether I used 14 of Han-Wen's original lines or 16. I'm not going to do that. It's a gargantic amount of wasted effort. I mean, everybody in that list is deeply involved in lilypond, we all want the best for lilypond, and we all agree to the same license. Spending an hour looking through git logs every time I want to clarify the documentation helps *nobody*. For this reason, I categorically refuse to have file-specific ownership. Documentation is documentation; any doc committers will be listed in the same place. It's true that code doesn't change as much as the docs, although I could well imagine some kinds of useful reshuffling that would require hours of extra work if we had file-specific ownership. (say, what if we decided to split \mark into \markText and \markRehearsal ? Oops, now we need to track down exactly who wrote which lines in the relevant file(s), to make sure that info gets into the new file(s)). I still think it would be a complete waste of time, but if you really want to track down file ownership of source code, _I_ won't stop you. You'd better check that everybody else is ok with this, though. And by ok, I mean agrees to you doing the initial work, *and* commits to maintain such info in the future. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: For this reason, I categorically refuse to have file-specific ownership. Documentation is documentation; any doc committers will be listed in the same place. About docs, I completely agree. I didn't have to spend long in the git logs to realise that it just wasn't feasible to meaningfully identify contributors -- there's too much moving, renaming, copy-pasting, etc. I still think it would be a complete waste of time, but if you really want to track down file ownership of source code, _I_ won't stop you. You'd better check that everybody else is ok with this, though. And by ok, I mean agrees to you doing the initial work, *and* commits to maintain such info in the future. I think with code it has more value, and ought to be reasonably easy to maintain. There's also the fact that the code, unlike the docs, _does_ contain per-file copyright notices, and that these are wrong. If we're going to have them, they ought to be accurate. Best wishes, -- Joe ___ 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 01:03:05AM +0200, Joseph Wakeling wrote: Graham Percival wrote: 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). Bugger the GNU project guidelines. They're not the be-all and end-all of good project mangement. In many ways, they're pure rubbish. Toodle-pip, cheers, and all that. (I'm trying to be more British... I was really surprised at the use of cheers here. It's a greeting! It's a farewell! It's a thanks! It's an airplaine... no, it's super-word! :) 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. ok. ... 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, ok. and a note explaining how we are attempting to change the licensing situation. Not ok. The above oks are in reference to notices on the entry point (i.e. main.cc, notation.tely for some GFDL text, etc). For all other files, such as random-beam-file.cc or world.itely, I think a simple: @ignore This file is part of the LilyPond Documentation. It is included in specialist.itely, which is included in ../notation.itely. See the latter file for copyright license. @end ignore (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 ... :-) Patches accepted. 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. But we *don't* have a licensing situation on a file-by-file basis. Everything[1] under Documentation/ is FDL; everything else[2] is GPLv2. [1] it would be very useful if somebody could create an example to replace cary.ly, since that's non-free. [2] it would be very useful if somebody could identify anything (other than texinfo.tex and input/* since those are slated for demolition) that isn't GPLv2. [3] haha, an unreferenced footnote! It would be very useful if the note at the top of /COPYING had these exceptions noted. (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 Bugger them -- this time with feeling, not as a cutesy attempt to learn/naturalize British slang. What's the point of per-file stuff? The only thing that I can think of is that if somebody discovers the file via a google search (say, in gitweb), but is too lazy to look at the top of the gitweb repository, they can see the license and comply with it. That's ridiculous. Anybody who is moral will take the extra 30 seconds to find the appropriate COPYING file. Anybody who isn't moral is going to ignore the license anyway and just take whatever they want. I will admit that the docs could use better signage, especially after I moved the license into a @macro (oops). But a simple paragraph for the main manuals in Documentation/, and a sentence or two pointing back to those main manuals for everything in a subdir, would suffice for this. (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
Re: Overview of copyright issues
Le samedi 19 septembre 2009 à 07:30 +0100, Graham Percival a écrit : But we *don't* have a licensing situation on a file-by-file basis. Everything[1] under Documentation/ is FDL; everything else[2] is GPLv2. [1] it would be very useful if somebody could create an example to replace cary.ly, since that's non-free. What about keeping Trevor's work under a CC-BY-ND license, in case he agrees with this? If anybody wants to reuse code for any purpose other than quoting the music itself, it will lead to a different enough work so you can consider it can't be a derived work. About other snippets, are you sure there is no other Mutopia snippet in the public domain or under some license other than FDL (say, CC) in the source tree? On the opposite, note that snippets from LSR are public domain, not FDL. [2] it would be very useful if somebody could identify anything (other than texinfo.tex and input/* since those are slated for demolition) that isn't GPLv2. Junking texinfo.tex from our sources is looking for problems: it's better to keep it in our sources, so we can freely update it to latest CVS or keep a not up-to-date revision if we encounter issues with latest CVS. 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
Graham Percival wrote: Bugger the GNU project guidelines. They're not the be-all and end-all of good project mangement. In many ways, they're pure rubbish. Toodle-pip, cheers, and all that. (I'm trying to be more British... I was really surprised at the use of cheers here. It's a greeting! It's a farewell! It's a thanks! It's an airplaine... no, it's super-word! :) One of the best words in the English language. ;-) GNU guidelines seem to me to be least important reason to do anything, but worth reading and understanding the motivation behind them, particularly where copyright/licensing is concerned -- just because the people behind GNU have put a lot of thought into these things and have a lot of experience. 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. ok. ... 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, ok. I'll put forward a patch for this, then. and a note explaining how we are attempting to change the licensing situation. Not ok. Will not be in the aforementioned patch, then. (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 ... :-) Patches accepted. I'll see what I can do. (Depending on the timeline for launch of the new site. Not much point patching the current one if you're going to launch the new one in a couple of weeks' time.) Sure; this is just a useful policy to have (and maintain) because it clarifies the licensing situation on a file-by-file basis. But we *don't* have a licensing situation on a file-by-file basis. Everything[1] under Documentation/ is FDL; everything else[2] is GPLv2. I'll come to this in a moment after addressing your next points... [1] it would be very useful if somebody could create an example to replace cary.ly, since that's non-free. [2] it would be very useful if somebody could identify anything (other than texinfo.tex and input/* since those are slated for demolition) that isn't GPLv2. [3] haha, an unreferenced footnote! It would be very useful if the note at the top of /COPYING had these exceptions noted. I can work on at least [2] and [3]. I can try to do [1] as well. What's the point of per-file stuff? The only thing that I can think of is that if somebody discovers the file via a google search (say, in gitweb), but is too lazy to look at the top of the gitweb repository, they can see the license and comply with it. That's ridiculous. Anybody who is moral will take the extra 30 seconds to find the appropriate COPYING file. Anybody who isn't moral is going to ignore the license anyway and just take whatever they want. OK, well. Perhaps I should say 'credit on a per-file basis' rather than licensing[1]. The reason I can see is this: if I decide I want to use a file from Lilypond in my own piece of code, it's helpful to me to know exactly who the authors and copyright holders are for that particular file. With such a notice I immediately know who I have to contact if I need/want further permissions, I know who I have to credit in my AUTHORS file, etc. etc. Now, I can of course go searching through the git log to track them down. But then what happens when I discover the apparent contributors don't match with the copyright notice in the file (currently the case)? What happens if I trust the copyright/credit notice, then suddenly later get someone I didn't know about coming along and saying, 'Hey, you're using my code without credit'? (Or, what happens if someone adds third-party material to Lilypond code or docs? OK, we have the git log, but it's handy to be able to see without delving into version history whether a particular file contains material from a given source.) So, I see maintaining good file-by-file contribution records as being both helpful to Lilypond (it helps us track who did what) and courteous to people receiving the code (it helps facilitate the process of adapting parts of the code for other projects). [1] Where the licensing issue might be important is this: what if someone forks Lilypond and adds a bunch of their own code with a different but compatible license statement -- like GPLv2+? It helps clarify the
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 06:19:20PM +0200, John Mandereau wrote: Le samedi 19 septembre 2009 à 07:30 +0100, Graham Percival a écrit : But we *don't* have a licensing situation on a file-by-file basis. Everything[1] under Documentation/ is FDL; everything else[2] is GPLv2. What about keeping Trevor's work under a CC-BY-ND license, in case he agrees with this? I'd rather not keep track of individual licenses in the source tree. Since he's stated that his work is in public domain, there'd be no problems with people extracting it for any CC stuff. ... err wait, are we talking about Trevor Daniels, or Trevor Baca? HOWEVER, I'm quite willing to re-open the debate about licenses or relicensing or whatever -- as long as it's done at a convenient time. Right now is not convenient. About other snippets, are you sure there is no other Mutopia snippet in the public domain or under some license other than FDL (say, CC) in the source tree? On the opposite, note that snippets from LSR are public domain, not FDL. If something's in the public domain, then we can take it an stamp a FDL onto it. Since the initial spark was to clarify the license situation, let's do that. Or, we could add a boilerplate message that anything in input/snippets/ is public domain. Then we'd have /* GPLv2 /Documentation/* FDL /Documentation/snippets/* public domain where the most restrictive search pattern selects the license. As for Mutopia, those are under input/*, and are thus slated for demolition, in no small part due to the licensing issues. [2] it would be very useful if somebody could identify anything (other than texinfo.tex and input/* since those are slated for demolition) that isn't GPLv2. Junking texinfo.tex from our sources is looking for problems: Sorry! Horribly unclear English at play. input/* is slated for removal (other than input/regression/); texinfo.tex will of course be remaining. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
In message 4ab5056a.9010...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net writes [1] Where the licensing issue might be important is this: what if someone forks Lilypond and adds a bunch of their own code with a different but compatible license statement -- like GPLv2+? It helps clarify the situation if each file has a specific license statement rather than just relying on 'files should be assumed to be under license X unless otherwise stated'. I don't know whether it's been done, but what if someone has added code into lilypond itself under a compatible licence such as GPLv2+? (What do you do if, when asking authors what licence they want you to use, they say v2+ or v2/v3, not v2-only?) The other motivation is if there _is_ a desire to alter the license it might be useful to be able to do this incrementally, e.g. move to (say) GPL2+ all those files where the authors give permission as soon as that permission is given. That's moving forward. The thing that concerns me is that, in my (non-lawyer) opinion, if any non-v2-only code HAS made its way into lilypond, it's a GPL violation to stamp a v2-only licence notice on it. If you want a simple explanation of that, if A grants v2+ to his code, then B gives the code to C saying it's v2-only, firstly B has no right to do that (the GPL says that C gets their licence from A, not B), and secondly the GPL says you can't take away rights granted by the copyright owner. Changing from v2+ to v2-only is such a forbidden change (taking away the recipient's right to change licence). 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
In message 1253377160.11679.1824.ca...@localhost, John Mandereau john.mander...@gmail.com writes Le samedi 19 septembre 2009 à 07:30 +0100, Graham Percival a écrit : But we *don't* have a licensing situation on a file-by-file basis. Everything[1] under Documentation/ is FDL; everything else[2] is GPLv2. [1] it would be very useful if somebody could create an example to replace cary.ly, since that's non-free. What about keeping Trevor's work under a CC-BY-ND license, in case he agrees with this? If anybody wants to reuse code for any purpose other than quoting the music itself, it will lead to a different enough work so you can consider it can't be a derived work. About other snippets, are you sure there is no other Mutopia snippet in the public domain or under some license other than FDL (say, CC) in the source tree? On the opposite, note that snippets from LSR are public domain, not FDL. Aarrgghh. The snippets are not public domain, unless the author put them there. The *music* may be public domain, but the *arrangement* is copyright whoever wrote the lilypond code (unless you make the argument that the snippet is too small to qualify for copyright). 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
Le samedi 19 septembre 2009 à 19:45 +0100, Anthony W. Youngman a écrit : The snippets are not public domain, unless the author put them there. The *music* may be public domain, but the *arrangement* is copyright whoever wrote the lilypond code (unless you make the argument that the snippet is too small to qualify for copyright). I understand your point, let me now explain the situation of LSR snippets import into Lily sources. LSR web site requires contributors to put the snippets they add in public domain, partly to make ly code reuse easier; then, when we import those snippets in LilyPond sources, we add a header at the beginning of each snippet source file automatically with a home-made Python script, and I think the only additions that are not too small to qualify for copyright are texidocs translations; should we require translators to put them there, or do we want to have English texidocs in public domain and translated ones under FDL? I prefer the former alternative. 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
Le samedi 19 septembre 2009 à 18:34 +0100, Graham Percival a écrit : I'd rather not keep track of individual licenses in the source tree. Since he's stated that his work is in public domain, there'd be no problems with people extracting it for any CC stuff. ... err wait, are we talking about Trevor Daniels, or Trevor Baca? Bloody mao, we're talking about the autor of cary.ly :-) HOWEVER, I'm quite willing to re-open the debate about licenses or relicensing or whatever -- as long as it's done at a convenient time. Right now is not convenient. Sure, so right now isn't convenient either to remove cary.ly and other so-said problematic files. If something's in the public domain, then we can take it an stamp a FDL onto it. Since the initial spark was to clarify the license situation, let's do that. Yes, let's do this for main manuals that include snippets. Or, we could add a boilerplate message that anything in input/snippets/ is public domain. Then we'd have /* GPLv2 /Documentation/* FDL /Documentation/snippets/* public domain where the most restrictive search pattern selects the license. We already stamp each snippet in Documentation/snippets public domain, and state it at the beginning of Snippets document, so it shows up in PDF, Info and HTML. We could protect the first page of the document under FDL, but would that make any sense? 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
Anthony W. Youngman wrote: Aarrgghh. The snippets are not public domain, unless the author put them there. The *music* may be public domain, but the *arrangement* is copyright whoever wrote the lilypond code (unless you make the argument that the snippet is too small to qualify for copyright). The snippets are taken from the LSR and a condition of submission to the LSR is that you consign your work to the public domain (and that you have the right to do so). I know, because I submitted a couple of snippets to the LSR and they later made it into the Lilypond docs' selection of snippets. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
In message 4ab53f73.1080...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net writes Anthony W. Youngman wrote: Aarrgghh. The snippets are not public domain, unless the author put them there. The *music* may be public domain, but the *arrangement* is copyright whoever wrote the lilypond code (unless you make the argument that the snippet is too small to qualify for copyright). The snippets are taken from the LSR and a condition of submission to the LSR is that you consign your work to the public domain (and that you have the right to do so). I know, because I submitted a couple of snippets to the LSR and they later made it into the Lilypond docs' selection of snippets. What happens if you're German :-) (I don't know, but there's been a fair bit of discussion, on and off, on debian legal as to whether it is even *possible* for some people to consign their work to the public domain - the *law* apparently says they *can't*) 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 Sun, Sep 20, 2009 at 12:28 AM, Anthony W. Youngman lilyp...@thewolery.demon.co.uk wrote: (I don't know, but there's been a fair bit of discussion, on and off, on debian legal as to whether it is even *possible* for some people to consign their work to the public domain - the *law* apparently says they *can't*) Hence the need for the WTFPL: http://sam.zoy.org/wtfpl/ (yeah, I've already mentioned it, but it just never gets old :-) Cheers, Valentin ___ 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 Samstag, 19. September 2009 20:45:46 schrieb Anthony W. Youngman: In message 1253377160.11679.1824.ca...@localhost, John Mandereau On the opposite, note that snippets from LSR are public domain, not FDL. Aarrgghh. The snippets are not public domain, unless the author put them there. Exactly. By putting them on LSR, you are putting it into PD. See e.g. http://lsr.dsi.unimi.it/LSR/html/whatsthis.html Also, the snippet submission page starts with the very sentence: Important: By entering your snippet, you are placing it in the public domain. This includes also snippets taken from the Lilypond manual (the manual authors grant you their permission to do so). And please don't argue that you were not aware, because that's there on the About page of the LSR, so if you still contribute it's you fault to not check. Not knowing doesn't prevent from prosecution, as we have a saying in (criminal) law studies here in Austria (Nichtwissen schützt vor Strafe nicht). The *music* may be public domain, but the *arrangement* is copyright whoever wrote the lilypond code (unless you make the argument that the snippet is too small to qualify for copyright). Again, by contributing to the LSR, the authors explicitly put it into PD (or one might argue that in jurisdictions without the notion of PD, they grant all rights they can give away, only retaining the moral rights that can't be signed away). 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) iD8DBQFKtWOlTqjEwhXvPN0RAviFAJ9BGMvLMvDSFAaULKxli+OK46qtWACeJV99 gp0Gez8rLmo/OyFIhwXH2lA= =llQu -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
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: Overview of copyright issues + Debian
Graham Percival wrote: 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. Brilliant. So as far as the docs are concerned that reduces my task to 'Who contributed to ... ?' rather than 'Do they agree to ... ?' In that case I'll submit a patch with licensing notices for doc files. I will still work on identifying who should be credited as authors on a file-by-file basis. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Op donderdag 10-09-2009 om 23:47 uur [tijdzone +0100], schreef Graham Percival: On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote: On 9/10/09 4:02 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: 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. The FSF has always adviced and argued to use v2 or at your option any later version. I got tired of arguing with Han-Wen that being paranoid does not bring you anything and gave in to strict v2, so it was *me* who was monumentally stupid. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | 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
Carl Sorensen wrote: 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. There was no way they could have done that, unfortunately. :-( It's not a matter of GPLv3 accommodating GPLv2 but the other way round -- GPLv2 has a 'no additional clauses' requirement and GPLv3 applies ... additional clauses. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Francisco Vila wrote:
2009/9/11 Francisco Vila paconet@gmail.com:
Those stats are very old now.
They are now up to date, just in case.
http://paconet.org/lilypond-statistics/
Thanks very much for this! :-)
It leads to the question -- already in mind from browsing the git log --
who is 'fred'? There is no full name and no email ('fred fred'), but
a lot of commits are in his name. Is this someone responsible for much
code? Or just someone responsible for managing the git or cvs repo in
the past?
And no, it seems docs are (fortunately) already 'or later', so we don't
have to worry on that account. :-)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Le jeudi 10 septembre 2009 à 00:24 +0200, Joseph Wakeling a écrit : But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. For the record, I agree to license/relicense all my code contributions (mostly Python scripts and makefiles) under GPLv2+ or GPLv3+, and dual-license my doc contributions under GFDL1.1+ and GPLv2+. I also hope that I'll junk all dirty scripts I wrote before a copyright header is added to them, but I'm not sure I can achieve this :-) Cheers, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 11. September 2009 11:14:39 schrieb Joseph Wakeling:
Francisco Vila wrote:
2009/9/11 Francisco Vila paconet@gmail.com:
Those stats are very old now.
They are now up to date, just in case.
http://paconet.org/lilypond-statistics/
Thanks very much for this! :-)
FWIW, I've now added a .mailcap file, so names like wl or Andrew Hawyluk or
Carl Sorensen should now be combined with the correct names Werner
Lemberg, Andrew Hawryluk and Carl D. Sorensen.
So git shortlog or git shortlog -s should now give less contributors and a
better overview.
I've also added all adresses, which already use the correct name (I just took
the output of git shortlog -s -e and corrected some apparently wrong or
missing names).
There are some open committers, though:
Maximiliano m...@intelacer.(none)
Maximiliano mxg...@yahoo.it
Lilypond GDP lilyp...@server.kainhofer.com
kroger kroger
reuter reuter
root r...@tsubasa.(none)
andrew and...@obi-wan.(none)
erik erik
fred fred
uid67283 uid67283
It leads to the question -- already in mind from browsing the git log --
who is 'fred'? There is no full name and no email ('fred fred'), but
a lot of commits are in his name. Is this someone responsible for much
code?
IIRC, that's the name that Jan or Han-Wen used to import the old versions into
git (or svn).
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)
iD8DBQFKqhiLTqjEwhXvPN0RAt1/AKC2eg4shejENUxsFFNTJFC2rUVLKgCfY1vV
HvVtGe9lfprJD+a4s1lelbI=
=skRa
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
2009/9/11 Reinhold Kainhofer reinh...@kainhofer.com:
FWIW, I've now added a .mailcap file, so names like wl or Andrew Hawyluk
or
Carl Sorensen should now be combined with the correct names Werner
Lemberg, Andrew Hawryluk and Carl D. Sorensen.
So git shortlog or git shortlog -s should now give less contributors and a
better overview.
Well, we have duplicated the effort. I mentioned this in this very thread.
There is no need to put names and addresses that are already correctly
spelt in the file; it only makes sense if names or addresses vary for
the same author. Anyway, we now have a comprehensive e-mail
directory.
There are some open committers, though:
...
kroger kroger
Pedro Kroger kroger
reuter reuter
Jürgen Reuter, reuter [at] ipd [dot] uka [dot] de
root r...@tsubasa.(none)
Graham Percival.
andrew and...@obi-wan.(none)
this could be Andrew Hawryluk or A. Wilson
erik erik
Erik Sandberg erik
fred fred
Han-Wen Nienhuys and Jan Nieuwenhuizen fred
uid67283 uid67283
Han-Wen Nienhuys uid67283, I think
It leads to the question -- already in mind from browsing the git log --
who is 'fred'? There is no full name and no email ('fred fred'), but
a lot of commits are in his name. Is this someone responsible for much
code?
IIRC, that's the name that Jan or Han-Wen used to import the old versions into
git (or svn).
I asked the same on February and here is the answer:
http://lists.gnu.org/archive/html/lilypond-devel/2009-02/msg00029.html
--
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
2009/9/11 Reinhold Kainhofer reinh...@kainhofer.com: So git shortlog or git shortlog -s should now give less contributors and a better overview. Please add Francisco Vila fr...@salvia.(none) Francisco Vila fr...@salvia.org so that Paco Vila gets redirected to me (that is the purpose of the file as I understand it) Other issues could arise; let's talk about them in private. I could also commit the changes that are necessary, directly. -- 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 11:14:39AM +0200, Joseph Wakeling wrote: It leads to the question -- already in mind from browsing the git log -- who is 'fred'? Please get into the habit of searching -devel before asking such questions. The answer is on the top 10 results for fred on a lilypond-devel search. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
In message 1252655677.8830.236.ca...@heerbeest, Jan Nieuwenhuizen janneke-l...@xs4all.nl writes Op donderdag 10-09-2009 om 23:47 uur [tijdzone +0100], schreef Graham Percival: On Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote: On 9/10/09 4:02 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: 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. The FSF has always adviced and argued to use v2 or at your option any later version. I got tired of arguing with Han-Wen that being paranoid does not bring you anything and gave in to strict v2, so it was *me* who was monumentally stupid. Jan. Well, Han-Wen is in good company - Linus! So I take this to mean all your code is v2+? Whatever Han-Wen said has no influence on YOUR code. And all we need is for Han-Wen to say he's happy with v3, and all your worries have gone away. (The problem is if Han-Wen goes away, but hopefully his will leaves all his copyrights to the FSF :-) You may have been monumentally stupid, but it wasn't arguing about paranoia. It was trying to apply YOUR choice of licence to SOMEONE ELSE'S CODE. That's ALWAYS a stupid idea. 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
Joseph Wakeling wrote Thursday, September 10, 2009 2:10 PM 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: I really can't get excited about this issue. I'm happy to donate my LilyPond contributions, which are almost entirely documentation and snippets, to the public domain. That should give you freedom to license them in the LilyPond distributions as you see fit. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
In message 3ccb7043-cf70-480b-84d1-27332fda9...@math.su.se, Hans Aberg hab...@math.su.se writes I don't see much point in continuing this discussion further because I don't think you understand what the real problems (or solutions) are, or what the requirements of the GPL (in any version) are. The point is that if you want to be up-to-date with latest GPL in both new restrictions and permissions, the only way to do it is to refer to the latest version when the source is published. 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. 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. 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
In message 4aa828d1.5000...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net writes Reinhold Kainhofer wrote: ... which I'm sure will NOT hold up in court, so I propose we really end this discussion. Please leave the lawyering to the lawyers and lets go back to coding. Please understand the motivation for OPENING this discussion -- not to debate which license or what license, but to propose a few concrete things the LP coding team can do to clarify licensing and (perhaps) make it easier to upgrade the license if that's desired. I'm very wary of the or later wording - I wouldn't want to push it on people. And there's a whole bunch of licences that are GPL-compatible that people might like to use. I think that the guidelines should say all new code must be licenced compatibly with v2 and v3. The preferred licence is 'v2 or later'. I particularly think it would be a good idea to make sure that all files in the source tree -- code and docs -- have both copyright and licensing statements in them. Yup. And the contributors file should list the over-riding licence chosen by any contributor. That way, if Joe Bloggs licenced everything under v2, then asks you to put him down as licencing his code v2 and v3, that change can be retroactive to ALL his code (there's no problem here because he's granting EXTRA rights). You probably want to put a copy of that email grant with the contributors file. More particularly, does anyone object to me adding a GFDL 1.1 or later notice to the doc files I have written? It's your copyright, licence it as you wish (provided it's not incompatible with what's gone before). One rider - please add the with no invariant sections etc wording so that it's compatible with the Debian Free Software Guidelines. You are aware the GFDL as it stands is not recognised as a Free licence? I'm not sure where you'll find that wording - probably on the Debian website, and almost certainly if you search debian-legal. Best wishes, -- Joe 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 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
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 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
In message eb078a48-7666-4486-bf94-a29a94abf...@math.su.se, Hans Aberg hab...@math.su.se 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 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
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 + 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
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
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 v.villen...@gmail.com wrote: On Thu, Sep 10, 2009 at 3:10 PM, Joseph Wakeling joseph.wakel...@webdrake.net 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
-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 joseph.wakel...@webdrake.net 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
In message 4aa8fadd.5050...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net 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 17:12:42 schrieb Anthony W. Youngman: In message 4aa8fadd.5050...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net 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
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
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
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
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 as a priority -- I have at least 50
Re: Overview of copyright issues + Debian
In message 200909101742.10364.reinh...@kainhofer.com, Reinhold Kainhofer reinh...@kainhofer.com writes Am Donnerstag, 10. September 2009 17:12:42 schrieb Anthony W. Youngman: In message 4aa8fadd.5050...@webdrake.net, Joseph Wakeling joseph.wakel...@webdrake.net 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
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
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 + 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: Overview of copyright issues
On Thu, Sep 10, 2009 at 7:02 PM, Graham Percival gra...@percival-music.ca 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 11:07:06PM +0100, Anthony W. Youngman wrote: In message 200909101742.10364.reinh...@kainhofer.com, Reinhold Kainhofer reinh...@kainhofer.com 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 9/10/09 4:02 PM, Graham Percival gra...@percival-music.ca 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 reinh...@kainhofer.com 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 Thu, Sep 10, 2009 at 04:37:46PM -0600, Carl Sorensen wrote: On 9/10/09 4:02 PM, Graham Percival gra...@percival-music.ca 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
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 think they get in the way of contribution -- it's more important to have the 'or later'
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
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
On Fri, Sep 11, 2009 at 12:47 AM, Graham Percival gra...@percival-music.ca 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
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
2009/9/11 Francisco Vila paconet@gmail.com: 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
On 9 Sep 2009, at 18:04, Joseph Wakeling wrote: 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 think that the formulation should be GPL, v2 or latest, because otherwise those that want to redistribute the code can choose which version, which is not the intent - v3 is in fact more restrictive with respect to tivoization. Only one GPL should be applicable. The formulation or later is probably spilled usage when indicating which version can be used - then it means one can choose version. This formulation also means that the distribution conditions may change, even though the copyright notice is not changed of a package, when new version of the GPL are issued. I think that is fully legal. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: I think that the formulation should be GPL, v2 or latest, because otherwise those that want to redistribute the code can choose which version, which is not the intent - v3 is in fact more restrictive with respect to tivoization. Only one GPL should be applicable. The formulation or later is probably spilled usage when indicating which version can be used - then it means one can choose version. The standard formulation, as advised in the GPL appendix which describes how to apply the GPL to your programs, is This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The whole point of this formulation is to give users of the program the option to choose which version of the license they want to be bound by if they redistribute or modify the code, and in particular to make it easy for a project to upgrade the license OR NOT. This formulation also means that the distribution conditions may change, even though the copyright notice is not changed of a package, when new version of the GPL are issued. I think that is fully legal. The problem with your formulation is that it is too restrictive. Consider this scenario: a program is being distributed as 'GPLv2 or latest' as you suggest. Someone writes a GPLv3 program which links with that code (as they are allowed to do at that point). Now Version 4 of the GPL is released. Suddenly the person with the second program can no longer keep linking to new releases of the first one, because 'GPLv2 or latest' now means v2 or v4 and neither v2 nor v4 are compatible with v3. It's a scenario that is completely undesirable. 'or later' basically is about making sure that writers of programs using all future versions of the GPL will have the right to link to or incorporate your code (as well as being handy if, as a community, you decide you want to upgrade the license). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 9 Sep 2009, at 20:30, Joseph Wakeling wrote: I think that the formulation should be GPL, v2 or latest, because otherwise those that want to redistribute the code can choose which version, which is not the intent - v3 is in fact more restrictive with respect to tivoization. Only one GPL should be applicable. The formulation or later is probably spilled usage when indicating which version can be used - then it means one can choose version. The standard formulation, as advised in the GPL appendix which describes how to apply the GPL to your programs, is This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The whole point of this formulation is to give users of the program the option to choose which version of the license they want to be bound by if they redistribute or modify the code, and in particular to make it easy for a project to upgrade the license OR NOT. You might check with the GNUers if it is the intention. It means that sources can be tivoized, even in the face of the new v3. This formulation also means that the distribution conditions may change, even though the copyright notice is not changed of a package, when new version of the GPL are issued. I think that is fully legal. The problem with your formulation is that it is too restrictive. Consider this scenario: a program is being distributed as 'GPLv2 or latest' as you suggest. Someone writes a GPLv3 program which links with that code (as they are allowed to do at that point). Now Version 4 of the GPL is released. Suddenly the person with the second program can no longer keep linking to new releases of the first one, because 'GPLv2 or latest' now means v2 or v4 and neither v2 nor v4 are compatible with v3. Linking is always allowed if you make sure the interfaces are provided and other linking info is provided - copyright only controls distribution of the parts that makes it creatively unique, and v3 seemed to have changed over v2 to bring that out. There is no legal requirement that the parts should have the same license. It's a scenario that is completely undesirable. 'or later' basically is about making sure that writers of programs using all future versions of the GPL will have the right to link to or incorporate your code (as well as being handy if, as a community, you decide you want to upgrade the license). But it has the effect that sources that formerly have been OK to distribute may not be so. For example, if they are tivoized, then when the GPL v3 now has arrived, the old sources cannot be tivoized, even if the package itself has not been changed. On the other hand, the formulation or later means that new sources can be tivoized even if the new version v3 has been released, unless they explicitly mention v3. It is a choice: when a new license is issued, if it is more restrictive, do you want it to apply or not? I just point this difference out - do what you prefer. Hans ___ 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 06:04:17PM +0200, Joseph Wakeling wrote: So, having read the past discussion and looked through source code etc. it seems like there are several general observations, some conclusions, and some questions. Observations: (1) Lilypond isn't violating any copyright/license requirements. So what's the point of this discussion? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Matthias Kilian wrote: On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: So, having read the past discussion and looked through source code etc. it seems like there are several general observations, some conclusions, and some questions. Observations: (1) Lilypond isn't violating any copyright/license requirements. So what's the point of this discussion? Part is that there's some general consensus that it would be nice to move Lilypond to GPLv3, or at least to have the chance to do so. Hence some of the practical points on how to make that easier. The other part is that there are some aspects of the way Lilypond code and docs are managed with respect to licensing that are confusing or problematic -- lack of licensing notices in source code, lack of copyright or licensing notices in docs. Those really should be fixed and better practices established for maintaining them. I would see that as pretty urgent actually, far more important than the 'what license?' question, because it relates to LP's ability to track who wrote what and which conditions they made it available under. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: You might check with the GNUers if it is the intention. It means that sources can be tivoized, even in the face of the new v3. It's GPLv2, and not the 'or later', that allows for tivoization -- but you have to question whether this is a serious risk for Lilypond. Linking is always allowed if you make sure the interfaces are provided and other linking info is provided - copyright only controls distribution of the parts that makes it creatively unique, and v3 seemed to have changed over v2 to bring that out. There is no legal requirement that the parts should have the same license. The parts need a compatible license if one links to the other. GPLv2 and GPLv3 are not compatible licenses. That's why the 'or later' is important -- it allows that compatibility. But it has the effect that sources that formerly have been OK to distribute may not be so. For example, if they are tivoized, then when the GPL v3 now has arrived, the old sources cannot be tivoized, even if the package itself has not been changed. On the other hand, the formulation or later means that new sources can be tivoized even if the new version v3 has been released, unless they explicitly mention v3. Again, the 'or later' has nothing to do with tivoization. It's GPLv2 that allows for that possibility (which, again, is not likely). If Lilypond does switch to GPLv3 I would strongly argue for a 'GPLv3 or later' formulation, to avoid this problem arising again if a further GPL revision is released. I don't think it matters much whether Lilypond moves to GPLv3 because most of the risks that GPLv3 is designed to obviate are unlikely to arise in the case of Lilypond. I _do_ think it matters that Lilypond be released under license terms that are compatible with GPLv3 and future potential releases of the GPL. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 9 Sep 2009, at 22:37, Joseph Wakeling wrote: You might check with the GNUers if it is the intention. It means that sources can be tivoized, even in the face of the new v3. It's GPLv2, and not the 'or later', that allows for tivoization ... Right. Do you want v2 to applicable by a re-distributor, even though v3 has been released? -- but you have to question whether this is a serious risk for Lilypond. This was only an example - a point to think through what you want. Linking is always allowed if you make sure the interfaces are provided and other linking info is provided - copyright only controls distribution of the parts that makes it creatively unique, and v3 seemed to have changed over v2 to bring that out. There is no legal requirement that the parts should have the same license. The parts need a compatible license if one links to the other. GPLv2 and GPLv3 are not compatible licenses. That's why the 'or later' is important -- it allows that compatibility. No. You need to make sure that the conditions of the individual licenses are fulfilled when re-distributing the parts. Think of a musical recording - is there a requirement that the licenses of the composer and the performer are the same? - A similar issue was treated in the case I mentioned before, the Beastie Boys flute sample case. The judge decided that though the flutist had rights to the flute sample, the composer - the same person as the flutist - did not have that, because the sample was too small to be creatively unique from the composing standpoint. So you consider each parts, and decide how the copyright applies to them. But it has the effect that sources that formerly have been OK to distribute may not be so. For example, if they are tivoized, then when the GPL v3 now has arrived, the old sources cannot be tivoized, even if the package itself has not been changed. On the other hand, the formulation or later means that new sources can be tivoized even if the new version v3 has been released, unless they explicitly mention v3. Again, the 'or later' has nothing to do with tivoization. It's GPLv2 that allows for that possibility (which, again, is not likely). As long as you use or later, tivoization and other new restriction in v3 is allowed. If Lilypond does switch to GPLv3 I would strongly argue for a ' GPLv3 or later' formulation, to avoid this problem arising again if a further GPL revision is released. I don't think it matters much whether Lilypond moves to GPLv3 because most of the risks that GPLv3 is designed to obviate are unlikely to arise in the case of Lilypond. I _do_ think it matters that Lilypond be released under license terms that are compatible with GPLv3 and future potential releases of the GPL. It is probably simplest to just make sure that the latest GPL is copied into the lilypond sources by some semi-automated scheme. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: As long as you use or later, tivoization and other new restriction in v3 is allowed. No, as long as you use _GPLv2_, whether it's GPLv2 or later or GPLv2 and only GPLv2, tivoization is possible. 'GPLv3 or later' would not allow tivoization. It is probably simplest to just make sure that the latest GPL is copied into the lilypond sources by some semi-automated scheme. Unless you have an 'or later' cause already in place, or you have the permission of the copyright holders, you cannot unilaterally substitute GPLv3 for GPLv2. That's what the whole problem is about. I don't see much point in continuing this discussion further because I don't think you understand what the real problems (or solutions) are, or what the requirements of the GPL (in any version) are. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On 9 Sep 2009, at 23:14, Joseph Wakeling wrote: As long as you use or later, tivoization and other new restriction in v3 is allowed. No, as long as you use _GPLv2_, whether it's GPLv2 or later or GPLv2 and only GPLv2, tivoization is possible. 'GPLv3 or later' would not allow tivoization. Right, but then the same problem arises if v4 prohibits fooization :-). It is probably simplest to just make sure that the latest GPL is copied into the lilypond sources by some semi-automated scheme. Unless you have an 'or later' cause already in place, or you have the permission of the copyright holders, you cannot unilaterally substitute GPLv3 for GPLv2. That's what the whole problem is about. I don't see much point in continuing this discussion further because I don't think you understand what the real problems (or solutions) are, or what the requirements of the GPL (in any version) are. The point is that if you want to be up-to-date with latest GPL in both new restrictions and permissions, the only way to do it is to refer to the latest version when the source is published. Or later will admit later restrictions, or latest will impose them quietly on old sources. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: The point is that if you want to be up-to-date with latest GPL in both new restrictions and permissions, the only way to do it is to refer to the latest version when the source is published. Or later will admit later restrictions, or latest will impose them quietly on old sources. No, it won't, because if a piece of code has been released under particular license conditions (say, GPLv2) you can't revoke that. You can't rewrite the license for old sources -- you can only upgrade the license for new releases. And for that, 'or later' is a much better formulation than 'or latest', because it also allows you to choose NOT to upgrade if that is your desire or interest. ___ 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 Mittwoch, 9. September 2009 23:30:19 schrieb Hans Aberg: The point is that if you want to be up-to-date with latest GPL in both new restrictions and permissions, the only way to do it is to refer to the latest version when the source is published. Or later will admit later restrictions, or latest will impose them quietly on old sources. ... which I'm sure will NOT hold up in court, so I propose we really end this discussion. Please leave the lawyering to the lawyers and lets go back to coding. Cheers, Reinhold PS: The or latest would also be the perfect weapon for anyone trying to spread FUD about open source, since now a third person (the FSF) has basically control about your code (i.e. it can now make your investments into open source suddenly illegal). Tell (or simply mention it slightly) that to any manager, and you can be sure that Open Source will be ruled out forever in that company. Imposing additional restrictions quietly on old sources is a big legal NO-NO. - -- - -- 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) iD8DBQFKqCPiTqjEwhXvPN0RAt2VAKDOe4G1/GBSi9n2T7vLH3LUVUnaLwCfQNIz 4I5WosJyvY3S3hS9xds4lL4= =c3MS -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 Wed, Sep 9, 2009 at 5:21 PM, Joseph Wakelingjoseph.wakel...@webdrake.net wrote: The other part is that there are some aspects of the way Lilypond code and docs are managed with respect to licensing that are confusing or problematic -- lack of licensing notices in source code, lack of copyright or licensing notices in docs. Those really should be fixed and better practices established for maintaining them. I would see that as pretty urgent actually, far more important than the 'what license?' question, because it relates to LP's ability to track who wrote what and which conditions they made it available under. Jan and I know that the current situation wrt copyright headers and license notes is not ideal, but we never could bring ourselves to fix it, because there always were more important things to do. Nevertheless, if someone feels energetic to take this on, they have my blessing. -- 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
Reinhold Kainhofer wrote: ... which I'm sure will NOT hold up in court, so I propose we really end this discussion. Please leave the lawyering to the lawyers and lets go back to coding. Please understand the motivation for OPENING this discussion -- not to debate which license or what license, but to propose a few concrete things the LP coding team can do to clarify licensing and (perhaps) make it easier to upgrade the license if that's desired. I particularly think it would be a good idea to make sure that all files in the source tree -- code and docs -- have both copyright and licensing statements in them. More particularly, does anyone object to me adding a GFDL 1.1 or later notice to the doc files I have written? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Han-Wen Nienhuys wrote: Jan and I know that the current situation wrt copyright headers and license notes is not ideal, but we never could bring ourselves to fix it, because there always were more important things to do. Nevertheless, if someone feels energetic to take this on, they have my blessing. Well, I'm happy to go fix the actual files, just not sure what the precise legal ramifications of this are. I mean, if _I_ change the copyright notice in a file that is _your_ copyright ... :-) But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. I'd consider taking on the paperwork side as well (not right now, maybe a month or two from now) but I want to try and to as much as possible of what can be done without it. What I could suggest as an approval mechanism is for individual authors to 'sign off' the patches (as git allows) that add licensing notices to their files, to show that they consent to what has been put there. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Wed, Sep 9, 2009 at 7:24 PM, Joseph Wakelingjoseph.wakel...@webdrake.net wrote: Han-Wen Nienhuys wrote: Jan and I know that the current situation wrt copyright headers and license notes is not ideal, but we never could bring ourselves to fix it, because there always were more important things to do. Nevertheless, if someone feels energetic to take this on, they have my blessing. Well, I'm happy to go fix the actual files, just not sure what the precise legal ramifications of this are. I mean, if _I_ change the copyright notice in a file that is _your_ copyright ... :-) Also, let's assume I am not interested in tiring myself, and that I will not try to sue for adding gpl headers to the source. But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your Let's postpone difficult decisions, and stick with gplv2 for the notices for now. thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. 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'd consider taking on the paperwork side as well (not right now, maybe a month or two from now) but I want to try and to as much as possible of what can be done without it. What I could suggest as an approval mechanism is for individual authors to 'sign off' the patches (as git allows) that add licensing notices to their files, to show that they consent to what has been put there. Sign-off: Han-Wen Nienhuys In general it would be good to know who reviewed what. -- 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
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), because that takes a lot of the sting out of potential future license upgrade decisions. I don't know whether that needs formal paperwork or whether emailed permission will suffice (again, allowing for the fact that LP contributors are most likely not interested in suing over such factors:-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Wed, 09 Sep 2009, Joseph Wakeling wrote: (6) Confusion has come from (i) a Debian copyright file for the package, apparently last updated in 2004, stating that Lilypond is 'v2 or later' 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.] (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]) 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. (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.) Don Armstrong 1: I've taken over maintenance of lilypond from Thomas Bushnell; hopefully I'll be able to keep up with you all. If any of you run across Debian specific issues, feel free to file bugs in our BTS or let me know personally. 2: Not sure if that's problem for you all, but it certainly means that Debian can't distribute it; it'll be removed from my source package as soon as I get a chance to do so. -- Your village called. They want their idiot back. -- xkcd http://xkcd.com/c23.html 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 10. September 2009 00:24:35 schrieb Joseph Wakeling: Han-Wen Nienhuys wrote: Jan and I know that the current situation wrt copyright headers and license notes is not ideal, but we never could bring ourselves to fix it, because there always were more important things to do. [...] But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. Just for the record: I'm perfectly fine with re-licensing my contributions from GPL v2 to GPL v2+. In fact, I don't really mind about the license. I would even be most comfortable with a BSD- or MIT-type license (i.e. can also be used in proprietary apps). However, I don't want to sign my contributions over to the FSF, since I want my contributions to help Lilypond in whatever ways might be needed, even commercial or proprietary. I don't want them as weapons in the hand of the FSF (i.e. use them to do what they think is best for open source, even if it might not be best for Lilypond). 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) iD8DBQFKqDCgTqjEwhXvPN0RAuTlAJ9kYcFuTeKOWdyqN/HtjvMUJ2kS+wCeIAsI g6e4TKoiWXb9E1RBvSCRS6k= =aNKy -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 Wed, Sep 9, 2009 at 7:48 PM, Reinhold Kainhoferreinh...@kainhofer.com wrote: However, I don't want to sign my contributions over to the FSF, since I want my contributions to help Lilypond in whatever ways might be needed, even commercial or proprietary. I don't want them as weapons in the hand of the FSF (i.e. use them to do what they think is best for open source, even if it might not be best for Lilypond). FSF assignments are non-exclusive, ie. the moment you sign over copyrights, they license the work irrevocably and without limitations back to you, and you are free to do what you want with it. -- 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
On 9/9/09 4:24 PM, Joseph Wakeling joseph.wakel...@webdrake.net wrote: Han-Wen Nienhuys wrote: Jan and I know that the current situation wrt copyright headers and license notes is not ideal, but we never could bring ourselves to fix it, because there always were more important things to do. Nevertheless, if someone feels energetic to take this on, they have my blessing. Well, I'm happy to go fix the actual files, just not sure what the precise legal ramifications of this are. I mean, if _I_ change the copyright notice in a file that is _your_ copyright ... :-) But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. GPLv2 works for me for both docs and source code. I will happily put my contributions under that license. Carl Sorensen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On 8 Sep 2009, at 02:42, Joe Neeman wrote: If you meant ghostscript in particular, then I guess we'll have to stay with ghostscript 8.70 for now. We don't link to ghostscript -- we merely call the command line program -- so the GPL doesn't apply. I think that copyright only applies to how it is redistributed, and not how it is used. Mac OS X LilyPond has a gs in its distribution. So its GPL version will apply to that part when (re-)distribution. So you need to make sure that when you distribute it, you do not violate any of its terms, like tivoization - which isn't an issue on Mac OS X. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
Le lundi 07 septembre 2009 à 16:42 -0700, Patrick McCarty a écrit : The part that (I think) is relevant to LilyPond is below: [...] The licensing of the Free version of the core Ghostscript code has been changed to GPLv3 or later. Previously, the core code was GPLv2 only. Ghostscript can now be used with GPLv3 applications, and can no longer be used with applications that are GPLv2-only. [...] Thoughts? Even if any program in LilyPond linked with gs, we'd have no problem since LilyPond is licensed under GPLv2+ (GPL v2 or later). Please correct me if I'm wrong. 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: Copyright issues
John Mandereau wrote: Even if any program in LilyPond linked with gs, we'd have no problem since LilyPond is licensed under GPLv2+ (GPL v2 or later). Please correct me if I'm wrong. That was the point of the re-opening of discussion -- my query on that very point in relation to the new website design. The COPYING file in Lilypond source code references GPLv2 only. The copyright file in my distro (Ubuntu) refers to GPLv2 or later, which may be where confusion comes from. Past discussion on -devel notes that LP is v2 only and the difficulty comes from the paperwork needed to get permission from contributors to move to 'v2 or later' or 'v3 or later'. By the way, I note that individual source/documentation files often have no notice of copyright or license. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
Op dinsdag 08-09-2009 om 12:34 uur [tijdzone +0200], schreef Joseph Wakeling: The copyright file in my distro (Ubuntu) refers to GPLv2 or later Which file are you referring to, and what does it say? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | 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: Copyright issues
Op dinsdag 08-09-2009 om 13:02 uur [tijdzone +0200], schreef Joseph
Wakeling:
Jan Nieuwenhuizen wrote:
Op dinsdag 08-09-2009 om 12:34 uur [tijdzone +0200], schreef Joseph
Wakeling:
The
copyright file in my distro (Ubuntu) refers to GPLv2 or later
Which file are you referring to, and what does it say?
/usr/share/doc/lilypond/copyright
Its contents:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
I cannot imagine this ever having been in the lilypond sources. It
may have been copied from somewhere else, possibly by mistake.
All the other scripts and control files for building and installing
GNU LilyPond under Debian GNU/Linux are also under the GNU General
Public License (GPL) version 2 or later.
*also* -- very confusing
I didn't read it properly before, but it looks like a severely
out-of-date notice added by the Debian packager which no one has ever
bothered to revise.
Not only out-of-date, but also /wrong/. I just checked our sources,
a very early one and the one that was claimed to be packaged
git show release/{1.0.1,2.2.2}:{COPYING,main.cc}
and none of these contain the or later clause.
A bug report should be filed here, any takers?
Thanks,
Jan.
--
Jan Nieuwenhuizen jann...@gnu.org | 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: Copyright issues
Op dinsdag 08-09-2009 om 13:16 uur [tijdzone +0200], schreef Jan
Nieuwenhuizen:
Not only out-of-date, but also /wrong/. I just checked our sources,
a very early one and the one that was claimed to be packaged
git show release/{1.0.1,2.2.2}:{COPYING,main.cc}
git show release/{1.0.1,2.2.2}:{COPYING,lily/main.cc
--
Jan Nieuwenhuizen jann...@gnu.org | 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: Copyright issues
Jan Nieuwenhuizen wrote:
Op dinsdag 08-09-2009 om 13:16 uur [tijdzone +0200], schreef Jan
Nieuwenhuizen:
Not only out-of-date, but also /wrong/. I just checked our sources,
a very early one and the one that was claimed to be packaged
git show release/{1.0.1,2.2.2}:{COPYING,main.cc}
git show release/{1.0.1,2.2.2}:{COPYING,lily/main.cc
There are several possible sources of this confusion.
First: nowhere in the LP source can I find the typical notice that the
FSF recommends/requests in the 'How to Apply These Terms to your new
program' appendix to the GPL.
The notice in the COPYING file is technically unambiguous but is so
atypical as to not necessarily be clear.
Second: Lilypond is part of the GNU project and GNU programs typically
have the 'or later' option, and indeed there is a perception that they
will upgrade to the latest GPL by default.
Third -- and this is really important: Lilypond's source code and other
files lack often copyright/licensing notices. This is explicitly
contrary to the policies of the GNU project:
http://www.gnu.org/prep/maintain/html_node/License-Notices.html#License-Notices
I gather there is a complete list of Lilypond contributors but are there
records of who contributed what?
Best wishes,
-- Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
I wrote: Second: Lilypond is part of the GNU project and GNU programs typically have the 'or later' option, and indeed there is a perception that they will upgrade to the latest GPL by default. ... see the general information on making a package part of the GNU project: http://www.gnu.org/help/evaluation.html A GNU program should use the latest version of the license that the GNU Project recommends—not just any free software license. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On Tue, Sep 8, 2009 at 6:51 AM, Hans Aberghab...@math.su.se wrote: If you meant ghostscript in particular, then I guess we'll have to stay with ghostscript 8.70 for now. We don't link to ghostscript -- we merely call the command line program -- so the GPL doesn't apply. I think that copyright only applies to how it is redistributed, and not how it is used. Mac OS X LilyPond has a gs in its distribution. So its GPL version will apply to that part when (re-)distribution. So you need to make sure that when you distribute it, you do not violate any of its terms, like tivoization - which isn't an issue on Mac OS X. The lilypond installer is an aggregration of several packages, each under its own license, rather than a derived work which would have to be under GPL. There is no problem here. -- 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: Copyright issues
Op dinsdag 08-09-2009 om 11:51 uur [tijdzone +0200], schreef Hans Aberg: On 8 Sep 2009, at 02:42, Joe Neeman wrote: I think that copyright only applies to how it is redistributed Almost, copyright is about copying. So its GPL version will apply No, it does not, as Joe pointed out. Can you please read the GNU GPL before spreading too much nonsense? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | 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: Copyright issues
On 8 Sep 2009, at 14:33, Han-Wen Nienhuys wrote: I think that copyright only applies to how it is redistributed, and not how it is used. Mac OS X LilyPond has a gs in its distribution. So its GPL version will apply to that part when (re-)distribution. So you need to make sure that when you distribute it, you do not violate any of its terms, like tivoization - which isn't an issue on Mac OS X. The lilypond installer is an aggregration of several packages, each under its own license, rather than a derived work which would have to be under GPL. There is no problem here. Right. That is my point. You need to make sure when you package the thing up for redistribution that you do not violate any copyright terms of the individual components. If you cannot ensure that for some components, an alternative is that the user takes down those components by themselves. There is no need that all components of a package have same copyright license. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On 8 Sep 2009, at 15:06, Jan Nieuwenhuizen wrote: Can you please read the GNU GPL before spreading too much nonsense? I have now looked through it, and found nothing of it. So you will have to clarify. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
Am Dienstag, 8. September 2009 16:19:43 schrieb Hans Aberg: On 8 Sep 2009, at 15:06, Jan Nieuwenhuizen wrote: On 8 Sep 2009, at 02:42, Joe Neeman wrote: I think that copyright only applies to how it is redistributed Almost, copyright is about copying. Quote? So its GPL version will apply No, it does not, as Joe pointed out. Can you please read the GNU GPL before spreading too much nonsense? It is not about the GPL, but the WIPO copyright treaty, and copyright law. The GPL cannot override that. gs is GPL v3+, so anything that links to it has to be compatible to GPL v3. Lilypond doesn't link, but simply call it, so there's no restriction here. However, as the installer also bundles gs, the provisions about distributing copies of gs found in the GPL v3 have to be fulfilled. Section 6. Conveying Non-Source Forms. is about distributing compiled versions, but I don't see any further restrictions there (source code available, etc, of course). So, what's the problem here? 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On 8 Sep 2009, at 15:06, Jan Nieuwenhuizen wrote: On 8 Sep 2009, at 02:42, Joe Neeman wrote: I think that copyright only applies to how it is redistributed Almost, copyright is about copying. Quote? So its GPL version will apply No, it does not, as Joe pointed out. Can you please read the GNU GPL before spreading too much nonsense? It is not about the GPL, but the WIPO copyright treaty, and copyright law. The GPL cannot override that. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On 8 Sep 2009, at 16:51, Reinhold Kainhofer wrote: Can you please read the GNU GPL before spreading too much nonsense? It is not about the GPL, but the WIPO copyright treaty, and copyright law. The GPL cannot override that. gs is GPL v3+, so anything that links to it has to be compatible to GPL v3. The GPL 3.0 now contains the following quote. It looks to me as saying that for linking, the interface must be made public, but does not say anything about the program itself. Read yourself to see if you agree with my interpretation. I brought up this point with RMS - the things is that copyright roughly speaking protects the distribution of the parts that are humanly creatively unique (suggested by the Beastie flute sample case). But it is not possible for one copyright license to interfere with another copyright ownership. The Corresponding Source for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. Lilypond doesn't link, but simply call it, so there's no restriction here. That is what I say: the form is looser, so it should be less complicated and controversial. The WIPO copyright treaty says that programs are protected as literary works in the sense od the Berne convention. So think about books. So this situation is more like a bookstore wanting to sell a book package. However, as the installer also bundles gs, the provisions about distributing copies of gs found in the GPL v3 have to be fulfilled. Section 6. Conveying Non-Source Forms. is about distributing compiled versions, but I don't see any further restrictions there (source code available, etc, of course). So, what's the problem here? Yes, this is what I also said. In your redistribution, you must make sure that you fulfill the copyright conditions, in as much as they do not abrogate local copyright law, of the individual packages. If GPL was able to impose conditions of other software components, then it would not be possible to distribute GPL'd Bison with BSD'd Flex, and not would Mac OS X be possible, which contains many GPL'd components along with some which actually are closed source. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
