> Am 2019-11-01 um 12:16 schrieb J Martin Rushton
> :
>
> On 01/11/2019 10:45, Henning Hraban Ramm wrote:
>> BTW there is _no_ copyright on the design of sheet music, even if some music
>> publishers claim it.
>
> This depends upon the country. In the UK: "The typographical
> arrangement of
On 01/11/2019 10:45, Henning Hraban Ramm wrote:
>
>
> BTW there is _no_ copyright on the design of sheet music, even if some music
> publishers claim it.
>
This depends upon the country. In the UK: "The typographical
arrangement of a published edition lasts for 25 years from first
> Am 2019-10-31 um 03:15 schrieb Carl Sorensen :
>
> In the US, a typeface is not copyrightable. But a computer program that
> makes a font or its glyphs is copyrightable.
The "program code" of fonts is juristically not regarded a program, because it
is usually auto-generated by a design
> On 31 Oct 2019, at 22:10, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 31 Oct 2019, at 21:31, David Kastrup wrote:
>>>
All those parts should be LGPL, and also included headers, I believe:
Not GPL, because that would legal technically force copyright
limitations on
Hans Åberg writes:
>> On 31 Oct 2019, at 21:31, David Kastrup wrote:
>>
>>> 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
> On 31 Oct 2019, at 21:31, David Kastrup wrote:
>
>> 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
Hans Åberg writes:
>> On 31 Oct 2019, at 03:15, Carl Sorensen wrote:
>>
>>> On 10/30/19, 5:13 PM, "Hans Åberg" wrote:
>>>
On 30 Oct 2019, at 22:14, Carl Sorensen wrote:
The snippets should be LGPL for being includable under other
licenses, I believe, because the
> On 31 Oct 2019, at 03:15, Carl Sorensen wrote:
>
>> On 10/30/19, 5:13 PM, "Hans Åberg" wrote:
>>
>>> On 30 Oct 2019, at 22:14, Carl Sorensen wrote:
>>>
>>> The snippets should be LGPL for being includable under other licenses, I
>>> believe, because the processed part remains in the
On 10/30/19, 5:13 PM, "Hans Åberg" wrote:
> On 30 Oct 2019, at 22:14, Carl Sorensen 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
Urs:
...
> One of the main issues we have at play here (and that has been discussed
> by others in this thread) is that tools like LilyPond and LaTeX blur the
> lines between source, program, and document.
>
> The arguments that are expressed *for* a requirement to license the PDF
> (etc.)
Since I was off for nearly a day there may well be aspects I missed when
trying to read through the whole thread, but I have the feeling that
some thoughts still haven't been expressed.
Am 30.10.19 um 12:27 schrieb Urs Liska:
Sorry for being short: what you say is very much hiw I meant it but
> On 30 Oct 2019, at 22:14, Carl Sorensen 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
> On 30 Oct 2019, at 23:36, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 30 Oct 2019, at 23:05, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
The snippets should be LGPL for being includable under other licenses,
I believe, because the processed part remains in
Hans Åberg writes:
>> On 30 Oct 2019, at 23:05, David Kastrup wrote:
>>
>> Hans Åberg writes:
>>
>>> 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
Hans Åberg writes:
>> On 30 Oct 2019, at 18:48, Carl Sorensen wrote:
>>
>> This says to me that you can consider LSR snippets as part of the
>> code used to create music (any music, not just your specific music).
>> You can then put your specific music in a separate file, with
>> separate
On 10/30/19, 3:17 PM, "Hans Åberg" wrote:
> On 30 Oct 2019, at 22:14, Carl Sorensen 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
On 10/30/19, 3:10 PM, "Hans Åberg" wrote:
> On 30 Oct 2019, at 18:48, Carl Sorensen wrote:
>
>> In general this is legally impossible; copyright law does not give you
any say in the use of the output people make from their data using your
program. If the user uses your
> On 30 Oct 2019, at 23:05, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> 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
> On 30 Oct 2019, at 22:28, Carl Sorensen wrote:
>
>> On 10/30/19, 3:17 PM, "Hans Åberg" wrote:
>>
>>> On 30 Oct 2019, at 22:14, Carl Sorensen wrote:
>>>
The snippets should be LGPL for being includable under other licenses, I
believe, because the processed part remains in
> On 30 Oct 2019, at 22:14, Carl Sorensen 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
> On 30 Oct 2019, at 18:48, Carl Sorensen wrote:
>
>> In general this is legally impossible; copyright law does not give you any
>> say in the use of the output people make from their data using your program.
>> If the user uses your program to enter or convert her own data, the
>>
On 10/30, Karsten Reincke wrote:
> 1) I did not refer to the libstdc or anything else for which indeed
> the gcc runtime exception can be used. I am talking about the a bit
> abstract case of using a GPL licensed library or module or snippet as
> base of ones work compiled by the GCC to complere
From: Karsten Reincke
Date: Wednesday, October 30, 2019 at 9:02 AM
To: Henning Hraban Ramm , lilypond-user
Cc:
Subject: Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 15:08 +0100, Henning Hraban Ramm wrote:
[...]
It’s the same if you publish a book using TeX:
No, it isn't
On 10/30/19, 11:48 AM, "Karsten Reincke" wrote:
2) Your polemic attack is wrong and unfair. If you had read my posts
carefully,
you would know [and probably you know it, but withhold this aspect], that I
offered URS already the opportunity to integrate my coming lib -
intends the LGPL for libraries that do not provide any practical
> advantages over existing non-GPL'd alternatives.[2] The fact that you
> are complaining about the license instead of using a different library
> indicates that the license was probably chosen correctly.
>
> On 10/30, Karste
was probably chosen correctly.
On 10/30, Karsten Reincke wrote:
> I regret to be the messenger of bad news. But there is a simple
> solution: Don't use GPL licensed LilyPond snippets, if wou want to
> keep you rights. And perhaps convince the OpenLilyLib developers to
> relicense thei
On Wed, 2019-10-30 at 15:08 +0100, Henning Hraban Ramm wrote:
> [...]
> It’s the same if you publish a book using TeX:
No, it isn't.
> While original TeX is PD and some other parts have their own licenses, those
> never apply to the contents of your book or the PDF or printed version of it,
Am 2019-10-30 um 13:06 schrieb David Kastrup :
>
> You are correct that you cannot license the source under any license
> other than the GPL if you are going to distribute it containing GPL
> licensed snippets (the LSR snippets are PD, the Notation Reference
> contents GFDL). But the PDF
Am 30. Oktober 2019 12:45:06 MEZ schrieb Karsten Reincke :
>Dear Elaine
>
>On Tue, 2019-10-29 at 18:13 -0700, Flaming Hakama by Elaine wrote:
>> [...]
>> It seems you think that, if you use code from the LSR as part of your
>input
>> files, that you are obligated to distribute both the input
Karsten Reincke writes:
> Many thanks for your comment. It contains an important hint. BUt it is a bit
> apart
> from my crucial point:
>
> I am not arguing that my LilyPond work (or a snippet) is covered by
>the GPL because it is 'executed' by LilyPond. I argue that my code is
>covered by the
ilyPond score description. It
> is exactly the same case.
The score description in question reflecting the content of the score is
copyrighted by its author. Even when LilyPond was used for its
preparation, its copyright does not affect independently created
content.
> I regret to be the messen
Dear Elaine
On Tue, 2019-10-29 at 18:13 -0700, Flaming Hakama by Elaine wrote:
> [...]
> It seems you think that, if you use code from the LSR as part of your input
> files, that you are obligated to distribute both the input files and the
> resulting PDF/MIDI files under the GPL.
YES, if the
Sorry for being short: what you say is very much hiw I meant it but not all.
I'll clarify later but am currently on the road. Maybe tonight of tomorrow.
Am 30. Oktober 2019 12:09:37 MEZ schrieb Karsten Reincke :
>Dear Urs;
>
>many thanks for your clever thoughts! You brought up a very seductive
Dear Urs;
many thanks for your clever thoughts! You brought up a very seductive argument,
which I therefore will only summarize here for being sure that I've understood
you
correctly. May I condense your line of argumentation in the following way?
You point out that there could be a function in
pond matches perfectly: As we are must
distribute
binaries which are compiled by the gcc on the base a GPL licensed source code,
we
must also distribute the binaries (png) which are compiled by LilyPond on the
base
of a GPL licensed LilyPond score description. It is exactly the same case.
I re
On Wed, 2019-10-30 at 00:55 +, Carl Sorensen wrote:
>
> On 10/29/19, 5:46 PM, "David Kastrup" wrote:
>
> Karsten Reincke wrotes:
>
>[...]
> >
> > [4] But if a GPL licensed LilyPond snippet is used by another LilyPond
> > code (either by a functional call into the
> From: Karsten Reincke
> To: lilypond-user
> Cc: k.rein...@fodina.de
> Bcc:
> Date: Wed, 30 Oct 2019 00:06:32 +0100
> Subject: LilyPond, LilyPond snippets and the GPL
> By my last post, I, unfortunately, evoked a discussion concerning
> LilyPond, LilyPond snippets, an
On 10/29/19, 5:46 PM, "David Kastrup" wrote:
Karsten Reincke writes:
> By my last post, I, unfortunately, evoked a discussion concerning
> LilyPond, LilyPond snippets, and the GPL which actually did not belong
> to the original topic. During this dis
Karsten Reincke writes:
> On Wed, 2019-10-30 at 00:46 +0100, David Kastrup wrote:
>> [...]
>>
>> I disagree with your assessment that calling any code/function makes
>> the
>> work doing so a derivative of that code (that would concern using
>> OpenLilyLib code). [...]
>
> I agree with you,
On Wed, 2019-10-30 at 00:46 +0100, David Kastrup wrote:
> [...]
>
> I disagree with your assessment that calling any code/function makes
> the
> work doing so a derivative of that code (that would concern using
> OpenLilyLib code). [...]
I agree with you, that the question, when and how a piece
alone
and basically comment only on that one:
Am 30.10.19 um 00:06 schrieb Karsten Reincke:
By my last post, I, unfortunately, evoked a discussion concerning
LilyPond, LilyPond snippets, and the GPL which actually did not belong
to the original topic. During this discussion Harm stated, that „maybe
Karsten Reincke writes:
> By my last post, I, unfortunately, evoked a discussion concerning
> LilyPond, LilyPond snippets, and the GPL which actually did not belong
> to the original topic. During this discussion Harm stated, that „maybe
> LSR should better use GPL 3, not this de
By my last post, I, unfortunately, evoked a discussion concerning
LilyPond, LilyPond snippets, and the GPL which actually did not belong
to the original topic. During this discussion Harm stated, that „maybe
LSR should better use GPL 3, not this deprecated one (Public Domain)“.
Urs asked whether
43 matches
Mail list logo
