lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LilyPond, LilyPond snippets and the GPL


From: David Kastrup
Subject: Re: LilyPond, LilyPond snippets and the GPL
Date: Thu, 31 Oct 2019 21:31:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Hans Åberg <address@hidden> writes:

>> On 31 Oct 2019, at 03:15, Carl Sorensen <address@hidden> wrote:
>> 
>>> On 10/30/19, 5:13 PM, "Hans Åberg" <address@hidden> wrote:
>>> 
>>>> On 30 Oct 2019, at 22:14, Carl Sorensen <address@hidden> wrote:
>>>> 
>>>>   The snippets should be LGPL for being includable under other
>>>> licenses, I believe, because the processed part remains in the
>>>> output, and thus copyrightable. Thus, they play the same role as
>>>> the Bison skeleton file and GCC libraries.
>>>> 
>>>> What processed part remains in the output?
>>> 
>>>    If say somebody makes a snippet on how to make special type of
>>> clef, then that is copyrightable, just as a font and its glyphs
>>> are, it would seem, and that copyright will remain if
>>> copy-and-pasted into user code.
>> 
>> In the US, a typeface is not copyrightable.  But a computer program
>> that makes a font or its glyphs is copyrightable.  I can see your
>> argument here.  But if this argument is true, then it seems that all
>> music set with LilyPond is GPL3, because the code for drawing beams,
>> stems, staff lines, and straight flags is in LilyPond and is
>> licensed under GPL3.  I find it very hard to believe that this is
>> true.  And certainly, as far as the FSF is concerned, this is not
>> true.
>
> All those parts should be LGPL, and also included headers, I believe:
> Not GPL, because that would legal technically force copyright
> limitations on the output, and not public domain, because then one
> could exploit the inputs in ways you do not want. But check with the
> experts.

I think this kind of stuff should just be exempt from licensing (namely
declared public domain) like stub code in GCC.  It doesn't survive into
PDF anyway (since PDF is not programmable and so the PostScript-to-PDF
conversion executes the code in question rather than converting it) and
it is very unusual to distribute PostScript these days instead of
executing it right away in the form of some document processing
workflow.

So that is indeed something that would warrant getting separate
appropriate licensing attention, but in most use cases it would end up
not being relevant since there are few workflows where a PostScript file
ends up as something to be distributed.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]