Re: LilyPond, LilyPond snippets and the GPL

[Carl Sorensen]

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 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. 
 

Carl

Re: English Version of Functional Harmony Analysis Symbols

[Gregory Hollands]

I believe these are called Scaled Degrees in English.
https://en.wikipedia.org/wiki/Degree_(music)

I'm not sure how they correspond with the Reimannian names, but here they
are:
 1 - Tonic
 2 - Supertonic
 3 - Mediant
 4 - Subdominant
 5 - Dominant
 6 - Submediant
b7 - Subtonic
 7 - Leading tone
 8 - Tonic

The problem with this method is that there's only one name for both b2 and
2, as well as b3 and 3, and also b6 and 6. Sometimes people use Tritone for
b5, but I'm not sure if that's part of this naming scheme.

Hope this helps,
-Greg



> Dear Sam
> I an looking for the Riemannian approach. Can you help me?
> On Wed, 2019-10-30 at 18:30 -0400, Sam Bivens wrote:
> > Hi Karsten,
> > The Riemannian system isn't as widely used among English-speaking
> circles as it
> > is in German-speaking circles. Are you looking for the non-Riemannian
> > translations for these terms (we tend to use Roman numerals), or would
> you
> > prefer to keep the Riemannian approach?
> > Sam
> >
> > On Wed, Oct 30, 2019 at 11:49 AM Karsten Reincke 
> wrote:
> > > Dear Friends;
> > > [...]
> > > Nevertheless, I need your help. I do not know the correct translations
> of the
> > > German / Italien names of the Functional Harmony Theory symbols. dict
> does not
> > > really help.
> > >
> > > Symbol | German | English
> > > -
> > > T  | Tonika | tonic
> > > Tp | Tonika-Parallele   |
> > > Tg | Tonika-Gegenklang  |
> > > S  | Subdominante   | subdominant
> > > Sp | Subdominant-Parallele  |
> > > Sg | Subdominant-Gegenklang |
> > > SS | Doppelsubdominante*|
> > > D  | Dominante  | dominant
> > > Dp | Dominant-Parallele |
> > > Dg | Dominant-Gegenklang|
> > > DD | Doppeldominante|
> > >
> > > Any proposal is welcome
> > >
> > > many thanks for your answers
> > > Karsten

Re: LilyPond, LilyPond snippets and the GPL

[karl]

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.) files resulting from a LilyPond or LaTeX run are all based on the 
> assumption that the graphical documents created like this are 
> "comparable to the binary resulting from a compilation using a "typical" 
> C compiler." I think (which others have stated earlier today) that the 
> culprit here is that these arguments (e.g. when pointing to resources 
> like https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary) 
> assume that a "resulting PDF document" can be considered equivalent to a 
> "resulting program" or "resulting software". It has been said several 
> times: the PDF/PNG/SVG resulting from a LilyPond run is a document, not 
> a program.
...

Just to provide a data point...

As I work with postscript files, the result is certaintly a program.
Also files (at least one) from the lilypond distribution are included
verbatim in the output (I.ps is just one file created using lilypond).

//
$ fgrep -a -A10 'procset (music-drawing-routines.ps)' I.ps
%%BeginResource: procset (music-drawing-routines.ps) 1 0
%!PS-Adobe-2.0
%
% Functions for direct and embedded PostScript

% Careful with double % as comment prefix.
% Any %%X comment is interpreted as DSC comments.

% TODO: use dicts or prefixes to prevent namespace pollution.

/pdfmark where
//
$ head -10 /Net/git/lilypond/ps/music-drawing-routines.ps 
%!PS-Adobe-2.0
%
% Functions for direct and embedded PostScript

% Careful with double % as comment prefix.
% Any %%X comment is interpreted as DSC comments.

% TODO: use dicts or prefixes to prevent namespace pollution.

/pdfmark where
//

Regards,
/Karl Hammar

Re: Tight spacing in mensural notation (was: Re: Cadenza Senza Tempo Problem)

[Graham King]

> On 30 Oct 2019, at 21:41, Thomas Morley  wrote:
> 
> Am Mi., 30. Okt. 2019 um 19:44 Uhr schrieb Graham King
> :
> 
>> Harm, I'm afraid I'm struggling with "#(ly:make-moment -3)"
>> 
>> The NR[2] shows four arguments to ly:make-moment, describes two of them, and 
>> then speaks a little obtusely of the _second_ argument to ly:make-moment 
>> being possibly negative, and I can't find any examples of a negative first 
>> (and only) argument online.  Most examples seem to use one argument, a 
>> positive rational, which I think I do understand.
>> 
>> Where does this syntax come from and what does it mean?
>> And why did you choose -3 ?
>> 
>> TIA
>> -- Graham
>> 
>> [2] 
>> http://lilypond.org/doc/v2.19/Documentation/notation/scheme-functions#index-ly_003amake_002dmoment
>> 
> 
> I intended to set common-shortest-duration to the length of a maxima,
> to get tight spacing, see IR
> (Similiar for base-shortest-duration, although this may be superfluous.)
> And I confused ly:make-moment and ly:make-duration :(
> 
> Though the duration-log of a maxima is -3, it's length is #
> 
> See:
> \new MensuralStaff {
>  \compressFullBarRests
>  \applyMusic
>#(lambda (mus)
>  (ly:music-set-property! mus 'duration (ly:make-duration -3))
>  (format #t "\n\tLength of music: ~a\n\tDuration of music: ~a"
>(ly:music-length mus)
>(ly:music-property mus 'duration))
>  mus)
>  b
> }
> 
> =>
> 
>Length of music: #
>Duration of music: #
> 
> 
> So you better change in my proposal common-shortest-duration to:
> \override SpacingSpanner.common-shortest-duration = #(ly:make-moment 8)
> 
> Cheers,
>  Harm

Harm,
many thanks!  There I was, feeling inadequate in the face of what was, 
evidently, some seriously recondite lilypond-fu :)
I understand now.

BTW, your \applyMusic lambda function is a really neat way of explaining a lot 
in a few lines.

-- Graham

Re: LilyPond, LilyPond snippets and the GPL

[Urs Liska]

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 
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 
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 a GPL licensed snippet 
which only
modifies the apperance of a score. Such a function does not concern the 
music
itself. And therefore, the copyleft effect is not applied of the music.



That is not fully to the point. What I mean is (and what others have 
expressed more succinctly) is that such a function (say my 
\diplomaticLineBreak) is a *tool* that you use to express some auctorial 
decision (whether artistic or scientific), and in that respect it is 
exactly equal to using \ottava or \accidentalStyle.




Then it seems that you try to generalize your argumentation: Every piece of
LilyPond code describing the music score does not not concern the music, 
but only
the appearance. Hence the, the copyleft effect can not be applied to any 
results
of the LilyPond compilation process (the pdfs, pngs, ...)



No, I don't think that properly reflects my argument.
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.) files resulting from a LilyPond or LaTeX run are all based on the 
assumption that the graphical documents created like this are 
"comparable to the binary resulting from a compilation using a "typical" 
C compiler." I think (which others have stated earlier today) that the 
culprit here is that these arguments (e.g. when pointing to resources 
like https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary) 
assume that a "resulting PDF document" can be considered equivalent to a 
"resulting program" or "resulting software". It has been said several 
times: the PDF/PNG/SVG resulting from a LilyPond run is a document, not 
a program.


The issue that makes this complicated is the fact that in LilyPond and 
LaTeX the "document" is expressed in the same domain (the .ly files and 
included files) as the software that produces it. This makes it somehow 
difficult to cleanly separate the domains I still argue that all the 
functionality that you can *use* to create your document is comceptually 
separate from the *content* of your document.


I would argue that (except that the example is of course too small to be 
copyrightable) in a situation with


% library.ily
myFunction = trill

% document.ly
\include "library.ily"
{
  c \myFunction
}

the content of library.ily is *code* while the content of document.ly is 
*content*, and you use library.ily to produce a document from your content.


To use yet another analogy: this is like if you are using GIMP and a 
plugin, where the license of that plugin has no bearing on the licensing 
of the produced image file.




Please tell me, whether I got your point or not. Again, it seems to 
seductive and
I want to consider it a bit longer, before I will answer



There's one more point, and I think that hasn't been brought up by 
anyone yet. At some point you say "You can't have and eat the cake." But 
that holds true for your approach as well. If you insist on the 
interpretation that the GPL used for a snippet or library forces you to 
also license your document with the GPL then this holds true for *any* 
document you compile with LilyPond. an LSR or openLilyLib snippet is 
technically and conceptually identical to LilyPond.


Maybe you are not fully aware of how LilyPond works:

 * There is LilyPond as a binary that is executed within your operating
   system.
 * You can extend LilyPond's capabilities using the Scheme scripting
   language, which is done in the snippets we're talking about
 * BUT: LilyPond itself includes a ton of .scm and .ly files that are
   not part of LilyPond-as-a-compiler but actually "included" in the
   document, either implicitly by LilyPond's startup routine or
   explicitly from your input files (as I've exemplified in my previous
   post).

These files and the functions provided by them are exactly the same as 
the functions you can copy from the LSR or include through openLilyLib. 
The are not part of the compiler but of the compiled document. And if 
you are convinced that the GPL of openLilyLib packages forces you to 

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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 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.

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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 the output, and thus
 copyrightable. Thus, they play the same role as the Bison skeleton
 file and GCC libraries.
>>> 
>>> LSR snippets are public domain already.
>> 
>> So then this is not an issue, but public domain means that it can be
>> exploited in ways you may not approve of, therefore LGPL would be
>> better. But I am not an expert on such matters.
> 
> For the snippets, that is a reasonable compromise avoiding the user
> having reservations and headaches.  They are more intended as starting
> points for your own documents than as cut&dry code.

As examples, I have also done that. So if everyone is happy with that, it is a 
non-issue.

Re: English Version of Functional Harmony Analysis Symbols

[Karsten Reincke]

Dear Sam

I an looking for the Riemannian approach. Can you help me?

On Wed, 2019-10-30 at 18:30 -0400, Sam Bivens wrote:
> Hi Karsten,
> The Riemannian system isn't as widely used among English-speaking circles as 
> it
> is in German-speaking circles. Are you looking for the non-Riemannian
> translations for these terms (we tend to use Roman numerals), or would you
> prefer to keep the Riemannian approach?
> Sam
> 
> On Wed, Oct 30, 2019 at 11:49 AM Karsten Reincke  wrote:
> > Dear Friends;
> > [...]
> > Nevertheless, I need your help. I do not know the correct translations of 
> > the
> > German / Italien names of the Functional Harmony Theory symbols. dict does 
> > not
> > really help. 
> > 
> > Symbol | German | English
> > -
> > T  | Tonika | tonic 
> > Tp | Tonika-Parallele   | 
> > Tg | Tonika-Gegenklang  |
> > S  | Subdominante   | subdominant
> > Sp | Subdominant-Parallele  |
> > Sg | Subdominant-Gegenklang |
> > SS | Doppelsubdominante*|
> > D  | Dominante  | dominant
> > Dp | Dominant-Parallele |
> > Dg | Dominant-Gegenklang|
> > DD | Doppeldominante|
> > 
> > Any proposal is welcome
> > 
> > many thanks for your answers
> > Karsten
 

Re: Hairpin.minimum-length gives wrong output

[Thomas Morley-2]

ptoye wrote
> What I want is the first quaver sf and the hairpin to finish before the
> next quaver, so that the 3rd quaver is at the same dynamic  as the 2nd
> one.
> 
> Here's a better MWV
> 
> \version "2.19.52"
> \language "english"
> {
>   <<
> \new Staff {
>   \time 2/4
>   \clef "treble"
>   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
>   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
>   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
>   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
> }
> \new Dynamics {
>   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
>   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
>   \override Hairpin.minimum-length = #10
>   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
>   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2
> }
>   >>
> }
> 
> Line 1 has the hairpin too late at both the start and endpoints. Line 2
> has a warning that the hairpin is too small. Line 3 has the end of the
> hairpin too late. Line 4 is fine.

Hi Peter,

I'm having a hard time to shorten your mail to the part I want to reply. 
I'd recommend to use plain text.
Right now I use the nabble-interface, because I failed to do it otherwise.
That's unneeded tedious.

Anyway, single Hairpins (not surrounded by other dynamic signs) should start
at the left of the starting note and end at the right of the target note. If
dynamic signs are present they are centered below their notes and the
Hairpin is printed in between. 
For subsequent Hairpins, end/new-start are printed a little left and right
from the corresponding notehead-center.
This is the typesetting rule as far as I can tell.

See LilyPond doing it:
\paper { ragged-right = ##f }
{ b4\> b\! }
{ b4\> b\> b\! }


Thus I think you're wrong saying
"Line 3 has the end of the hairpin too late."
And even your initial quoted statement is not at the lines of usual
typesetting rules.
The Hairpin _is_positioned correctly, although admittedly it looks terrible.
But this is due to the uneven spacing, not a wrong Hairpin.

Here: "Line 1 has the hairpin too late at both the start and endpoints" I'm
not sure what you want instead for the Hairpin-start, wherelse than after
the sforzato should it start? 
The endpoint is correct either (see above).
Alas, this line looks terrible as well.
By all means, the Hairpin is too short.

Similiar for line 2 of your example.

So, all these three examples look weird because the Hairpin is not long
enough.
This may be a weakness of LilyPond: A spanner doesn't push it's bounds,
unless forced. P.e. with setting minimum-length to a higher value. This is
not done automagically.

Thus line 4 looks best: The Hairpin is lengthened and positioned between the
two dynamic signs, each centerd below their notes. Although the uneven
spacing is still ugly.


So if you really want the Hairpin to end before the target note, you have to
ensure/set two things
(1) Help LilyPond, make the Hairpin long enough, i.e. set minimum-length to
a suitable value.
(2) For further tweaking use shortern-pair 

\paper { ragged-right = ##t }
{ 
\override Hairpin.shorten-pair = #'(0 . 1.5)
\override Hairpin.minimum-length = #10
b4\> b\! 
}


Cheers,
  Harm








--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

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 role as the Bison skeleton
>>> file and GCC libraries.
>> 
>> LSR snippets are public domain already.
>
> So then this is not an issue, but public domain means that it can be
> exploited in ways you may not approve of, therefore LGPL would be
> better. But I am not an expert on such matters.

For the snippets, that is a reasonable compromise avoiding the user
having reservations and headaches.  They are more intended as starting
points for your own documents than as cut&dry code.

-- 
David Kastrup

Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

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 copyright.  And the modified LilyPond (including the LSR
>> snippets) is a derivative work of LilyPond, and has GPL rights, and
>> you would be required to share all of that code.  But the created
>> music engraving (pdf, svg, or midi) is not a derivative work of
>> LilyPond, but an output of the program lilypond, and cannot be
>> restricted by the GPL, according to the FSF.
>
> 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.

LSR snippets are public domain already.

-- 
David Kastrup

Re: LilyPond, LilyPond snippets and the GPL

[Carl Sorensen]

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 the same role as the Bison skeleton file and GCC 
libraries.
> 
> What processed part remains in the output?

The part of them that one includes in ones own code, if large enough to be 
copyrightable. If you just look at them and write something else, it does not 
matter.


How so?  When I wrote fret-diagram code, and before it was accepted in the 
distribution, it could be contained in an included .ly file.

When the fret-diagram code was executed, no part of that code ended up in the 
resulting PDF or PNG files.  The fret-diagram code created ink at specified 
locations; but the specified locations were not part of the code I wrote.  
Instead they were generated by the interaction of the main lilypond 
distribution with the music input I wrote.  And the result was printed music 
that matched my intent.  If  the music was original, the copyright was mine.  
If I was transcribing music from another composer, the copyright remained with 
the composer.

The GPL had no influence on the copyright of the printed music.

Carl

Re: LilyPond, LilyPond snippets and the GPL

[Carl Sorensen]

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 program to enter or convert her own data, the 
copyright on the output belongs to her, not you. More generally, when a program 
translates its input into some other form, the copyright status of the output 
inherits that of the input it was generated from.
>> 
>> So the only way you have a say in the use of the output is if 
substantial parts of the output are copied (more or less) from text in your 
program. For instance, part of the output of Bison (see above) would be covered 
by the GNU GPL, if we had not made an exception in this specific case.
>> 
>> You could artificially make a program copy certain text into its output 
even if there is no technical reason to do so. But if that copied text serves 
no practical purpose, the user could simply delete that text from the output 
and use only the rest. Then he would not have to obey the conditions on 
redistribution of the copied text.
> 
> 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 copyright.  And the 
modified LilyPond (including the LSR snippets) is a derivative work of 
LilyPond, and has GPL rights, and you would be required to share all of that 
code.  But the created music engraving (pdf, svg, or midi) is not a derivative 
work of LilyPond, but an output of the program lilypond, and cannot be 
restricted by the GPL, according to the FSF.

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?

Carl

Re: New option for OOoLilyPond: PDF to SVG

[Klaus Blum]

Hi Carl, 


Carl Sorensen-3 wrote
> The two big issues I saw were font embedding and clipping the bounding
> box.  It seems like we ought to be able to adjust both of those in the svg
> output.
> Would it be possible to modify the effects of lilypond-book-preamble.ly on
> .svg files?

LilyPond does not embed fonts in svg output. Is this possible in general,
like in pdf files? 
lilypond-book-preamble.ly only works with the eps backend, not with the svg
one. 

AFAIK, there have been questions and discussions on the list about both of
those issues, but no solutions available yet. 


Carl Sorensen-3 wrote
> It seems to me that fixing lilypond svg output to match what we want
> would be a better approach long-term than trying to integrate the call of
> a pdf->svg converter.
> Nevertheless, calling the converter appears to be an immediate workaround.

100% agreed.  :)
Another solution would be a working pdf import for LibreOffice. But that
seems to be still a long way to go as well. 

Cheers, 
Klaus



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: English Version of Functional Harmony Analysis Symbols

[Sam Bivens]

Hi Karsten,
The Riemannian system isn't as widely used among English-speaking circles
as it is in German-speaking circles. Are you looking for the non-Riemannian
translations for these terms (we tend to use Roman numerals), or would you
prefer to keep the Riemannian approach?
Sam

On Wed, Oct 30, 2019 at 11:49 AM Karsten Reincke 
wrote:

> Dear Friends;
>
> as perhaps known, I try to refactor the LilyPond snippet
> http://lsr.di.unimi.it/LSR/Snippet?id=967 originally written by Klaus
> Blum. It is
> already in a good shape, but it is still not a 'library. If you want to
> follow the
> development steps, check out https://github.com/kreincke/harmonyli branch
> development. But for the moment, you wont't see much progress. I will
> anounce the
> first alpha release, when it is ready.
>
> Nevertheless, I need your help. I do not know the correct translations of
> the
> German / Italien names of the Functional Harmony Theory symbols. dict does
> not
> really help.
>
> Symbol | German | English
> -
> T  | Tonika | tonic
> Tp | Tonika-Parallele   |
> Tg | Tonika-Gegenklang  |
> S  | Subdominante   | subdominant
> Sp | Subdominant-Parallele  |
> Sg | Subdominant-Gegenklang |
> SS | Doppelsubdominante*|
> D  | Dominante  | dominant
> Dp | Dominant-Parallele |
> Dg | Dominant-Gegenklang|
> DD | Doppeldominante|
>
> Any proposal is welcome
>
> many thanks for your answers
> Karsten
>
> --
>   Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
>  Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
> 60431 Frankfurt a.M.  \/http://www.fodina.de/kr/
>
>
>
>

-- 
Sam Bivens, Ph.D.
Music Theory Faculty
Cleveland Institute of Music
11021 East Boulevard
Cleveland, OH 44106
sam.biv...@cim.edu

Re: New option for OOoLilyPond: PDF to SVG

[Klaus Blum]

Hi Carl,

Am 30.10.2019 um 18:34 schrieb Carl Sorensen:

The two big issues I saw were font embedding and clipping the bounding box.  It 
seems like we ought to be able to adjust both of those in the svg output.
Would it be possible to modify the effects of lilypond-book-preamble.ly on .svg 
files?

LilyPond does not embed fonts in svg output. Is this possible in
general, like in pdf files?
lilypond-book-preamble.ly only works with the eps backend, not with the
svg one.

AFAIK, there have been questions and discussions on the list about both
of those issues, but no solutions available yet.

It seems to me that fixing lilypond svg output to match what we want would be a 
better approach long-term than trying to integrate the call of a pdf->svg 
converter.
Nevertheless, calling the converter appears to be an immediate workaround.

100% agreed.  :)
Another solution would be a working pdf import for LibreOffice. But that
seems to be still a long way to go as well.

Cheers,
Klaus

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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
>> file and GCC libraries.
> 
> LSR snippets are public domain already.

So then this is not an issue, but public domain means that it can be exploited 
in ways you may not approve of, therefore LGPL would be better. But I am not an 
expert on such matters.

Re: Tight spacing in mensural notation (was: Re: Cadenza Senza Tempo Problem)

[Thomas Morley]

Am Mi., 30. Okt. 2019 um 19:44 Uhr schrieb Graham King
:

> Harm, I'm afraid I'm struggling with "#(ly:make-moment -3)"
>
> The NR[2] shows four arguments to ly:make-moment, describes two of them, and 
> then speaks a little obtusely of the _second_ argument to ly:make-moment 
> being possibly negative, and I can't find any examples of a negative first 
> (and only) argument online.  Most examples seem to use one argument, a 
> positive rational, which I think I do understand.
>
> Where does this syntax come from and what does it mean?
> And why did you choose -3 ?
>
> TIA
> -- Graham
>
> [2] 
> http://lilypond.org/doc/v2.19/Documentation/notation/scheme-functions#index-ly_003amake_002dmoment
>

I intended to set common-shortest-duration to the length of a maxima,
to get tight spacing, see IR
(Similiar for base-shortest-duration, although this may be superfluous.)
And I confused ly:make-moment and ly:make-duration :(

Though the duration-log of a maxima is -3, it's length is #

See:
\new MensuralStaff {
  \compressFullBarRests
  \applyMusic
#(lambda (mus)
  (ly:music-set-property! mus 'duration (ly:make-duration -3))
  (format #t "\n\tLength of music: ~a\n\tDuration of music: ~a"
(ly:music-length mus)
(ly:music-property mus 'duration))
  mus)
  b
}

=>

Length of music: #
Duration of music: #


So you better change in my proposal common-shortest-duration to:
\override SpacingSpanner.common-shortest-duration = #(ly:make-moment 8)

Cheers,
  Harm

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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 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?
>> 
>>The part of them that one includes in ones own code, if large enough to 
>> be copyrightable. If you just look at them and write something else, it does 
>> not matter.
> 
> How so?  When I wrote fret-diagram code, and before it was accepted in the 
> distribution, it could be contained in an included .ly file.
> 
> When the fret-diagram code was executed, no part of that code ended up in the 
> resulting PDF or PNG files.  The fret-diagram code created ink at specified 
> locations; but the specified locations were not part of the code I wrote.  
> Instead they were generated by the interaction of the main lilypond 
> distribution with the music input I wrote.  And the result was printed music 
> that matched my intent.  If  the music was original, the copyright was mine.  
> If I was transcribing music from another composer, the copyright remained 
> with the composer.
> 
> The GPL had no influence on the copyright of the printed music.

It depends on the snippet then: If it just processes, GPL suffices; if it is 
stuff that remains in the output albeit it processed form, it ought to be LPGL 
if one wants it to freely usable. The Bison skeleton file has stuff that part 
is copied verbatim, part processed with M4, and compiled with languages like 
C/C++, and the copyrightability remains through it all, that is why it is LGPL.

LGPL would be simplest not having to working through all individual cases. But 
that is just my take on it.

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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 libraries.
> 
> What processed part remains in the output?

The part of them that one includes in ones own code, if large enough to be 
copyrightable. If you just look at them and write something else, it does not 
matter.

Re: LilyPond, LilyPond snippets and the GPL

[Hans Åberg]

> 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 
>> copyright on the output belongs to her, not you. More generally, when a 
>> program translates its input into some other form, the copyright status of 
>> the output inherits that of the input it was generated from.
>> 
>> So the only way you have a say in the use of the output is if substantial 
>> parts of the output are copied (more or less) from text in your program. For 
>> instance, part of the output of Bison (see above) would be covered by the 
>> GNU GPL, if we had not made an exception in this specific case.
>> 
>> You could artificially make a program copy certain text into its output even 
>> if there is no technical reason to do so. But if that copied text serves no 
>> practical purpose, the user could simply delete that text from the output 
>> and use only the rest. Then he would not have to obey the conditions on 
>> redistribution of the copied text.
> 
> 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 copyright.  And the 
> modified LilyPond (including the LSR snippets) is a derivative work of 
> LilyPond, and has GPL rights, and you would be required to share all of that 
> code.  But the created music engraving (pdf, svg, or midi) is not a 
> derivative work of LilyPond, but an output of the program lilypond, and 
> cannot be restricted by the GPL, according to the FSF.

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.

Re: New option for OOoLilyPond: PDF to SVG

[Klaus Blum]

Hi Henning, 

thanks for your hints. 

Henning Hraban Ramm-3 wrote
> You can also use Inkscape on the command line. The call is like
> inkscape -z -f input.pdf -A output.svg

On my PC, this creates a SVG file that even Inkscape cannot read. 
I already experimented with 
inkscape -z -f input.pdf -l output.svg
but the resulting graphic is incomplete.

The thing is that Inkscape should be forced to use Poppler/Cairo instead of
its own internal library. 
Is there a command that can achieve that?

Cheers, 
Klaus



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: LilyPond, LilyPond snippets and the GPL

[mason]

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 the analogy used by
> other participants of this discussion.

Okay, then GCC didn't need to be brought up at all.  Sorry for
misunderstanding.  That said, a pdf generated by Lilypond still does not
need to contain or use any Lilypond code.  Users do not need to fear
that they will "lose their rights" if they use a GPL'd snippet.

> it is complete misleading if you say that I
> 
> a) want to enforce Urs to relicense his work

I'm not sure how else to interpret a call to "perhaps convince the
OpenLilyLib developers to relicense their work."  

Mason


signature.asc
Description: PGP signature

Re: LilyPond, LilyPond snippets and the GPL

[Carl Sorensen]

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.

Actually, it is.

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,
That's an unproven proposition
In the TeX world, it may be unproven.  In the GPL world, with the best legal 
advice the license creators could get, it is proven.  See their FAQ.
because the code of TeX (or LilyPond) isn’t in there, it was just used to 
generate the result. (Same if you use OS software to generate graphics, videos 
etc.)
Not it isn't.

Again - like others in this thread - you are mixing the cases

Actually, I think you are mixing the cases.

a) The GCC, the TeX-engine, and LilyPond are programs, which take a piece of 
source code and compile the output (Binary, PDF, PNG).

b) The licenses of these engines do not influence the licensing of the input or 
output.

c) But if the gcc compiles a source code, which uses the prework of a GPL 
licensed library, snippet, or anything else, then - in accordance to the GPL-v3 
§6 - the compiled program (binary) has also to be distributed under the terms 
of the GPL (strong copyleft effect). If you deny this statement, then you argue 
against the idea of the Free Software itself.

This is true, not because of the license of gcc, but because of the license of 
the program that is used by the gcc (the library).  And it holds true because 
the output of gcc is a *program*, i.e., a piece of software executed by the 
computer to achieve desirable results.  And it needs the four freedoms that the 
FSF cares about.

d) If the TeX engine compiles a LaTeX source code, which uses the prework of a 
GPL licensed style or anything else, then indeed - in accordance to the GPL-v3 
§6 (titled "Conveying Non-Source Forms"), the compiled result (the PDF etc.) 
has to be distributed under the terms of the GPL too. That's stated in and by 
the LaTex community (e.g. 
https://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages ). And 
that's the reason, why ctan mostly does not contain GPL licensed packages.

That’s stated by one person in the LaTeX community, and only upvoted by 3 
people in the LaTeX community.  I suppose it creates a non-zero risk of having 
that argument upheld, and you are free to act according to that risk.  
Personally, I am sure that if somebody tried to sue a user demanding the 
application of GPL to the output of the TeX processing based on the usage of a 
GPL package, the FSF would get involved in the lawsuit.  The FSF can’t afford 
to have this interpretation hold, because if this interpretation held up in 
court, nobody would ever license software by the GPL.  And it’s clearly 
contrary to the stated intent of the GPL.

Quoting from the GPL FAQ:

Is there some way that I can GPL the output people get from use of my program? 
For example, if my program is used to develop hardware designs, can I require 
that these designs must be free? 
(#GPLOutput)
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 copyright on the 
output belongs to her, not you. More generally, when a program translates its 
input into some other form, the copyright status of the output inherits that of 
the input it was generated from.
So the only way you have a say in the use of the output is if substantial parts 
of the output are copied (more or less) from text in your program. For 
instance, part of the output of Bison (see above) would be covered by the GNU 
GPL, if we had not made an exception in this specific case.
You could artificially make a program copy certain text into its output even if 
there is no technical reason to do so. But if that copied text serves no 
practical purpose, the user could simply delete that text from the output and 
use only the rest. Then he would not have to obey the conditions on 
redistribution of the copied text.
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 copyright.  And the modified 
LilyPond (including the LSR snippets) is a derivative work of LilyPond, and has 
GPL rights, and you would be required to share all of that code.  But the 
created music engraving (pdf, svg, or midi) is not a derivative work of 
LilyPond, but an output of the program lilypond, and cannot be restricted by 
the GPL, according to the FSF.

e) If the LilyPond engine compiles a LilyPond music source c

Re: New option for OOoLilyPond: PDF to SVG

[Henning Hraban Ramm]

> Am 2019-10-30 um 16:35 schrieb Klaus Blum :
> 
> For Mac, I don't have any idea. My knowledge about Macs is exactly zero.

As Nick stated, pfd2svg is available via HomeBrew, but also via MacPorts.
Mac users that are able to use LilyPond should be able to use one of those or 
even compile it on their own.

You can also use Inkscape on the command line. The call is like

inkscape -z -f input.pdf -A output.svg


Greetlings, Hraban
---
fiëé visuëlle
Henning Hraban Ramm
https://www.fiee.net

Re: Tight spacing in mensural notation (was: Re: Cadenza Senza Tempo Problem)

[Graham King]

> On 30 Oct 2019, at 00:05, Graham King  wrote:
> 
>> 
>> On 29 Oct 2019, at 22:12, Thomas Morley  wrote:
>> 
>> Am Di., 29. Okt. 2019 um 16:28 Uhr schrieb Graham King
>> :
>>> 
>>> 
>>> This unanswered part of Reggie's question in [1] lead me to re-scratch an 
>>> old itch.  In manuscripts and old printed editions of mensural notation, 
>>> notes and rests are horizontally densely-spaced without regard for their 
>>> musical duration.  I have struggled to reproduce this in lilypond, and the 
>>> nearest I can get is this:
>>> 
>>> 
>>> It would be good to be able to impose a small amount of horizontal space 
>>> between the noteheads, but I'm at a loss to see how that can be done.  Any 
>>> ideas?
>>> 
>>> -- Graham
>>> 
>>> [1] https://lists.gnu.org/archive/html/lilypond-user/2019-10/msg00420.html
>> 
>> Probably below may be of some help?
>> 
>> \paper { ragged-right = ##t }
>> 
>> \new Score \with {
>> \omit TimeSignature
>> \override SpacingSpanner.spacing-increment = 1
>> \override SpacingSpanner.base-shortest-duration = #(ly:make-moment -3)
>> \override SpacingSpanner.common-shortest-duration = #(ly:make-moment -3)
>> \override NoteHead.style = #'petrucci
>> 
>> %% play around with below, probably useful are settings between 2 and ~10
>> \override SpacingSpanner.shortest-duration-space = #2
>> }
>> 
>> {
>> \cadenzaOn
>> c'\longa \breve 1 \breve 1 2 2 1 4 4 1 2
>> %\bar "" \break % uncomment to observe effect
>> 2 8 8 8 8 c''1 b' a' g'
>> }
> 
> That's lovely. \override SpacingSpanner.shortest-duration-space = #3.5 
> results in something that could almost be from Cantiones Sacrae or any of the 
> movable-type printed editions of the period.
> 
> It will take me a little while to understand fully what you've done, but 
> thanks!
> 
> -- Graham

Harm, I'm afraid I'm struggling with "#(ly:make-moment -3)"

The NR[2] shows four arguments to ly:make-moment, describes two of them, and 
then speaks a little obtusely of the _second_ argument to ly:make-moment being 
possibly negative, and I can't find any examples of a negative first (and only) 
argument online.  Most examples seem to use one argument, a positive rational, 
which I think I do understand.

Where does this syntax come from and what does it mean?
And why did you choose -3 ?

TIA
-- Graham

[2] 
http://lilypond.org/doc/v2.19/Documentation/notation/scheme-functions#index-ly_003amake_002dmoment

Chop Notation Symbols

[Gregory Hollands]

Casey Driessen and Oriole Saña have developed some new symbols for notating
the violin/fiddle technique called chopping.

You can see .png images of these symbols here:
https://drive.google.com/drive/folders/15b2tNfqkp9jkpd1T3r1lcgulSbNfwWQ7

More background on the technique is available at:
https://www.caseydriessen.com/chop-notation-project

How would one add these symbols to LilyPond? I know it's possible to draw
shapes, but I'm not sure exactly how to do that.

Any help is greatly appreciated,
-Greg

Re: LilyPond, LilyPond snippets and the GPL

[Carl Sorensen]

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 - licensed 
under
the MIT license - into his OpenLIlyLib. I only refused and refuse to use 
any GPL
licensed Lilypond snippet as 'module' / 'lib' for my own work.

I am curious as to why you feel you cannot use any GPL licensed LilyPond 
snippet but you can use the GPL licensed lilypond itself.  What about a snippet 
makes it more invasive in terms of the GPL than the original program?  I don't 
understand.

Carl
 

Re: LilyPond, LilyPond snippets and the GPL

[Karsten Reincke]

On Wed, 2019-10-30 at 09:41 -0700, ma...@masonhock.com wrote:
> On 10/30, Karsten Reincke wrote:
> > Here, the analogy of gcc and Lilypond 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.
> 
> The rational for the GCC exception is "These libraries are automatically
> used by the object code that GCC produces. Because of that, if these
> libraries were simply distributed only under the terms of the GPL, all
> the object code that GCC produces would have to be distributed under the
> same terms."[1]
> 
> This does not apply here.  A pdf generated by Lilypond does not
> automatically use any snippets of Lilypond code.  A pdf reader can't
> even do anything with Lilypond code.  You can distribute the pdf under
> any license you want.  The GPL only comes into play if you distribute
> your Lilypond code.
> 
> All of this is beside the point, though.  The library that started this
> discussion (analysis) is for "graphical highlighting of musical
> analysis,"  which is probably not something you need in order to engrave
> and publish your music.  It seems more likely that the purpose behind
> this FUD about the GPL is to put pressure on Urs to relicense of
> analysis so that you can use it in harmonyli without having to comply
> with the GPL.
> 
> On 10/30, Karsten Reincke wrote:
> > RMS has invented the LGPL to ensure that free code stays free. (weak
> > copyleft effect).
> 
> RMS 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, 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 their work.
> 
> There it is.
> 
> Mason

Dear Mason;

before you shoot, you should perhaps carefully read the line of argumentation:

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 the analogy used by other participants of this discussion.

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 - licensed under
the MIT license - into his OpenLIlyLib. I only refused and refuse to use any GPL
licensed Lilypond snippet as 'module' / 'lib' for my own work.

3) And if you follow the thread thoroughly, you could also have known, that I 
was
asked by Urs to take a look at OpenLilyLib instead of inventing the wheel twice.
To reason why I can't do that is matter of courtesy.

Hence it is complete misleading if you say that I

a) want to enforce Urs to relicense his work
b) do not want to develop my own snippet (I am doing that already)

EOM
KARSTN 

-- 
  Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
60431 Frankfurt a.M.  \/http://www.fodina.de/kr/

Re: New option for OOoLilyPond: PDF to SVG

[Carl Sorensen]

On 10/30/19, 9:35 AM, "Klaus Blum"  wrote:

Dear OOoLilyPond users, 

I'm planning to add a new option to OOoLilyPond. 

At the moment, we only have the choice between three file formats: 
- PNG is a bitmap format with the obvious quality drawbacks. 
- EPS can only be used with OpenOffice (not LibreOffice) and cannot be
displayed on screen. 
- SVG offers good quality but requires quite some tweaking (described in 
http://lilypondblog.org/2018/02/ooolilypond-part-2-optimizing/
  ). Most
obvious drawback: You cannot use lilypond-book-preamble.ly

The two big issues I saw were font embedding and clipping the bounding box.  It 
seems like we ought to be able to adjust both of those in the svg output.

Would it be possible to modify the effects of lilypond-book-preamble.ly on .svg 
files?


PDF would be the ideal choice for an output format, but LibreOffice cannot
(yet?) import PDF files with satisfying quality. 

Now (why did I take so long?...) I had the idea to call an external program
to convert LilyPond's PDF output into SVG which then can be imported into
LibreOffice. 
Most obvious advantage: You can work with any template, just like it works
with PNG and EPS. No need for dedicated SVG templates.
My first test look very promising. 

In Linux, it seems to be quite easy: You can use pdf2svg which can be
installed with any packet manager. (Am I right?)

With Windows, it looks (as always?) more complicated: 
We need additional software capable to perform a command-line conversion
from PDF to SVG. It must be installed by the user, and OOoLilyPond needs to
know the exact command line to be called. 
In a forum post ( http://www.inkscapeforum.com/viewtopic.php?t=30252
  ) i found that
Inkscape cannot yet do that, but there is a "standalone" version of Poppler
that can be used: 
http://blog.alivate.com.au/wp-content/uploads/2018/10/poppler-0.68.0_x86.7z

  
While I still don't know whether to recommend a software that I don't know,
I've tried it and it performs allright.

For Mac, I don't have any idea. My knowledge about Macs is exactly zero.


Am I still missing something? Do you have any more thoughts, ideas,
recommendations, experiences, ... ?

It seems to me that fixing lilypond svg output to match what we want would be a 
better approach long-term than trying to integrate the call of a pdf->svg 
converter.

Nevertheless, calling the converter appears to be an immediate workaround.

Carl
 

Re: LilyPond, LilyPond snippets and the GPL

[mason]

On 10/30, Karsten Reincke wrote:
> Here, the analogy of gcc and Lilypond 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.

The rational for the GCC exception is "These libraries are automatically
used by the object code that GCC produces. Because of that, if these
libraries were simply distributed only under the terms of the GPL, all
the object code that GCC produces would have to be distributed under the
same terms."[1]

This does not apply here.  A pdf generated by Lilypond does not
automatically use any snippets of Lilypond code.  A pdf reader can't
even do anything with Lilypond code.  You can distribute the pdf under
any license you want.  The GPL only comes into play if you distribute
your Lilypond code.

All of this is beside the point, though.  The library that started this
discussion (analysis) is for "graphical highlighting of musical
analysis,"  which is probably not something you need in order to engrave
and publish your music.  It seems more likely that the purpose behind
this FUD about the GPL is to put pressure on Urs to relicense of
analysis so that you can use it in harmonyli without having to comply
with the GPL.

On 10/30, Karsten Reincke wrote:
> RMS has invented the LGPL to ensure that free code stays free. (weak
> copyleft effect).

RMS 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, 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 their work.

There it is.

Mason

[1] https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

[2] https://www.gnu.org/licenses/why-not-lgpl.html


signature.asc
Description: PGP signature

Re: New option for OOoLilyPond: PDF to SVG

[Nicholas Bailey]

On Wednesday, 30 October 2019 15:35:34 GMT Klaus Blum wrote:
> For Mac, I don't have any idea. My knowledge about Macs is exactly zero.
> 
> 
> Am I still missing something? Do you have any more thoughts, ideas,
> recommendations, experiences, ... ?
I don't know either, but the thing about MacOS is "it's Unix, Jim, but not as 
we know it".

I'd be very surprised if Mac users couldn't be asked to install pdf2svg via 
one of their pacakge managers such as Homebrew

https://brew.sh/

specifically:

https://formulae.brew.sh/formula/pdf2svg

Nick/.

Re: Hairpin.minimum-length gives wrong output

[Phil Holmes]

Re: Hairpin.minimum-length gives wrong output 
Try s8\sf\> s8-\hide\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2


--
Phil Holmes




 - Original Message - 

From: Peter Toye 



To: Phil Holmes ; lilypond-user@gnu.org 



Sent: Wednesday, October 30, 2019 3:51 PM

 Subject: Re: Hairpin.minimum-length gives wrong output
 


Sorry, a typo. Both lines should have \! rather than \p. What I want is the 
first quaver sf and the hairpin to finish before the next quaver, so that the 
3rd quaver is at the same dynamic  as the 2nd one.
 
Here's a better MWV
 
\version "2.19.52"
 \language "english"
 {
   <<
 \new Staff {
   \time 2/4
   \clef "treble"
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
 }
 \new Dynamics {
   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
   \override Hairpin.minimum-length = #10
   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2
 }
   >>
 }
 
Line 1 has the hairpin too late at both the start and endpoints. Line 2 has a 
warning that the hairpin is too small. Line 3 has the end of the hairpin too 
late. Line 4 is fine.
 
Best regards,
 
Peter
 mailto:lilyp...@ptoye.com
 www.ptoye.com
 
-
 Wednesday, October 30, 2019, 3:24:52 PM, Phil Holmes wrote:
 


  

  
  
  Not quite sure of the output you want here.  Your 2 lines of your example 
aren't the same since the top line has a piano dynamic on it and the lower line 
doesn't.  Is the first quaver supposed to have the sf immediately below it?  If 
so, where do you expect the p dynamic to be?  If it's below the second quaver, 
all lily can try to do is space the quavers to fit in the minimum length of 
your hairpin, which it does.
   
  --
   Phil Holmes


   





- Original Message -
 From: Peter Toye
 To: lilypond-user@gnu.org
 Sent: Wednesday, October 30, 2019 3:14 PM
 Subject: Hairpin.minimum-length gives wrong output
 
This minimal criminal seems to give  wrong output. I want to make sure that 
the hairpin lasts for exactly one quaver (1/8 note). The first line gives a 
warning message that the hairpin is too short. The second line adjusts the 
length of the hairpin but it's now too long.
 
To try it out you may need to modify the number of notes depending on the 
paper size.
 
\version "2.19.52"
 
\language "english"
 
{
   <<
 \new Staff {
   \time 2/4
   \clef "treble"
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
 }
 \new Dynamics {
   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
\override Hairpin.minimum-length = #5
   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2
 }
   >>
 }
  
 Regards,
 
Peter
 mailto:lilyp...@ptoye.com
 www.ptoye.com
 
  

Re: Hairpin.minimum-length gives wrong output

[Peter Toye]

Sorry, a typo. Both lines should have \! rather than \p. What I want is the 
first quaver sf and the hairpin to finish before the next quaver, so that the 
3rd quaver is at the same dynamic  as the 2nd one.

Here's a better MWV

\version "2.19.52"
\language "english"
{
  <<
\new Staff {
  \time 2/4
  \clef "treble"
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
}
\new Dynamics {
  s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
  s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
  \override Hairpin.minimum-length = #10
  s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2 2 2
  s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2
}
  >>
}

Line 1 has the hairpin too late at both the start and endpoints. Line 2 has a 
warning that the hairpin is too small. Line 3 has the end of the hairpin too 
late. Line 4 is fine.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Wednesday, October 30, 2019, 3:24:52 PM, Phil Holmes wrote:


Not quite sure of the output you want here.  Your 2 lines of your example 
aren't the same since the top line has a piano dynamic on it and the lower line 
doesn't.  Is the first quaver supposed to have the sf immediately below it?  If 
so, where do you expect the p dynamic to be?  If it's below the second quaver, 
all lily can try to do is space the quavers to fit in the minimum length of 
your hairpin, which it does.

--
Phil Holmes
 
 

- Original Message -
From: Peter Toye
To: lilypond-user@gnu.org
Sent: Wednesday, October 30, 2019 3:14 PM
Subject: Hairpin.minimum-length gives wrong output

This minimal criminal seems to give  wrong output. I want to make sure that the 
hairpin lasts for exactly one quaver (1/8 note). The first line gives a warning 
message that the hairpin is too short. The second line adjusts the length of 
the hairpin but it's now too long.

To try it out you may need to modify the number of notes depending on the paper 
size.

\version "2.19.52"

\language "english"

{
  <<
\new Staff {
  \time 2/4
  \clef "treble"
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
}
\new Dynamics {
  s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
   \override Hairpin.minimum-length = #5
  s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2
}
  >>
}
 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

English Version of Functional Harmony Analysis Symbols

[Karsten Reincke]

Dear Friends;

as perhaps known, I try to refactor the LilyPond snippet 
http://lsr.di.unimi.it/LSR/Snippet?id=967 originally written by Klaus Blum. It 
is
already in a good shape, but it is still not a 'library. If you want to follow 
the
development steps, check out https://github.com/kreincke/harmonyli branch
development. But for the moment, you wont't see much progress. I will anounce 
the
first alpha release, when it is ready.

Nevertheless, I need your help. I do not know the correct translations of the
German / Italien names of the Functional Harmony Theory symbols. dict does not
really help. 

Symbol | German | English
-
T  | Tonika | tonic 
Tp | Tonika-Parallele   | 
Tg | Tonika-Gegenklang  |
S  | Subdominante   | subdominant
Sp | Subdominant-Parallele  |
Sg | Subdominant-Gegenklang |
SS | Doppelsubdominante*|
D  | Dominante  | dominant
Dp | Dominant-Parallele |
Dg | Dominant-Gegenklang|
DD | Doppeldominante|

Any proposal is welcome

many thanks for your answers
Karsten

-- 
  Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
60431 Frankfurt a.M.  \/http://www.fodina.de/kr/

Re: Hairpin.minimum-length gives wrong output

[Phil Holmes]

Hairpin.minimum-length gives wrong output 
Not quite sure of the output you want here.  Your 2 lines of your example 
aren't the same since the top line has a piano dynamic on it and the lower line 
doesn't.  Is the first quaver supposed to have the sf immediately below it?  If 
so, where do you expect the p dynamic to be?  If it's below the second quaver, 
all lily can try to do is space the quavers to fit in the minimum length of 
your hairpin, which it does.


--
Phil Holmes




 - Original Message - 

From: Peter Toye 



To: lilypond-user@gnu.org 



Sent: Wednesday, October 30, 2019 3:14 PM

 Subject: Hairpin.minimum-length gives wrong output
 


This minimal criminal seems to give  wrong output. I want to make sure that the 
hairpin lasts for exactly one quaver (1/8 note). The first line gives a warning 
message that the hairpin is too short. The second line adjusts the length of 
the hairpin but it's now too long.
 
To try it out you may need to modify the number of notes depending on the paper 
size.
 
\version "2.19.52"
 
\language "english"
 
{
   <<
 \new Staff {
   \time 2/4
   \clef "treble"
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
   c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
 }
 \new Dynamics {
   s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
\override Hairpin.minimum-length = #5
   s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2
 }
   >>
 }
  
 Regards,
 
Peter
 mailto:lilyp...@ptoye.com
 www.ptoye.com

New option for OOoLilyPond: PDF to SVG

[Klaus Blum]

Dear OOoLilyPond users, 

I'm planning to add a new option to OOoLilyPond. 

At the moment, we only have the choice between three file formats: 
- PNG is a bitmap format with the obvious quality drawbacks. 
- EPS can only be used with OpenOffice (not LibreOffice) and cannot be
displayed on screen. 
- SVG offers good quality but requires quite some tweaking (described in 
http://lilypondblog.org/2018/02/ooolilypond-part-2-optimizing/
  ). Most
obvious drawback: You cannot use lilypond-book-preamble.ly

PDF would be the ideal choice for an output format, but LibreOffice cannot
(yet?) import PDF files with satisfying quality. 

Now (why did I take so long?...) I had the idea to call an external program
to convert LilyPond's PDF output into SVG which then can be imported into
LibreOffice. 
Most obvious advantage: You can work with any template, just like it works
with PNG and EPS. No need for dedicated SVG templates.
My first test look very promising. 

In Linux, it seems to be quite easy: You can use pdf2svg which can be
installed with any packet manager. (Am I right?)

With Windows, it looks (as always?) more complicated: 
We need additional software capable to perform a command-line conversion
from PDF to SVG. It must be installed by the user, and OOoLilyPond needs to
know the exact command line to be called. 
In a forum post ( http://www.inkscapeforum.com/viewtopic.php?t=30252
  ) i found that
Inkscape cannot yet do that, but there is a "standalone" version of Poppler
that can be used: 
http://blog.alivate.com.au/wp-content/uploads/2018/10/poppler-0.68.0_x86.7z
  
While I still don't know whether to recommend a software that I don't know,
I've tried it and it performs allright.

For Mac, I don't have any idea. My knowledge about Macs is exactly zero.


Am I still missing something? Do you have any more thoughts, ideas,
recommendations, experiences, ... ?

Cheers, 
Klaus




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Repeat ties within chords

[Peter Toye]

Dear Robin,

Thanks - I see from the bug reports that it's fixed in LP 2.21 but I don't know 
the release date for that.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Wednesday, October 30, 2019, 2:58:25 PM, Robin Bannister wrote:

> Peter Toye wrote:

>> Any ideas on how to get just the tied note showing a repeat


> https://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00226.html


> Cheers,
> Robin

Re: LilyPond, LilyPond snippets and the GPL

[Karsten Reincke]

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, 
That's an unproven proposition
> because the code of TeX (or LilyPond) isn’t in there, it was just used to
> generate the result. (Same if you use OS software to generate graphics, videos
> etc.)
Not it isn't.

Again - like others in this thread - you are mixing the cases

a) The GCC, the TeX-engine, and LilyPond are programs, which take a piece of
source code and compile the output (Binary, PDF, PNG).

b) The licenses of these engines do not influence the licensing of the input or
output.

c) But if the gcc compiles a source code, which uses the prework of a GPL 
licensed
library, snippet, or anything else, then - in accordance to the GPL-v3 §6 - the
compiled program (binary) has also to be distributed under the terms of the GPL
(strong copyleft effect). If you deny this statement, then you argue against the
idea of the Free Software itself.

d) If the TeX engine compiles a LaTeX source code, which uses the prework of a 
GPL
licensed style or anything else, then indeed - in accordance to the GPL-v3 §6
(titled "Conveying Non-Source Forms"), the compiled result (the PDF etc.) has to
be distributed under the terms of the GPL too. That's stated in and by the LaTex
community (e.g. 
https://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages ). And
that's the reason, why ctan mostly does not contain GPL licensed packages.

e) If the LilyPond engine compiles a LilyPond music source code, which uses the
prework of a GPL licensed LilyPond snippet, then - in accordance to the GPL-v3 
§6
(titled "Conveying Non-Source Forms"), the compiled result (the PDF, PNG) has to
be distributed under the terms of the GPL too.

Why should c) and d) be valid, but not e)? You can't have and eat the cake.

If we want to protect the 'biotope' of free and open source software from being
misused and if we want that others respect the licensing rules, then at least we
have to take the license texts as seriously as possible. They are not a hawker's
tray from which we can take what we love and ignore the rest. 

With best regards Karsten

Hairpin.minimum-length gives wrong output

[Peter Toye]

This minimal criminal seems to give  wrong output. I want to make sure that the 
hairpin lasts for exactly one quaver (1/8 note). The first line gives a warning 
message that the hairpin is too short. The second line adjusts the length of 
the hairpin but it's now too long.

To try it out you may need to modify the number of notes depending on the paper 
size.

\version "2.19.52"

\language "english"

{
  <<
\new Staff {
  \time 2/4
  \clef "treble"
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4\break
  c''8 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
}
\new Dynamics {
  s8\sf\> s8\p s4 | s2 2 2 2 2 2 2 2 2 2 2 2
   \override Hairpin.minimum-length = #5
  s8\sf\> s8\! s4 | s2 2 2 2 2 2 2 2 2 2
}
  >>
}
 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Re: Repeat ties within chords

[Robin Bannister]

Peter Toye wrote:


Any ideas on how to get just the tied note showing a repeat



https://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00226.html


Cheers,
Robin

Re: LilyPond, LilyPond snippets and the GPL

[Henning Hraban Ramm]

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 reflecting your source code is a derivative
> of the actual content-reflecting parts of the source code.  Of which you
> are the copyright holder.

It’s the same if you publish a book using TeX: 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, because the code of TeX (or 
LilyPond) isn’t in there, it was just used to generate the result. (Same if you 
use OS software to generate graphics, videos etc.)

A *program* that’s using open source code *contains* this code (in compiled 
form).

On the other hand if I write a book *about* TeX and show a lot of its code or 
copy examples from the FDL-licensed documentation, my book also falls under 
that license. While the publisher can sell copies, we can’t prohibit users to 
make their own copies, becaus the book is derived work of the publicly 
available documentation.


Greetlings, Hraban
---
fiëé visuëlle
Henning Hraban Ramm
https://www.fiee.net

Re: Using rumor with Docker container on MacOS

[Hans Åberg]

> On 30 Oct 2019, at 02:15, Carl Sorensen  wrote:
> 
>Frescobaldi 3 (without Rumor) also supports MIDI input.
> 
> Yes, but it only gets the notes.  Rumor will also capture durations.

For what it is worth, one can record it in GarageBand, select the track and 
copy, which produces a textual representation of the MIDI events on the 
clipboard.

Re: Using rumor with Docker container on MacOS

[Federico Bruni]

Il giorno mer 30 ott 2019 alle 01:15, Carl Sorensen 
 ha scritto:

Frescobaldi 3 (without Rumor) also supports MIDI input.

Yes, but it only gets the notes.  Rumor will also capture durations.  
From reading the Frescobaldi docs, there used to be a Rumor plugin.  
Now it appears we no longer have a Rumor plugin, but the base MIDI 
input ignores durations.


Is there a way to get durations off a MIDI keyboard in Frescobaldi?


No.

If you use current master, you can type the durations first, e.g.:

s2 s4. s8

and then replace the spacer rests with the notes played on keyboard.
This feature has been merged last month. This was the original PR:
https://github.com/frescobaldi/frescobaldi/pull/1039

See also these discussions:
https://github.com/frescobaldi/frescobaldi/issues/865
https://github.com/frescobaldi/frescobaldi/issues/839

Repeat ties within chords

[Peter Toye]

I'm trying to engrave some music where there is an alternative repeat end, and 
a single note within a chord is tied over. The tie works for the 1st 
alternative, but not for the 2nd. But adding \repeatTie in the alternative 
produces ties for all notes in the chord, and not just the tied one. 

Any ideas on how to get just the tied note showing a repeat

Here's a minimal criminal. The first and second parts tie to the first 
alternative but not to the second. The third (putting \repeatTie outside the 
chord) adds ties to all the notes (and the tie to the G is a bit short).

Any ideas as to how to get a single tie to the G in the 2nd alternative?

\version "2.19.52"

\language "english"

{
  \relative c'
  {
\repeat volta 2 {
  1
}
\alternative {
  {

  }
  {

  }
}
 
\repeat volta 2 {
  1
}
\alternative {
  {

  }
  {

  }
}
\repeat volta 2 {
  1
}
\alternative {
  {

  }
  {
\repeatTie
  }
}
  }
}

 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Articulation marks in a dynamic staff

[Peter Toye]

I'm trying to engrave some piano music where the composer (or probably the 
original 19th century engraver) has saved time by putting accents midway 
between the staves (see attached snip). I've tried to do this in a dynamic 
staff with LP code like

s4->

but this gives warning messages, although the output looks OK.

Is there a better way of doing this?
 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Re: LilyPond, LilyPond snippets and the GPL

[Urs Liska]

 

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 files and
>the
>> resulting PDF/MIDI files under the GPL.
>YES, if the LSR snippet was licensed under the GPL (In fact, the LSR
>snippets are
>not licensed under the GPL, they are Public Domain, I know!)
>> 
>
>> One thing you state is clearly incorrect:  "snippets are either
>linked into the
>> main code using the command #include “ABC.ly”..."   No, this is
>actually part of
>> the reason why the openlilylib is structured the way it is, since the
>LSR is
>> explicitly NOT a library or set of libraries, and many people find
>that
>> annoying.  openlilylib was started (as I understand it) by people who
>do want a
>> libary-based approach, since the LSR approach encourages lots of
>duplication.
>
>I cannot say anything about the methods of OpenLilyLib - because I did
>not find
>any 'Hello World' example which I could compile on my machine (Ubuntu
>19.10).
>(This is another topic, which I want to ignore in this context.)
>

openLilyLib may be awfully underdocumented, but there are usage examples all 
over the place, really. I think every package or module has an example next to 
it or a usage-wxamples directory...


>But at least without beside using OpenLilyLib you have to methods to
>use the LSR
>snippets: either you save the snippet in your file tree and insert an
>include
>directive into your code which takes the path to that file as an
>argument. Or you
>copy the snippet literally and directly into your code.
>
>
>> So, here we have the solution to your dilemma: don't copy them.  
>
>Yeep, that's what I will do: as long as I am afraid to lose not only my
>LilyPond
>code (which I do not care), but the rights of my using scientific /
>musical work,
>I won't use any snippet which is license und er GPl. All other snippets
>are ok.
>And the LSR is a great help.
>
>> [...] Besides the debate about the letter of the law, then there is
>the reality
>> check part.  
>> 
>> Which is to say, you seem to think that someone who voluntarily
>submitted
>> content to the LSR as "public domain" is going to turn around and
>state that,
>> because that language is either inaccurate, or does not hold
>relevance in their
>> legal domain, they will take you to court to force you to comply with
>the terms
>> and distribute both your input files and resulting PDFs, or desist in
>> distributing the work.  
>Yes and No. 
>
>No, because I do not believe, that contributors to the LSR, later on,
>change their
>mind or want to attack us due to an infringement based on the weakness
>of a local
>legal system (But can we really be sure? Do you know that we have a lot
>of  patent
>trolls and meanwhile also GPL trolls, who invented a business model on
>suing users
>because of a non-compliant use of a GPL licensed program?)
>
>And yes, because I believe in good systems. And if we minimize the
>weakness of a
>system, then we should do that. The weakness of the LSR is, that Europe
>does not
>know the idea of 'public domain' (based on the principle, that you
>first have to
>claim your copyrights before you grant any rights). In Europe, nearly
>every work
>has a copyright owner. Hence every snippet contributed by a European
>citizen
>legally is not correctly contributed. This could be healed by using the
>CC0: It
>also talks about the public domain, but it explicitly grants all rights
>to the
>users without requiring any service in return.
>
>Best regards Karsten

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

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 GPL if I use (include or copy) a GPL licensed
>snippet. And if it is covered, then in accordance to the GPL §6 (title:
>"Conveying Non-Source Forms") also the compiled version is covered by
>the GPL. (BTW: even a picture is binary code which is interpreted)

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 reflecting your source code is a derivative
of the actual content-reflecting parts of the source code.  Of which you
are the copyright holder.

So the solution is not to distribute your source code embedding GPLed
elements.

-- 
David Kastrup

Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

Karsten Reincke  writes:

> On Wed, 2019-10-30 at 01:36 +0100, David Kastrup wrote:
>> Karsten Reincke  writes:
>> 
>> > [...]
>> > 
>> > Hence, if I use a piece of software as library, snippet, or module,
>> > then I am using the advantage that I do not have to program that code
>> > by myself. I am saving costs and time. A very good indicator, that I am
>> > saving resources by using the prework of another programer, is the call
>> > of a function (or method or similar). Therefore, calling a function /
>> > method delivered by a GPL licensed software indicates that I create a
>> > derivative work and that the strong copyleft effect is triggered.
>> 
>> Which would imply that distributing your LilyPond input combined with
>> OpenLilylib code would require licensing your LilyPond input under the
>> GPL.
> Yes, exactly. That's my point.
>> 
>> It doesn't cover the output of running your LilyPond code, namely the
>> PDF.
>
> I am afraid that this statement does judicially not hold:
>
> LilyPond itself says that it works "[...] as a compiled system: [...] In some
> ways, LilyPond is more similar to a programming language [...]". Hence the
> viewpoint of Carl Sorensen seems to be valid: LilyPond is like the gcc. And 
> even
> in case of the gcc, the copyleft effect does not cover the outpout (the 
> compiled
> program).
>
> But in case of a GPL licensed LilyPond snippet (sic!), the copyleft effetc is
> triggered by the use of that snippet.

Why do you assume that?

> And the GPLv3 is very clear: §4 and §5 require us also to distribute
> the code of the embedding / using work under the terms of th GPL.

Embedding is not the same as using.

> And - under the title "Conveying Non-Source Forms" - §6 requires us
> also to distribute our non-source forms under the terms of the GPL.

It isn't a non-source form of the library but a non-source form of the
input representation of the music.

> Here, the analogy of gcc and Lilypond matches perfectly: As we are
> must distribute binaries which are compiled by the gcc on the base a
> GPL licensed source code,

The copyright/licensing of GCC has nothing to do with the
copyright/licensing of source code compiled with it.  There is a special
license clarification for stubs to be included in the binaries.
However, LSR code as a rule is not included in the resulting PDF or Midi
files.

> 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.

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 messenger of bad news. But there is a simple
> solution: Don't use GPL licensed LilyPond snippets, if wou want to
> keep you rights.

There is a difference between using _content_ of snippets and using
_mechanisms_ of snippets.

Apart from that, the list of snippets declares right at its start:

LilyPond — Snippets
***

This document shows a selected set of LilyPond snippets from the
LilyPond Snippet Repository (http://lsr.di.unimi.it) (LSR). It is in the
public domain.

while the LilyPond Notation Reference is licensed under the GFDL.

> And perhaps convince the OpenLilyLib developers to relicense their
> work.

I don't see the necessity as long as no _content_ of OpenLilyLib is
redistributed as matters of its output.

-- 
David Kastrup

Re: LilyPond, LilyPond snippets and the GPL

[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 files and the
> resulting PDF/MIDI files under the GPL.
YES, if the LSR snippet was licensed under the GPL (In fact, the LSR snippets 
are
not licensed under the GPL, they are Public Domain, I know!)
> 

> One thing you state is clearly incorrect:  "snippets are either linked into 
> the
> main code using the command #include “ABC.ly”..."   No, this is actually part 
> of
> the reason why the openlilylib is structured the way it is, since the LSR is
> explicitly NOT a library or set of libraries, and many people find that
> annoying.  openlilylib was started (as I understand it) by people who do want 
> a
> libary-based approach, since the LSR approach encourages lots of duplication.

I cannot say anything about the methods of OpenLilyLib - because I did not find
any 'Hello World' example which I could compile on my machine (Ubuntu 19.10).
(This is another topic, which I want to ignore in this context.)

But at least without beside using OpenLilyLib you have to methods to use the LSR
snippets: either you save the snippet in your file tree and insert an include
directive into your code which takes the path to that file as an argument. Or 
you
copy the snippet literally and directly into your code.


> So, here we have the solution to your dilemma: don't copy them.  

Yeep, that's what I will do: as long as I am afraid to lose not only my LilyPond
code (which I do not care), but the rights of my using scientific / musical 
work,
I won't use any snippet which is license und er GPl. All other snippets are ok.
And the LSR is a great help.

> [...] Besides the debate about the letter of the law, then there is the 
> reality
> check part.  
> 
> Which is to say, you seem to think that someone who voluntarily submitted
> content to the LSR as "public domain" is going to turn around and state that,
> because that language is either inaccurate, or does not hold relevance in 
> their
> legal domain, they will take you to court to force you to comply with the 
> terms
> and distribute both your input files and resulting PDFs, or desist in
> distributing the work.  
Yes and No. 

No, because I do not believe, that contributors to the LSR, later on, change 
their
mind or want to attack us due to an infringement based on the weakness of a 
local
legal system (But can we really be sure? Do you know that we have a lot of  
patent
trolls and meanwhile also GPL trolls, who invented a business model on suing 
users
because of a non-compliant use of a GPL licensed program?)

And yes, because I believe in good systems. And if we minimize the weakness of a
system, then we should do that. The weakness of the LSR is, that Europe does not
know the idea of 'public domain' (based on the principle, that you first have to
claim your copyrights before you grant any rights). In Europe, nearly every work
has a copyright owner. Hence every snippet contributed by a European citizen
legally is not correctly contributed. This could be healed by using the CC0: It
also talks about the public domain, but it explicitly grants all rights to the
users without requiring any service in return.

Best regards Karsten

Re: LilyPond, LilyPond snippets and the GPL

[Urs Liska]

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
>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 a GPL licensed snippet
>which only
>modifies the apperance of a score. Such a function does not concern the
>music
>itself. And therefore, the copyleft effect is not applied of the music.
>
>Then it seems that you try to generalize your argumentation: Every
>piece of
>LilyPond code describing the music score does not not concern the
>music, but only
>the appearance. Hence the, the copyleft effect can not be applied to
>any results
>of the LilyPond compilation process (the pdfs, pngs, ...)
>
>Please tell me, whether I got your point or not. Again, it seems to
>seductive and
>I want to consider it a bit longer, before I will answer
>
>best regards karsten

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: LilyPond, LilyPond snippets and the GPL

[Karsten Reincke]

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 a GPL licensed snippet which 
only
modifies the apperance of a score. Such a function does not concern the music
itself. And therefore, the copyleft effect is not applied of the music.

Then it seems that you try to generalize your argumentation: Every piece of
LilyPond code describing the music score does not not concern the music, but 
only
the appearance. Hence the, the copyleft effect can not be applied to any results
of the LilyPond compilation process (the pdfs, pngs, ...)

Please tell me, whether I got your point or not. Again, it seems to seductive 
and
I want to consider it a bit longer, before I will answer

best regards karsten

Re: LilyPond, LilyPond snippets and the GPL

[Karsten Reincke]

On Wed, 2019-10-30 at 01:36 +0100, David Kastrup wrote:
> Karsten Reincke  writes:
> 
> > [...]
> > 
> > Hence, if I use a piece of software as library, snippet, or module,
> > then I am using the advantage that I do not have to program that code
> > by myself. I am saving costs and time. A very good indicator, that I am
> > saving resources by using the prework of another programer, is the call
> > of a function (or method or similar). Therefore, calling a function /
> > method delivered by a GPL licensed software indicates that I create a
> > derivative work and that the strong copyleft effect is triggered.
> 
> Which would imply that distributing your LilyPond input combined with
> OpenLilylib code would require licensing your LilyPond input under the
> GPL.
Yes, exactly. That's my point.
> 
> It doesn't cover the output of running your LilyPond code, namely the
> PDF.

I am afraid that this statement does judicially not hold:

LilyPond itself says that it works "[...] as a compiled system: [...] In some
ways, LilyPond is more similar to a programming language [...]". Hence the
viewpoint of Carl Sorensen seems to be valid: LilyPond is like the gcc. And even
in case of the gcc, the copyleft effect does not cover the outpout (the compiled
program).

But in case of a GPL licensed LilyPond snippet (sic!), the copyleft effetc is
triggered by the use of that snippet. And the GPLv3 is very clear: §4 and §5
require us also to distribute the code of the embedding / using work under the
terms of th GPL. And - under the title "Conveying Non-Source Forms" - §6 
requires
us also to distribute our non-source forms under the terms of the GPL.

Here, the analogy of gcc and Lilypond 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 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 their work.

with best reagards Karsten

-- 
  Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
60431 Frankfurt a.M.  \/http://www.fodina.de/kr/

Re: LilyPond, LilyPond snippets and the GPL

[Karsten Reincke]

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 included snippet or by
> > literally copying the snippet into the other code), then the copyleft
> > effect of the GPL is triggered.
> >
> [...]
> 
> 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 do agree that including/using/changing LSR
> snippets as part of your work means deriving from them.  That's why I
> would agree that using the GPL for the LSR snippets would not be
> desirable since it would introduce a licensing regime where it seems
> exaggerated.
> 
> I agree with this comment only to the extent that you are distributing the
> source code for your music.  If you only distribute the PDF and/or MIDI 
> output,
> the GPL does not apply, according to the FSF:
> 
> " In what cases is the output of a GPL program covered by the GPL too?
> (#WhatCaseIsOutputGPL)
> The output of a program is not, in general, covered by the copyright on the 
> code
> of the program. So the license of the code of the program does not apply to 
> the
> output, whether you pipe it into a file, make a screenshot, screencast, or
> video.

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 GPL
if I use (include or copy) a GPL licensed snippet. And if it is covered, then in
accordance to the GPL §6 (title: "Conveying Non-Source Forms") also the compiled
version is covered by the GPL. (BTW: even a picture is binary code which is
interpreted)

Nevertheless, I would be happy if the statement you quoted would be judically
approved! But as long as we do not have such a legal descision there is a great
risk that my scientific and artistical music work can freely be used due to the
fact that I used a GPL licensed snippet for ceating the music scores - a risk,
which I don't want to take.

But even if I agreed with your position, then we both still have to conlude, 
that
we can only distribute / hand over our LilyPond code under the terms of the GPL,
if our code used a GPL licensed snippet. And even this is a strong side effect.

with best regards Karsten

 


> Carl Sorensen
> 
> 1. https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
> 
> 
> 
-- 
  Karsten Reincke/\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
60431 Frankfurt a.M.  \/http://www.fodina.de/kr/