Re: Potential LSR licensing violations
Le 21/10/2022 à 13:21, Kevin Barry a écrit : On Fri, Oct 21, 2022 at 01:12:09PM +0200, Jean Abou Samra wrote: -- AFAIK, this is the first time we have to do a relicensing, and the odds of a legal case involving LilyPond are very small due to its low-key profile in the industry. I feel this would be much ado about nothing. This is why I think it's usually better not to pay any attention to licence issues that don't come in the form of cease-and-desist or whatever. This whole exercise was (IMO) much ado about nothing. It would have helped IMO if all the more or less unrelated side questions had been raised in separate threads… And we are now left with the question of whether licensing is now part of the duties of LSR editors. As Thomas said, it's not mentioned in the CG. I guess we have to add it? What's the specification of that job? As I wrote to Harm (but maybe the mailing list didn't deliver that post to you yet), I don't think there is a lot to do. If you see a clear license violation, correct it, as we've done here. But this is likely to be rare and I don't think actively actively searching for violations is a good use of one's time. Jean
Re: Potential LSR licensing violations
On Fri, Oct 21, 2022 at 01:27:07PM +0200, Jean Abou Samra wrote: > It would have helped IMO if all the more or less unrelated side > questions had been raised in separate threads… Well yes, but it's totally unavoidable any time licencing comes up for discussion. The subject itself seems to be a magnet for generating endless pontificating (I'm guilty of this too). I see some messages in this thread about how included style files in LaTeX mean the resulting PDF is GPL. It reminds me of a similar discussion about LilyPond some years ago (about '\include "english.ly"' I think) that went nowhere, wasted everyone's time, and was never resolved. That discussion probably did the most in putting me off the subject for life. > What's the specification of that job? > > As I wrote to Harm (but maybe the mailing list didn't > deliver that post to you yet), I don't think there is > a lot to do. If you see a clear license violation, > correct it, as we've done here. The question of whether it's a requirement or not has nothing to do with how onerous it is. I can't weigh in on the specification of the duties because I wouldn't particularly be in favour of adding that responsibility to the LSR maintainers (but I won't object either). Kevin
Re: Potential LSR licensing violations
On Fri, Oct 21, 2022 at 01:12:09PM +0200, Jean Abou Samra wrote: > -- AFAIK, this is the first time we have to do a relicensing, > and the odds of a legal case involving LilyPond are very small > due to its low-key profile in the industry. I feel this would > be much ado about nothing. This is why I think it's usually better not to pay any attention to licence issues that don't come in the form of cease-and-desist or whatever. This whole exercise was (IMO) much ado about nothing. And we are now left with the question of whether licensing is now part of the duties of LSR editors. As Thomas said, it's not mentioned in the CG. I guess we have to add it? Kevin
Re: Potential LSR licensing violations
Le 21/10/2022 à 13:08, Luca Fascione a écrit : Well, the TeX people say that if the style file is GPL, the entire document is GPL, look: https://opensource.stackexchange.com/questions/2735/gpl-licensed-latex-template-implications-for-resulting-work So I think this constitutes evidence that actually that interpretation is the accepted one. This is the interpretation of one person, not "the TeX people" as a whole and not backed by a court case. If you look in the comments on that post, there is a lot of debate… even involving LilyPond.
Re: Potential LSR licensing violations
Le 20/10/2022 à 09:26, Luca Fascione a écrit : On Thu, Oct 20, 2022 at 9:07 AM Jean Abou Samra wrote: Anyway, this discussion is academical. It would have practical relevance if we were creating the project today. `git shortlog -s | wc -l` tells that there have been 236 contributors to the project. We cannot ask each of them to assign copyright to the LilyPond foundation even if we were to create it. To a point, though: first off, if you start change, you embark on a path that will eventually take you to a better place. Secondarily, although there are 236 contributors, how many have contributed code that is still alive (and needed)? I'm saying that I don't agree with your statement that we cannot ask 236 people to assign copyright. It seems to me it's far from impossible to send a couple hundred emails, filter the responses and blast out a code update. Of the X remaining (80?) we can analyze the impact of the corresponding code and proceed with a decision (a part of the project is in a difficult spot, code is rewritten, functionality turns out to be buggy or dead, many scenarios are possible). Besides, if a foundation in itself is needed, it doesn't seem impossible to get one going, is it? One thing that seems certain to me is that doing nothing guarantees there will be no change. I think the two advantages of copyright assignment you mention in your earlier email are very small in the context of LilyPond -- AFAIK, this is the first time we have to do a relicensing, and the odds of a legal case involving LilyPond are very small due to its low-key profile in the industry. I feel this would be much ado about nothing.
Re: Potential LSR licensing violations
Le 20/10/2022 à 15:46, Luca Fascione a écrit : To be clear: the potential issue I see is when the score or some of the headers it includes are GPL licensed, of course. Now of course the boundary between 'score' and 'lilypond plugin' in our case is particularly blurry, but still, it seems the question is germane to the discussion at hand. IMHO, such an interpretation by a court is unlikely. The truth, as with a number of legal things, is that we will never know for sure, because (with probability close to 1) no court will ever have to settle such a case. Cheers, Jean
Re: Potential LSR licensing violations
Le 21/10/2022 à 12:32, Jan Nieuwenhuizen a écrit : To my knowledge, this is a more or less isolated case. It would be simpler to have all of LSR in the public domain. Would you mind sending a written statement that you release this code under the public domain? Sure. Hereby I place this [legacy Banter chord names] code in the public domain or Creative Commons CC0 license, whichever you prefer. Thanks! I've edited the snippet to mention this statement. As far as I am concerned, the problem is cured. Cheers, Jean
Re: Potential LSR licensing violations
On Fri, Oct 21, 2022 at 1:00 PM Jean Abou Samra wrote: > Le 20/10/2022 à 15:46, Luca Fascione a écrit : > > To be clear: the potential issue I see is when the score or some of > > the headers it includes are GPL licensed, of course. > > Now of course the boundary between 'score' and 'lilypond plugin' in > > our case is particularly blurry, but still, it seems the > > question is germane to the discussion at hand. > > IMHO, such an interpretation by a court is unlikely. The truth, > as with a number of legal things, is that we will never know for > sure, because (with probability close to 1) no court will ever have > to settle such a case. > Well, the TeX people say that if the style file is GPL, the entire document is GPL, look: https://opensource.stackexchange.com/questions/2735/gpl-licensed-latex-template-implications-for-resulting-work So I think this constitutes evidence that actually that interpretation is the accepted one. As to whether this will be in court, I agree this is not too likely. All the same, if it did happen, I would not want to be a cause for well-meaning folks to be dragged into displeasing circumstances. I feel it was absolutely brilliant how Jan resolved the issue, showing that getting new permissions may actually not be that hard in practice and after all. Luca -- Luca Fascione
Re: Potential LSR licensing violations
Le 20/10/2022 à 21:41, Thomas Morley a écrit : Am Do., 20. Okt. 2022 um 02:34 Uhr schrieb Jean Abou Samra : I figured that now I am an LSR editor, I had to learn about what legal responsibility I have when accepting contributions. Well, I think the work of an LSR editor is roughly described in CG 7. LSR work. Afaict, license issues are not mentioned. Apart from obvious cases [*] I don't think it's my duty as an LSR editor to think about the problem at all. More: discussions about license issues inevitably causes headache to me. If we extend the duties of LSR editors in that way, i'll immediately step down from that role. Well, the next time someone submits a snippet with lots of code from LilyPond itself, you will likely recognize it. I don't think there is more to this than "obvious cases". Jean
Re: Potential LSR licensing violations
Jean Abou Samra writes: Hello Jean, > Adding you to this lilypond-devel thread. [..] > In doing so, Valentin didn't realize that moving this code to LSR was > a violation of the GPL, because the code was under GPL but LSR > snippets are in the public domain. Right. Sounds like an honest oversight. Thanks for bringing this to my attention. > To my knowledge, this is a more or less isolated case. It would be > simpler to have all of LSR in the public domain. Would you mind > sending a written statement that you release this code under the > public domain? Sure. Hereby I place this [legacy Banter chord names] code in the public domain or Creative Commons CC0 license, whichever you prefer. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond https://lilypond.org Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Potential LSR licensing violations
Hi Jan, Adding you to this lilypond-devel thread. Short story: in 2019, Valentin moved the legacy Banter chord names code from the LilyPond source to a snippet (https://lsr.di.unimi.it/LSR/Item?id=102). This code was originally written by you, with only minor fixes from other contributors as far as I can judge from the Git history. In doing so, Valentin didn't realize that moving this code to LSR was a violation of the GPL, because the code was under GPL but LSR snippets are in the public domain. To my knowledge, this is a more or less isolated case. It would be simpler to have all of LSR in the public domain. Would you mind sending a written statement that you release this code under the public domain? Thanks, Jean
Re: Potential LSR licensing violations
Am Do., 20. Okt. 2022 um 21:30 Uhr schrieb Han-Wen Nienhuys : > > On Thu, Oct 20, 2022 at 2:34 AM Jean Abou Samra wrote: > > So far, so good. However, take this snippet: > > > > https://lsr.di.unimi.it/LSR/Item?id=102 > > > > It begins with 300 lines of code that used to be in the LilyPond > > repository, released under the GPL, before they were considered > > legacy and moved to a snippet. I am pretty sure this violates > > the GPL. 300 lines looks too much for fair use law to apply, > > doesn't it? > > Why not ask Jan who wrote the chords snippet if is he OK to relicense > the snippet as public domain? (or, maybe he already did this when the > snippet was submitted) > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen > Yep, though pretty often the author of a snippet is not known to the LSR editor... Cheers, Harm
Re: Potential LSR licensing violations
Am Do., 20. Okt. 2022 um 02:34 Uhr schrieb Jean Abou Samra : > I figured that now I am an LSR editor, I had to learn about what > legal responsibility I have when accepting contributions. Well, I think the work of an LSR editor is roughly described in CG 7. LSR work. Afaict, license issues are not mentioned. Apart from obvious cases [*] I don't think it's my duty as an LSR editor to think about the problem at all. More: discussions about license issues inevitably causes headache to me. If we extend the duties of LSR editors in that way, i'll immediately step down from that role. Sorry, Harm [*] I hope copyright with https://lsr.di.unimi.it/LSR/Item?id=1005 is sufficently solved. See discussions: https://lists.gnu.org/archive/html/bug-lilypond/2016-04/msg4.html and finally: https://lists.gnu.org/archive/html/bug-lilypond/2020-03/msg00060.html
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 2:34 AM Jean Abou Samra wrote: > So far, so good. However, take this snippet: > > https://lsr.di.unimi.it/LSR/Item?id=102 > > It begins with 300 lines of code that used to be in the LilyPond > repository, released under the GPL, before they were considered > legacy and moved to a snippet. I am pretty sure this violates > the GPL. 300 lines looks too much for fair use law to apply, > doesn't it? Why not ask Jan who wrote the chords snippet if is he OK to relicense the snippet as public domain? (or, maybe he already did this when the snippet was submitted) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 1:47 PM Jean Abou Samra wrote: > > Le 20/10/2022 12:59 CEST, Luca Fascione a écrit : > > I think having GPL content in the lsr is the least desirable in the long > term, because either folks using it won't notice, or they might find > themselves unable or unwilling to use GPL as part of their content. > This came out too strong. I meant "there is a possibility/risk that folks might" L -- Luca Fascione
Re: Potential LSR licensing violations
Wols Lists writes: > On 20/10/2022 11:34, Jean Abou Samra wrote: >> The LSR distributes a piece of GPLed code under GPL-incompatible >> terms, which is illegal, period. I don't think I am imagining >> a problem here. Being an LSR-editor now, I don't like having >> my responsibility involved in copyright infringement. > > And as the linux kernel found out, David is wrong saying that only the > copyright holder can take enforcement action. > > German law allows people to take enforcement action without the > copyright holder's knowledge or consent. And somebody took active > advantage of that. Come again? Particularly in Germany, the bulk of Linux kernel enforcement actions have been taken by Harald Welte on behalf of his ipfilter/netfilter code in particular. What other examples do you have in mind? -- David Kastrup
Re: Potential LSR licensing violations
To be clear: the potential issue I see is when the score or some of the headers it includes are GPL licensed, of course. Now of course the boundary between 'score' and 'lilypond plugin' in our case is particularly blurry, but still, it seems the question is germane to the discussion at hand. L On Thu, Oct 20, 2022 at 1:56 PM Luca Fascione wrote: > Hum. It seems to me this is greyer that what you say. > > gcc transforms program.c into a.out > > Your access to a.out gives you rights to access program.c > > s/gcc/lilypond/; s/program.c/score.ly/; s/a.out/out.pdf/; > > I see very little difference. > > More importantly, what would lawyers and judges from various legislative > systems think about this? Our opinion counts up to a point (which is very > insignificant). > > I suspect it's not as clear cut as you make it. > > I am not a lawyer either. This message is not legal advice > > L > -- Luca Fascione
Re: Potential LSR licensing violations
Hum. It seems to me this is greyer that what you say. gcc transforms program.c into a.out Your access to a.out gives you rights to access program.c s/gcc/lilypond/; s/program.c/score.ly/; s/a.out/out.pdf/; I see very little difference. More importantly, what would lawyers and judges from various legislative systems think about this? Our opinion counts up to a point (which is very insignificant). I suspect it's not as clear cut as you make it. I am not a lawyer either. This message is not legal advice L On Thu, 20 Oct 2022, 13:47 Jean Abou Samra, wrote: > > Le 20/10/2022 12:59 CEST, Luca Fascione a écrit : > > > > > > Or you remove it, or you reimplement it > > > Well yes. > > > > I think having GPL content in the lsr is the least desirable in the long > term, because either folks using it won't notice, or they might find > themselves unable or unwilling to use GPL as part of their content. > > > Perhaps. > > > > I'm not clear what it means to have GPL source in a sheet of which you > have the pdf, it would seem to imply you'd have access to the whole > Lilypond source for it, maybe, if you asked for it. A publisher might be > unwilling to accept such terms, maybe > > > No; the GPL puts no restrictions on the output of the program, > only on the program itself and modified versions (and compiled > versions of it, but I really don't think compiling to PDF would > count, because the purpose of a PDF is to be viewed, not to be > executed like an executable produced by a C compiler). Cf. > > https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL > > LilyPond does embed a tagline, but it's so short you'd have trouble > claiming copyright on its text. The only thing in the output PDF > that could be considered copyrighted from LilyPond is the glyphs > from the Emmentaler font, and this is covered in the LICENSE file: > > * The files under mf/ form a font, and this font is dual-licensed > under the GPL+Font exception and the SIL Open Font License (OFL). > A copy of the OFL is in the file LICENSE.OFL. > > The font exception for the GPL stipulates the following exception: > > If you create a document which uses fonts included in LilyPond, > and embed this font or unaltered portions of this font into the > document, then this font does not by itself cause the resulting > document to be covered by the GNU General Public License. This > exception does not however invalidate any other reasons why the > document might be covered by the GNU General Public License. > If you modify one or more of the fonts, you may extend this > exception to your version of the fonts but you are not obliged > to do so. If you do not wish to do so, delete this exception > statement from your version. > > > In other words, everything is done properly so that an output PDF > from LilyPond is not covered by the GPL. > > However, if you use the -dembed-source-code option to embed your > source in the PDF, then the source remains under whatever license > you distribute it, independently from the graphical content of the > PDF. If it's adapted from source code found in LilyPond, it must be > GPL. > > IANAL (I should have said this on all my previous messages) >
Re: Potential LSR licensing violations
> Le 20/10/2022 12:59 CEST, Luca Fascione a écrit : > > > Or you remove it, or you reimplement it Well yes. > I think having GPL content in the lsr is the least desirable in the long > term, because either folks using it won't notice, or they might find > themselves unable or unwilling to use GPL as part of their content. Perhaps. > I'm not clear what it means to have GPL source in a sheet of which you have > the pdf, it would seem to imply you'd have access to the whole Lilypond > source for it, maybe, if you asked for it. A publisher might be unwilling to > accept such terms, maybe No; the GPL puts no restrictions on the output of the program, only on the program itself and modified versions (and compiled versions of it, but I really don't think compiling to PDF would count, because the purpose of a PDF is to be viewed, not to be executed like an executable produced by a C compiler). Cf. https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL LilyPond does embed a tagline, but it's so short you'd have trouble claiming copyright on its text. The only thing in the output PDF that could be considered copyrighted from LilyPond is the glyphs from the Emmentaler font, and this is covered in the LICENSE file: * The files under mf/ form a font, and this font is dual-licensed under the GPL+Font exception and the SIL Open Font License (OFL). A copy of the OFL is in the file LICENSE.OFL. The font exception for the GPL stipulates the following exception: If you create a document which uses fonts included in LilyPond, and embed this font or unaltered portions of this font into the document, then this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify one or more of the fonts, you may extend this exception to your version of the fonts but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version. In other words, everything is done properly so that an output PDF from LilyPond is not covered by the GPL. However, if you use the -dembed-source-code option to embed your source in the PDF, then the source remains under whatever license you distribute it, independently from the graphical content of the PDF. If it's adapted from source code found in LilyPond, it must be GPL. IANAL (I should have said this on all my previous messages)
Re: Potential LSR licensing violations
Or you remove it, or you reimplement it I think having GPL content in the lsr is the least desirable in the long term, because either folks using it won't notice, or they might find themselves unable or unwilling to use GPL as part of their content. I'm not clear what it means to have GPL source in a sheet of which you have the pdf, it would seem to imply you'd have access to the whole Lilypond source for it, maybe, if you asked for it. A publisher might be unwilling to accept such terms, maybe L On Thu, 20 Oct 2022, 12:45 Jean Abou Samra, wrote: > > And there aren't many solutions. Either we get permission from > the copyright owners to release it to the public domain, or > we release it under the GPL instead of the public domain. > > > Jean > >
Re: Potential LSR licensing violations
On 20/10/2022 11:34, Jean Abou Samra wrote: The LSR distributes a piece of GPLed code under GPL-incompatible terms, which is illegal, period. I don't think I am imagining a problem here. Being an LSR-editor now, I don't like having my responsibility involved in copyright infringement. And as the linux kernel found out, David is wrong saying that only the copyright holder can take enforcement action. German law allows people to take enforcement action without the copyright holder's knowledge or consent. And somebody took active advantage of that. Cheers, Wol
Re: Potential LSR licensing violations
> Le 20/10/2022 12:13 CEST, Kevin Barry a écrit : > > > On Thu, Oct 20, 2022 at 02:32:58AM +0200, Jean Abou Samra wrote: > > What should we do about these snippets? Delete them? > My two cents is that we should leave it alone and not spend time talking > about licences because those discussions rarely arrive at answers, and > most of the time there isn't really a problem except in someone's > imagination. The subsequent discussion on copyright assignment is a different thing, but I think it is neither true here that there is no problem, nor that it is difficult to arrive at an answer. The LSR distributes a piece of GPLed code under GPL-incompatible terms, which is illegal, period. I don't think I am imagining a problem here. Being an LSR-editor now, I don't like having my responsibility involved in copyright infringement. And there aren't many solutions. Either we get permission from the copyright owners to release it to the public domain, or we release it under the GPL instead of the public domain. Jean
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 02:32:58AM +0200, Jean Abou Samra wrote: > What should we do about these snippets? Delete them? My two cents is that we should leave it alone and not spend time talking about licences because those discussions rarely arrive at answers, and most of the time there isn't really a problem except in someone's imagination. Kevin
Re: Potential LSR licensing violations
Werner LEMBERG writes: >> The LSR is advertised as being released under the public domain. >> [...] >> >> The following exceptions apply: >> >> * It does not apply to input files (contained in the directory >> tree Documentation/snippets/); these are in the public domain. >> [...] >> >> So far, so good. However, take this snippet: >> >> https://lsr.di.unimi.it/LSR/Item?id=102 >> >> It begins with 300 lines of code that used to be in the LilyPond >> repository, released under the GPL, before they were considered >> legacy and moved to a snippet. I am pretty sure this violates the >> GPL. 300 lines looks too much for fair use law to apply, doesn't >> it? > > Assuming that it is ok with , we can put his > outdated, GPLed code into the public domain. "Ask the author" is the correct solution here. > I guess the opposite happens, too: there are probably some snippets > that have been incorporated into LilyPond code over the years. Such > code must be sufficiently rewritten so that the GPL can and be applied. That is nonsensical. PD code can be incorporated as part of a GPLed code base. When push comes to shove, the GPL relies on copyright as the legal means to enforce compliance, and only the copyright holder of some code can sue for compliance. LilyPond is not a copyright-assigned project, so enforcement will always be on a hit-and-miss basis, relying on the author of specific passages to have an interest in pursuing legal measures. > This sounds like a good temporary solution. However, I suggest that > we either get permission by the author to change the license,[*] or > the code gets rewritten eventually so that the 'correct' license can > be applied (again). We don't need permission of the author to "change the license" from PD. We are free to license in whatever manner we like. But the only one who can enforce any license is the original author, and when they release something as PD, chances are that they are very much not interested in pursuing legal steps on our behalf. And we would have to prove that the respective copy was taken from our licensed code base rather than the original distribution of PD code, and that would be tricky without significant modification. And the copyright holder could hardly claim real damages for PD code, so one would have to fall back on statutory damages. Essentially, this is going to be a disaster for enforcement purposes, but permission by the original author is not going to make any difference. For the other direction (GPLed to PD), yes, we should check back with the author. > [*] Here comes the benefit of transferring the copyright to the FSF, > which can handle such things without having to ask the original > author AFAIK. LilyPond, however, inspite of being a GNU project, > doesn't ask contributors for such a copyright transfer. LilyPond is not considered a strategic part of GNU, one where the FSF would consider taking legal measures for enforcing the licensing. -- David Kastrup
Re: Potential LSR licensing violations
Am Do., 20. Okt. 2022 um 07:23 Uhr schrieb Werner LEMBERG : > > So far, so good. However, take this snippet: > > > > https://lsr.di.unimi.it/LSR/Item?id=102 > > > > It begins with 300 lines of code that used to be in the LilyPond > > repository, released under the GPL, before they were considered > > legacy and moved to a snippet. I am pretty sure this violates the > > GPL. 300 lines looks too much for fair use law to apply, doesn't > > it? > > Assuming that it is ok with , we can put his > outdated, GPLed code into the public domain. Harm, do you remember > the history of this snippet? Sorry, I don't remember, Cheers, Harm
Re: Potential LSR licensing violations
>> BTW, the term 'public domain' is problematic in Europe, since this >> US law construct doesn't necessarily mean the same in all >> countries, in particular not in Germany.[*] >> >> Maybe it should be changed to CC0 >> (https://creativecommons.org/publicdomain/zero/1.0/deed) for >> further contributions? > > I'm not seeing clearly into what that means for us. LSR is based in > Italy (hosted on a server provided by the University of Milan). If > a German citizen contributes a snippet, which definition of 'public > domain' applies? This is exactly the issue. By using CC0, the legal impacts are minimized. At the time of inventing the LSR, such copyright issues were handled in a rather lax way. Today, we (unfortunately) have to take a more informed point of view. Werner
Re: Potential LSR licensing violations
On 20/10/2022 01:32, Jean Abou Samra wrote: What should we do about these snippets? Delete them? Introduce an exception "snippets are in the public domain unless stated otherwise" and add headers to them stating they are under the GPL? Create a GPL subdirectory under the snippets directory? My worry is that if some snippets are GPL'd, people might try to add more. If we move them to a GPL sub-directory, the status is clear, we can block new additions, and we can contact the authors for permission to move them to the main PD directory. Cheers, Wol
Re: Potential LSR licensing violations
On 20/10/2022 06:55, Jean Abou Samra wrote: Le 20/10/2022 à 07:38, Jean Abou Samra a écrit : You just don't become the copyright owner of the code, i.e., the copyright header in the source repository should give the name of the original author. I have to correct myself. This is not correct, since copyright doesn't exist for something in the public domain (as opposed to something released under a permissive license). So the file headers need not mention any copyright at all, if the code is unmodified. Note that, in Europe, you have non-transferable author's rights. So in various jurisdictions, you cannot place stuff in the public domain. What you can do, is waive all rights other than those you cannot legally waive, which ends up approximating 3-clause BSD. Cheers, Wol
Re: Potential LSR licensing violations
> Le 20/10/2022 09:30 CEST, Werner LEMBERG a écrit : > > > >> You just don't become the copyright owner of the code, i.e., the > >> copyright header in the source repository should give the name of > >> the original author. > > I have to correct myself. This is not correct, since copyright > > doesn't exist for something in the public domain (as opposed to > > something released under a permissive license). So the file headers > > need not mention any copyright at all, if the code is unmodified. > BTW, the term 'public domain' is problematic in Europe, since this US > law construct doesn't necessarily mean the same in all countries, in > particular not in Germany.[*] > > Maybe it should be changed to CC0 > (https://creativecommons.org/publicdomain/zero/1.0/deed) for further > contributions? I'm not seeing clearly into what that means for us. LSR is based in Italy (hosted on a server provided by the University of Milan). If a German citizen contributes a snippet, which definition of 'public domain' applies?
Re: Potential LSR licensing violations
>> You just don't become the copyright owner of the code, i.e., the >> copyright header in the source repository should give the name of >> the original author. > > I have to correct myself. This is not correct, since copyright > doesn't exist for something in the public domain (as opposed to > something released under a permissive license). So the file headers > need not mention any copyright at all, if the code is unmodified. BTW, the term 'public domain' is problematic in Europe, since this US law construct doesn't necessarily mean the same in all countries, in particular not in Germany.[*] Maybe it should be changed to CC0 (https://creativecommons.org/publicdomain/zero/1.0/deed) for further contributions? Werner [*] https://opensource.stackexchange.com/questions/2711/what-are-the-limitations-of-cc0-vs-public-domain
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 9:07 AM Jean Abou Samra wrote: > Anyway, this discussion is academical. It would have practical > relevance if we were creating the project today. > `git shortlog -s | wc -l` tells that there have been > 236 contributors to the project. We cannot ask each of > them to assign copyright to the LilyPond foundation even > if we were to create it. > > To a point, though: first off, if you start change, you embark on a path that will eventually take you to a better place. Secondarily, although there are 236 contributors, how many have contributed code that is still alive (and needed)? I'm saying that I don't agree with your statement that we cannot ask 236 people to assign copyright. It seems to me it's far from impossible to send a couple hundred emails, filter the responses and blast out a code update. Of the X remaining (80?) we can analyze the impact of the corresponding code and proceed with a decision (a part of the project is in a difficult spot, code is rewritten, functionality turns out to be buggy or dead, many scenarios are possible). Besides, if a foundation in itself is needed, it doesn't seem impossible to get one going, is it? One thing that seems certain to me is that doing nothing guarantees there will be no change. L -- Luca Fascione
Re: Potential LSR licensing violations
> Le 20/10/2022 08:50 CEST, Luca Fascione a écrit : > > > > > > On Thu, Oct 20, 2022 at 7:40 AM Jean Abou Samra wrote: > > Le 20/10/2022 à 07:22, Werner LEMBERG a écrit : > > > > It would be a problem if we assigned copyright to the FSF. > > As you mentioned below, we don't do this. > > > > > [*] Here comes the benefit of transferring the copyright to the FSF, > > > which can handle such things without having to ask the original > > > author AFAIK. LilyPond, however, inspite of being a GNU project, > > > doesn't ask contributors for such a copyright transfer. > > I would think it to be a more sustainable way forward to assign the copyright > of contributions to the Lilypond project itself (or a similar entity, in > charge of the project > but not linked to the identity of one or more specific individuals). > > Some folks use a statement like "Copyright 2012, 2016-2019 The contributors > of the Lilypond Project", for example. > > This has two kinds of advantages: one is that in instances like this where it > becomes sensible to > re-license some content, this can be done in a way that is transparent and > doesn't necessitate > tracking down specific individuals. (At the moment this list is where these > discussion would happen, > so the archives will provide a mean to track down when and how a given > decision was made). > > The other advantage is that it provides better insulation for the individual > contributing persons > against non-benevolent external parties that might show up to assert rights > they might think > they have (rightfully or not). Classic example would be patent rights > infringement. > Although Lilypond is not a commercial project, nor it is a particularly big > one (so it's > unlikely to attract attention from unsavory characters), I do feel it would > be a good ethical > standard to apply on the part of the project managers and owners to try and > insulate the contributors > from potential unpleasantness. > I repeat my disclaimer: Although I have been part of extensive discussions on > this topic, > I am not a lawyer, and my words do not constitute legal advice. AFAIK, in order to assert copyright on something, you first have to exist legally. If you are not a physical person, you need to exist as an organization. We don't have a LilyPond foundation (yet). The scheme "Copyright by the authors of project X" is used in many FLOSS projects, but it does not mean that kind of assignment, it is merely a shortcut for listing the contributors individually. Copyright remains in the hands of the individual contributors, it is not transferred to some sort of organization. Anyway, this discussion is academical. It would have practical relevance if we were creating the project today. `git shortlog -s | wc -l` tells that there have been 236 contributors to the project. We cannot ask each of them to assign copyright to the LilyPond foundation even if we were to create it. Cheers, Jean
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 7:40 AM Jean Abou Samra wrote: > Le 20/10/2022 à 07:22, Werner LEMBERG a écrit : > > It would be a problem if we assigned copyright to the FSF. > As you mentioned below, we don't do this. > > > [*] Here comes the benefit of transferring the copyright to the FSF, > > which can handle such things without having to ask the original > > author AFAIK. LilyPond, however, inspite of being a GNU project, > > doesn't ask contributors for such a copyright transfer. > I would think it to be a more sustainable way forward to assign the copyright of contributions to the Lilypond project itself (or a similar entity, in charge of the project but not linked to the identity of one or more specific individuals). Some folks use a statement like "Copyright 2012, 2016-2019 The contributors of the Lilypond Project", for example. This has two kinds of advantages: one is that in instances like this where it becomes sensible to re-license some content, this can be done in a way that is transparent and doesn't necessitate tracking down specific individuals. (At the moment this list is where these discussion would happen, so the archives will provide a mean to track down when and how a given decision was made). The other advantage is that it provides better insulation for the individual contributing persons against non-benevolent external parties that might show up to assert rights they might think they have (rightfully or not). Classic example would be patent rights infringement. Although Lilypond is not a commercial project, nor it is a particularly big one (so it's unlikely to attract attention from unsavory characters), I do feel it would be a good ethical standard to apply on the part of the project managers and owners to try and insulate the contributors from potential unpleasantness. I repeat my disclaimer: Although I have been part of extensive discussions on this topic, I am not a lawyer, and my words do not constitute legal advice. Luca -- Luca Fascione
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 7:57 AM Jean Abou Samra wrote: > This is not correct, since copyright doesn't > exist for something in the public domain (as opposed to something released > under a permissive license). So the file headers need not mention any > copyright at all, if the code is unmodified. > If I may propose a thought, I suspect it would probably be wisest they asserted their status of being in the public domain explicitly. If nothing else this will avoid future questions. I've seen folks use statements like "This file was originally written in 2013 by Ay B. Cee, and he hereby placed in the public domain". Disclaimer: Although I have been part of extensive discussions on this topic, I am not a lawyer, and my words do not constitute legal advice. L -- Luca Fascione
Re: Potential LSR licensing violations
Le 20/10/2022 à 07:38, Jean Abou Samra a écrit : You just don't become the copyright owner of the code, i.e., the copyright header in the source repository should give the name of the original author. I have to correct myself. This is not correct, since copyright doesn't exist for something in the public domain (as opposed to something released under a permissive license). So the file headers need not mention any copyright at all, if the code is unmodified.
Re: Potential LSR licensing violations
Le 20/10/2022 à 07:22, Werner LEMBERG a écrit : Assuming that it is ok with , we can put his outdated, GPLed code into the public domain. Harm, do you remember the history of this snippet? [For such historical research it would be great if the LSR was actually a git repository that gets eventually mapped to a database by a script. Sebastiano, is there any chance for such a thing?] Why not, we have to check that he was the only contributor. I'll do that later today. I guess the opposite happens, too: there are probably some snippets that have been incorporated into LilyPond code over the years. Such code must be sufficiently rewritten so that the GPL can be applied. Why? Public domain means you can do whatever you want with it, including incorporating it into GPL code. You just don't become the copyright owner of the code, i.e., the copyright header in the source repository should give the name of the original author. It would be a problem if we assigned copyright to the FSF. As you mentioned below, we don't do this. What should we do about these snippets? Delete them? Introduce an exception "snippets are in the public domain unless stated otherwise" and add headers to them stating they are under the GPL? This sounds like a good temporary solution. However, I suggest that we either get permission by the author to change the license,[*] or the code gets rewritten eventually so that the 'correct' license can be applied (again). Werner [*] Here comes the benefit of transferring the copyright to the FSF, which can handle such things without having to ask the original author AFAIK. LilyPond, however, inspite of being a GNU project, doesn't ask contributors for such a copyright transfer. (OT) Yes. On the other hand, it's pretty burdensome administratively. I'm glad LilyPond does not do this. Guile recently stopped doing it, for this reason. So did GCC last year.
Re: Potential LSR licensing violations
> The LSR is advertised as being released under the public domain. > [...] > > The following exceptions apply: > > * It does not apply to input files (contained in the directory > tree Documentation/snippets/); these are in the public domain. > [...] > > So far, so good. However, take this snippet: > > https://lsr.di.unimi.it/LSR/Item?id=102 > > It begins with 300 lines of code that used to be in the LilyPond > repository, released under the GPL, before they were considered > legacy and moved to a snippet. I am pretty sure this violates the > GPL. 300 lines looks too much for fair use law to apply, doesn't > it? Assuming that it is ok with , we can put his outdated, GPLed code into the public domain. Harm, do you remember the history of this snippet? [For such historical research it would be great if the LSR was actually a git repository that gets eventually mapped to a database by a script. Sebastiano, is there any chance for such a thing?] I guess the opposite happens, too: there are probably some snippets that have been incorporated into LilyPond code over the years. Such code must be sufficiently rewritten so that the GPL can be applied. > What should we do about these snippets? Delete them? Introduce an > exception "snippets are in the public domain unless stated > otherwise" and add headers to them stating they are under the GPL? This sounds like a good temporary solution. However, I suggest that we either get permission by the author to change the license,[*] or the code gets rewritten eventually so that the 'correct' license can be applied (again). Werner [*] Here comes the benefit of transferring the copyright to the FSF, which can handle such things without having to ask the original author AFAIK. LilyPond, however, inspite of being a GNU project, doesn't ask contributors for such a copyright transfer.
Potential LSR licensing violations
Hi, I figured that now I am an LSR editor, I had to learn about what legal responsibility I have when accepting contributions. The LSR is advertised as being released under the public domain. This is supposed to work in conjunction with LilyPond contributors making modifications in snippets/new/ thanks to this bit of text in LICENSE.DOCUMENTATION: """ Permission is granted to copy, distribute and/or modify the documentation for GNU LilyPond under the terms of the GNU Free Documentation License as published by the Free Software Foundation, either version 1.3, or (at your option) any later version; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is contained in the file COPYING.FDL. The following exceptions apply: * It does not apply to input files (contained in the directory tree Documentation/snippets/); these are in the public domain. [...] """ So far, so good. However, take this snippet: https://lsr.di.unimi.it/LSR/Item?id=102 It begins with 300 lines of code that used to be in the LilyPond repository, released under the GPL, before they were considered legacy and moved to a snippet. I am pretty sure this violates the GPL. 300 lines looks too much for fair use law to apply, doesn't it? Something similar although less extreme is done in this snippet: https://lsr.di.unimi.it/LSR/Snippet?id=763 What should we do about these snippets? Delete them? Introduce an exception "snippets are in the public domain unless stated otherwise" and add headers to them stating they are under the GPL? Thanks, Jean
