Re: Future of OpenLilyLib

[Graham King]

Thanks Jean and Federico.  I'll open a new thread on lyLuaTex, to avoid 
hijacking this one.

-- Graham

> On 23 Nov 2022, at 16:59, Federico Bruni  wrote:
> 
> In order to run lyluatex with recent versions of lilypond (2.23.x), you must 
> install the most recent version of lyluatex. In other words, you should 
> install Texlive standalone and not the texlive packaged by distros.
> 
> See this discussion:
> https://github.com/jperon/lyluatex/issues/287
> 
> 
> Il giorno mer 23 nov 2022 alle 17:55:34 +0100, Jean Abou Samra 
>  ha scritto:
>> Le 23/11/2022 à 16:31, Graham King a écrit :
>>> I've tried to get Scholarly working in the past, but failed.  I'm currently 
>>> failing to get lyluatex working.
>>> There are some really promising tools in OpenLilyLib, but they seem to 
>>> require someone with Urs' level of focus and intellect to use them.  This 
>>> thread is raising my hopes once more.
>> I'd suggest you open a new thread about lyLuaTeX, with details
>> of your problems getting it to run.
>> (Note that lyLuaTeX isn't part of openLilyLib.)
>> Best,
>> Jean
> 
> 

Re: Future of OpenLilyLib

[Federico Bruni]

In order to run lyluatex with recent versions of lilypond (2.23.x), you 
must install the most recent version of lyluatex. In other words, you 
should install Texlive standalone and not the texlive packaged by 
distros.


See this discussion:
https://github.com/jperon/lyluatex/issues/287


Il giorno mer 23 nov 2022 alle 17:55:34 +0100, Jean Abou Samra 
 ha scritto:

Le 23/11/2022 à 16:31, Graham King a écrit :
I've tried to get Scholarly working in the past, but failed.  I'm 
currently failing to get lyluatex working.


There are some really promising tools in OpenLilyLib, but they seem 
to require someone with Urs' level of focus and intellect to use 
them.  This thread is raising my hopes once more.





I'd suggest you open a new thread about lyLuaTeX, with details
of your problems getting it to run.

(Note that lyLuaTeX isn't part of openLilyLib.)

Best,
Jean

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 23/11/2022 à 16:31, Graham King a écrit :

I've tried to get Scholarly working in the past, but failed.  I'm currently 
failing to get lyluatex working.

There are some really promising tools in OpenLilyLib, but they seem to require 
someone with Urs' level of focus and intellect to use them.  This thread is 
raising my hopes once more.





I'd suggest you open a new thread about lyLuaTeX, with details
of your problems getting it to run.

(Note that lyLuaTeX isn't part of openLilyLib.)

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Graham King]

> On 22 Nov 2022, at 09:31, Mark Knoop  wrote:
> 
> Thanks to all for your responses. There seems to be a general agreement
> about the desired direction but I'd still like to hear who is actually
> using this code at the moment. Is it just Kieren and me?

I've tried to get Scholarly working in the past, but failed.  I'm currently 
failing to get lyluatex working.

There are some really promising tools in OpenLilyLib, but they seem to require 
someone with Urs' level of focus and intellect to use them.  This thread is 
raising my hopes once more.

Re: Future of OpenLilyLib

[Valentin Petzel]

Hello Mark,

> Yes, I think we all agree on that. At the moment there isn't, but even
> if and when that might be implemented, I can still see a role for a
> repository such as OpenLilyLib to collect and host those modules. Is the
> future really copying blocks of code from websites or email attachments
> and saving them to randomly organized local files?

If at some point Lilypond would have the capabilities to use modules that 
might be packaged and distributed I think this part of OLL could turn into 
some sort of centralized archive like CTAN, or into a centralized index, 
refering to the packages themselfes. I do not think that OLL as a giant git 
repository of packages makes a lot of sense in the terms of maintainence 
though.

Cheers,
Valentin

signature.asc
Description: This is a digitally signed message part.

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 22/11/2022 à 08:50, Henning Hraban Ramm a écrit :

... module code ...

\endModule % or whatever name

... example ...


where \endModule would act as a "trap" interrupting the parsing,
but only if the file is included. If the file is compiled as
main, it would continue parsing, and after \endModule you could
put some examples and tests for the snippet / module functionality.


That is how module documentation in TeX works (as you are probably 
aware). I don’t think many users would look into that, esp. since 
LilyPond’s documentation is more concise and centralized.




I wasn't even aware that TeX used a similar principle :-)

However, I wouldn't see a lot of value to it for documentation.
Maybe it would have some value for usage examples.

Best,
Jean




OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Andrew Bernard]

Mark, I use my stem slash code a lot.

I don't think you should delete things willy nilly. There may be users 
who use stuff in OLL that do not respond in the list etc etc.



Andrew

Re: Future of OpenLilyLib

[Mark Knoop]

Thanks to all for your responses. There seems to be a general agreement
about the desired direction but I'd still like to hear who is actually
using this code at the moment. Is it just Kieren and me?

### Usage

Several people mentioned difficulties using OLL.

- how to install?
- what does it do?
- combersome, unwieldy, unmaintained

This is the prime reason I decided to propose this reorganization. I
have started work to improve documentation and plan to work through most
of it incrementally. See below re maintenance.

### Shouldn't this all be in LilyPond or LSR?

Possibly, but it isn't at the moment.

Certainly there are features in OLL which could/should be moved into
LilyPond, and some which already have been. I believe maintaining _and_
**using** that code in the meantime is the best way to a) work out which
features should be prioritized, and b) come to some agreement about
interfaces and syntax for those features.

_Shouldn't this be done in code review as part of adding to LilyPond
directly?_

Possibly, but users are not always able to be focussed on this at the
time of development. If I'm engraving a score which is due next week and
need to do X then I'm most likely to write/adapt/hack together something
which works "well-enough" to get the score out next week. I almost
certainly won't have time to polish it to the point of submitting, and
following up, a merge request to LilyPond.

But I might be able to include it as an OLL module which somebody else
might see and either improve, use to solve a different problem, expand,
etc.

LSR has it's own set of problems, some of which have already come up in
this thread.

### There should be a better/easier way to include modular code in LilyPond

Yes, I think we all agree on that. At the moment there isn't, but even
if and when that might be implemented, I can still see a role for a
repository such as OpenLilyLib to collect and host those modules. Is the
future really copying blocks of code from websites or email attachments
and saving them to randomly organized local files?

In the meantime, OLL (mostly) works and can be improved with better
documentation.

### Maintenance

At the moment I use several parts of the OLL (mostly edition-engraver,
scholarly and bits from oll-misc) and so will keep maintaining them. I'm
also happy to help maintain any other parts which are used by others.
I'd like to identify what _isn't_ used so it can be marked as
unmaintained/deprecated/scavenged for parts.

Regards,

Mark
--
Mark Knoop

Re: Future of OpenLilyLib

[Henning Hraban Ramm]

Am 21.11.22 um 23:28 schrieb Jean Abou Samra:


One would add a new keyword in the parser akin to \include
(\import? \load?). 


How about \require?


... module code ...

\endModule % or whatever name

... example ...


where \endModule would act as a "trap" interrupting the parsing,
but only if the file is included. If the file is compiled as
main, it would continue parsing, and after \endModule you could
put some examples and tests for the snippet / module functionality.


That is how module documentation in TeX works (as you are probably 
aware). I don’t think many users would look into that, esp. since 
LilyPond’s documentation is more concise and centralized.


Otherwise I’ll leave this discussion to you, since I never need the more 
sophisticated features of LilyPond for my folk songs and odd other piece.


Thank you for your work!

Hraban

Re: Future of OpenLilyLib

[Karlin High]

On Mon, Nov 21, 2022, 6:11 PM Andrew Bernard 
wrote:

> it costs money for me to run the server
>

What storage and RAM is needed?

I might be able to host it for you.
--
Karlin High
Missouri, USA

>

Re: Future of OpenLilyLib

[Andrew Bernard]

I may as well shutdown openlilylib.space then. There are only 15 users, 
and it costs money for me to run the server, and there is zero traffic 
on Discourse.


Andrew


On 22/11/2022 9:22 am, Jean Abou Samra wrote:

Le 21/11/2022 à 23:19, Andrew Bernard a écrit :

Hello All,

Why don't we keep the discussion about OLL on the OLL Discourse forum 
I created and run? That's the whole point of it, and to avoid 
cluttering the Lilypond User list.



I think Mark's goal was to reach LilyPond users who are only casual 
users of OLL.


I would prefer not to move the thread now that it has started here, it 
always makes things confusing...


Jean

Re: Future of OpenLilyLib

[Valentin Petzel]

Hi Jean,

> I would change the tense:
> 
> [Independently of OLL,] non core developers *are* able to implement
> new features with Scheme code that *can* potentially be included in
> base LilyPond if proven reasonable.
> 
> Don't you agree?

I do agree that users are able to implement feature with Scheme code, but 
handling of 
such code is usually a matter of copying snippets, eventually outsourcing them 
into a file. 
With a module interface a user could implement his feature as module and 
publish this 
module. Then it would be very easy for other users to use this feature in own 
project, and 
we might see: Some modules are experiencing so frequent use that they might be 
well 
suited for actually being part of core Lilypond.

I did not intent to say that non core developers have absolutely no way of 
testing out 
functions, but that it would be much easier to have an ecosystem where such 
functions can 
be tested.

> It is true that not every feature fits. However, in practice, I
> have encountered few features that fit neither in an LSR
> snippet, nor in LilyPond's core, nor as some kind of mix between
> the two where the core receives some generic tools useful for
> other purposes as well, while the LSR snippet makes use of these
> tools for a very specific purpose.

But this might just be a result of the missing infrastructure :). If the 
extension methods we 
offer are simply snippets then it is clear that we will mostly get snippets and 
be bound to 
snippets. On the other hand a module could be thought as a snippet+.

> - a module should only be loaded once, even if imported twice in
>   different locations, 
> - a module could (optionally?) have its own namespace (Guile module
>object) with private definitions, and only export the definitions
>it needs.

I think Include files provide something similar to loading modules, but in the 
most 
primitive form possible, that is simply text insertion. I do agree on your 
points. @1: A 
Lilypond file could simply start with a declaration of required modules, which 
are then 
sourced at the start. @2: Definitely sensible, unnamespaced modules are prone 
to 
unwanted behaviour.

I’d add that a module could not only contain ly files but also scm files, and 
they could be 
loaded similar to base Lilypond’s scm/* and ly/* files, allowing for control 
bigger than a 
single session. Then we could simply use define-public for public definitions.

Cheers,
Valentin


signature.asc
Description: This is a digitally signed message part.

Re: Future of OpenLilyLib

[Kieren MacMillan]

Hi Jean,

> The first step to adding non-trivial things that need discussion
> is opening an issue. Do you feel like doing that?

https://gitlab.com/lilypond/lilypond/-/issues/6475
Look at me, being all “Do first” ’n’ stuff…  ;)

We taking the discussion over there?
K

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 23:02, Kieren MacMillan a écrit :

Then they should definitely be added: those were things Urs and I discussed (a 
fair bit off-list) as principle obstacles to the integration of “external” code 
(mostly equivalent to OLL at the time) into the ’Pond ecosystem.



The first step to adding non-trivial things that need discussion
is opening an issue. Do you feel like doing that?



I feel like the moment we have a real module system, two things will happen 
fairly quickly:

1. Many \include files (which are, to be fair, pretty cumbersome, especially in 
any reasonably complex file set) will become modules… and modular stylesheets 
will suddenly become exponentially less of a headache to implement.

2. The uptake (and thus maintenance) of really-helpful-but-currently-obscure 
code (e.g., the EE) will ramp up.

What’s required to add those two things you’re talking about?




One would add a new keyword in the parser akin to \include
(\import? \load?). Not importing a module more than once
should be almost trivial (just remember which modules have
already been imported). The namespacing thing is less
trivial, but you can probably get along by creating a
new parser, and use-module! its namespace into the main
file's namespace, or its public interface if you want
to get public names only. You'd also need some sort of
syntax like

\public var = val

e.g.

\public func =
#(define-music-function ...)

as an equivalent of

#(define-public var val)

Again, some hacking time but nothing hard if you know a bit
about the parser, really. (But the entry barrier to the parser
*is* high.)

One additional idea of mine in the category of "I don't know if
it's a good or a bad idea" is structuring LSR snippets / modules
as


... module code ...

\endModule % or whatever name

... example ...


where \endModule would act as a "trap" interrupting the parsing,
but only if the file is included. If the file is compiled as
main, it would continue parsing, and after \endModule you could
put some examples and tests for the snippet / module functionality.


Jean





OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 23:19, Andrew Bernard a écrit :

Hello All,

Why don't we keep the discussion about OLL on the OLL Discourse forum 
I created and run? That's the whole point of it, and to avoid 
cluttering the Lilypond User list.



I think Mark's goal was to reach LilyPond users who are only casual 
users of OLL.


I would prefer not to move the thread now that it has started here, it 
always makes things confusing...


Jean




OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Andrew Bernard]

Hello All,

Why don't we keep the discussion about OLL on the OLL Discourse forum I 
created and run? That's the whole point of it, and to avoid cluttering 
the Lilypond User list.


It's free to sign and and join. Otherwise I am running the website for 
nothing.


https://openlilylib.space

All are welcome.


Andrew


On 22/11/2022 4:09 am, Mark Knoop wrote:

With the imminent release of LilyPond 2.24, I thought it would be good
to (once again) raise the topic of OpenLilyLib.

Re: Future of OpenLilyLib

[Valentin Petzel]

Hello Karlin,

I’m sure no one who engages on the list will feel burdened by your questions, 
in the worst case they might just not engage with it and ignore it, that is as 
long as you talk nicely and do not demand for things (as the people here are 
doing this because they want to in their spare time this can be one hell of a 
turn-off. We do not *serve* the community, we *are* the community).

Generally I think we feel glad about people of all levels joining and being in 
the community, and I do not think anyone here has problems with not all 
questions being on the most obscure Lilypond level. Maybe unless they are 
questions that can easily be answered by reading a small bit of documentation.

Cheers,
Valentin

Am Montag, 21. November 2022, 20:43:29 CET schrieb Karlin High:
> On 11/21/2022 11:09 AM, Mark Knoop wrote:
> > It would be good to get a feel from users how much this resource isused
> 
> I have heard lots of good things about OpenLilyLib.
> 
> But I remain somewhat unclear as to what it offers and how it would be
> used in my usages for SATB/TTBB shape-note hymns and light choral works.
> 
> My first experience with OLL was downloading the zip folder with it,
> just to start poking it with sticks and see what it does. I extracted
> the zip, tried to use with LilyPond on Windows, and got lots of file
> path errors about not being able to find things or do anything.
> 
> It seemed like I could not find "a way in" to making use of it.
> 
> Asking questions on the lists and such left me feel like I was burdening
> the developers for it, needing "explain it like I am 5 years old"
> efforts when they could best serve the community by exploring and
> advancing the limits of LilyPond's capabilities with others who were
> already up to speed in the relevant areas.
> 
> I still have a dream project of using LilyPond to produce a new edition
> of a hymnal containing 467 songs. The Edition Engraver seems like a
> must-have for that.



signature.asc
Description: This is a digitally signed message part.

Re: Future of OpenLilyLib

[Kieren MacMillan]

Hi all,

> I don't think we're very far from that. Include files already work
> as kinds of modules. I only see two potential differences between modules
> and include files:
> 
> - a module should only be loaded once, even if imported twice in
>   different locations,
> 
> - a module could (optionally?) have its own namespace (Guile module
>   object) with private definitions, and only export the definitions
>   it needs.
> 
> None of these two would be very complicated to add to LilyPond.

Then they should definitely be added: those were things Urs and I discussed (a 
fair bit off-list) as principle obstacles to the integration of “external” code 
(mostly equivalent to OLL at the time) into the ’Pond ecosystem.

I feel like the moment we have a real module system, two things will happen 
fairly quickly:

1. Many \include files (which are, to be fair, pretty cumbersome, especially in 
any reasonably complex file set) will become modules… and modular stylesheets 
will suddenly become exponentially less of a headache to implement.

2. The uptake (and thus maintenance) of really-helpful-but-currently-obscure 
code (e.g., the EE) will ramp up.

What’s required to add those two things you’re talking about?

Thanks,
Kieren.

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 22:38, Valentin Petzel a écrit :

In my opinion it is not bad to allow for modular extension of Lilypond,
especially for things that do not fit the core of the program. You need to keep
in mind that this would be a strong possibility of enhancing Lilypond without
cluttering it’s core.




It is true that not every feature fits. However, in practice, I
have encountered few features that fit neither in an LSR
snippet, nor in LilyPond's core, nor as some kind of mix between
the two where the core receives some generic tools useful for
other purposes as well, while the LSR snippet makes use of these
tools for a very specific purpose.




And if non core developer were able to implement new
features in modules that could potentially be included into base Lilypond if
proven reasonable it might become easier to contribute to Lilypond.



I would change the tense:

[Independently of OLL,] non core developers *are* able to implement
new features with Scheme code that *can* potentially be included in
base LilyPond if proven reasonable.

Don't you agree?




This is a big part of the reason why languages like python are so popular. But 
the OLL
implementation is just unwieldy and hard to maintain.

Currently if I were to develop an OLL module for Lilypond I would face two
problems: Any potential user first must be motivated to install OLL, which is a
cluttered and unintuitive process. And then my package would constantly depend
on OLL being maintained.

Thus I think what would be more sustainable is if we had an module interface
that is well maintained (eventually to the point of maintaining against
multiple Lilypond versions), and individual packages using this interface.




I don't think we're very far from that. Include files already work
as kinds of modules. I only see two potential differences between modules
and include files:

- a module should only be loaded once, even if imported twice in
  different locations,

- a module could (optionally?) have its own namespace (Guile module
  object) with private definitions, and only export the definitions
  it needs.

None of these two would be very complicated to add to LilyPond.



Even more promising would be if Lilypond itself were to allow for modules,
which would eliminating the need for oll-core at all (also this would even
allow for more crazy stuff, like packaging specifying code that is executed at
different stages).

But as it stands I’m not sure if OLL can be maintained. We’ve seen how quickly
OLL falls if a handful of people fall away, and what we face here is basically
an uphill battle trying to keep that thing maintained (not even talking about
further developing it).



Yes.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Valentin Petzel]

Hello Jean, Hello All,

I think the main problem with OLL is that it tries to provide some sort of 
equivalent of the STL for Lilypond. Thus is packs a lot of functionality in 
one big chunk that is hard to organize and hard to maintain, feeling like a 
big, alien thing.

In my opinion it is not bad to allow for modular extension of Lilypond, 
especially for things that do not fit the core of the program. You need to keep 
in mind that this would be a strong possibility of enhancing Lilypond without 
cluttering it’s core. And if non core developer were able to implement new 
features in modules that could potentially be included into base Lilypond if 
proven reasonable it might become easier to contribute to Lilypond. This is a 
big part of the reason why languages like python are so popular. But the OLL 
implementation is just unwieldy and hard to maintain.

Currently if I were to develop an OLL module for Lilypond I would face two 
problems: Any potential user first must be motivated to install OLL, which is a 
cluttered and unintuitive process. And then my package would constantly depend 
on OLL being maintained.

Thus I think what would be more sustainable is if we had an module interface 
that is well maintained (eventually to the point of maintaining against 
multiple Lilypond versions), and individual packages using this interface. 
Even more promising would be if Lilypond itself were to allow for modules, 
which would eliminating the need for oll-core at all (also this would even 
allow for more crazy stuff, like packaging specifying code that is executed at 
different stages).

But as it stands I’m not sure if OLL can be maintained. We’ve seen how quickly 
OLL falls if a handful of people fall away, and what we face here is basically 
an uphill battle trying to keep that thing maintained (not even talking about 
further developing it).

Cheers,
Valentin

Am Montag, 21. November 2022, 18:54:50 CET schrieb Jean Abou Samra:
> Maybe what I'm going to say will sadden some, but personally,
> I never quite understood what the advantage of developing
> openLilyLib as a library external to LilyPond, as opposed to
> contributing features to LilyPond itself, was supposed to be.
> 
> I was going to add my lyrics code to LSR, actually. It's just
> more convenient for users to grab, and it's not like this is
> a very large piece of code that really needs version control
> (although version control in LSR *would* be nice).
> 
> To be honest, although I wasn't there at the time, it is my
> impression that this split was partly motivated by some personal
> conflicts that reduced Urs' willingness to submit patches to
> LilyPond, which is not relevant for us today.
> 
> Some of the OLL stuff has been made part of LilyPond over the
> years, for example Merge_mmrest_numbers_engraver and \vshape.
> There is also \staffHighlight, which serves a purpose that
> overlaps a bit with the purpose of AnaLYsis. Long-term, I would
> like to see edition-engraver go that route  as well (with a
> better, iterator-based implementation).
> 
> So it's a shrug from me: I thank you for your effort in making
> the code 2.23.81-compatible, and I'm fine with any reorganizations
> you want to make, but I will always feel that this code is not
> really at home.
> 
> Best,
> Jean
> 



signature.asc
Description: This is a digitally signed message part.

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 21:55, Kieren MacMillan a écrit :

cf. our past discussions (some on -devel, some private) about my attempts to 
add code, where it should go, etc.
=)




Yes, I remember that :-)




2. Obviously I use oll-core, since that is foundational to the EE.



Note: oll-core is a somewhat haphazard bag of stuff, some of
which is useful, some of which has already been integrated
to LilyPond (like ly:version?, added by Urs himself), and
some of which ... cough, doesn't make a lot of sense to me
(options, property sets and presets). There are things to
“clean out” there too.


Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Kieren MacMillan]

Hi all,

> Maybe what I'm going to say will sadden some, but personally,
> I never quite understood what the advantage of developing
> openLilyLib as a library external to LilyPond, as opposed to
> contributing features to LilyPond itself, was supposed to be.

cf. our past discussions (some on -devel, some private) about my attempts to 
add code, where it should go, etc.
=)

> To be honest, although I wasn't there at the time, it is my
> impression that this split was partly motivated by some personal
> conflicts that reduced Urs' willingness to submit patches to
> LilyPond, which is not relevant for us today.

The patch-discussion and -submission process has definitely been an impediment 
to many developers in the past.

> I would like to see edition-engraver go that route  as well
> (with a better, iterator-based implementation).

You know you’re preaching to the choir here… ;)

[Mark]
> It would be good to get a feel from users how much this resource is
> used, and which bits are most important to maintain.

1. I use the edition-engraver on everything more complicated than a MWE or 
“music theory exercise” [and sometimes I even use it for those! LOL].

2. Obviously I use oll-core, since that is foundational to the EE.

3. I use stylesheets and notation/font selection and breaks for everything BUT 
not the OLL frameworks which either never really got built out (stylesheets) or 
I've just never had enough breathing room to study (fonts and breaks); if those 
WERE built out, well-documented, and clearly optimized, I would consider those 
to be essential "bits".

Lots of thoughts on OLL and modular code integration etc., but will wait for 
concrete questions to answer.

Best,
Kieren.

Re: Future of OpenLilyLib

[Karlin High]

On 11/21/2022 11:09 AM, Mark Knoop wrote:

It would be good to get a feel from users how much this resource isused


I have heard lots of good things about OpenLilyLib.

But I remain somewhat unclear as to what it offers and how it would be 
used in my usages for SATB/TTBB shape-note hymns and light choral works.


My first experience with OLL was downloading the zip folder with it, 
just to start poking it with sticks and see what it does. I extracted 
the zip, tried to use with LilyPond on Windows, and got lots of file 
path errors about not being able to find things or do anything.


It seemed like I could not find "a way in" to making use of it.

Asking questions on the lists and such left me feel like I was burdening 
the developers for it, needing "explain it like I am 5 years old" 
efforts when they could best serve the community by exploring and 
advancing the limits of LilyPond's capabilities with others who were 
already up to speed in the relevant areas.


I still have a dream project of using LilyPond to produce a new edition 
of a hymnal containing 467 songs. The Edition Engraver seems like a 
must-have for that.

--
Karlin High
Missouri, USA

Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 20:02, Mark Knoop a écrit :

Thanks Jean for your thoughts, which are not so far from my own. A few comments:


Maybe what I'm going to say will sadden some, but personally,
I never quite understood what the advantage of developing
openLilyLib as a library external to LilyPond, as opposed to
contributing features to LilyPond itself, was supposed to be.

Having just looked through quite a lot of the code in openLilyLib, I
think there will always be code there that is not suitable for inclusion
in LilyPond, for many reasons (highly specialized use cases, code which
works just-well-enough™, etc...).

It's no criticism of the core LilyPond developers to acknowledge that
not every desired feature will be accepted, and even if so, there is
still a significantly higher hurdle to contributing to LilyPond than to
OpenLilyLib (and rightly so).




That is true. On the other hand, the hurdle for contributing to
LilyPond is already significantly lower than it used to be a few
years ago (we migrated to GitLab, large parts of the contributor's
guide were rewritten, ...).

It's all a tradeoff. The less requirements you put on quality,
the more maintenance trouble you get (and there is an inherent
maintenance trouble related to the fact that OLL is not usually
constrained to a single version of LilyPond, although you are
proposing to make it so in the short period until 2.24).




Almost all programming languages have non-core features which are
developed in a modular way - this fact would seem to support the case
for something similar for LilyPond.




A Python library for scientific computing has absolutely nothing
to do with a Python library for creating web pages, so the developers
have no reason to tie themselves together. In contrast, music
typesetting is an intricate task with dependencies everywhere.




I see two advantages over LSR, the primary one being version control
(which includes being able to search it locally with git grep); the
other being the potential to include code which is larger in scale and
interacts sensibly. (Once you start importing several LSR snippets into
one project, the potential for adverse side-effects becomes > 0.)




I dream of a remake of LSR that would fix its problems (lack of
history / version control, LSR editors don't know who submitted
a snippet and are not notified about it, things like that).

On the other hand, when I see a large snippet of useful code,
my first reaction is normally to wonder how some of it could
be turned into a patch.




To be honest, although I wasn't there at the time, it is my
impression that this split was partly motivated by some personal
conflicts that reduced Urs' willingness to submit patches to
LilyPond, which is not relevant for us today.

Indeed, this isn't relevant, except to acknowledge that for whatever
reason, there is at the moment a bunch of useful stuff which is a) not
yet in LilyPond, and b) bit-rotting until it is dealt with.



Yes.



Some of the OLL stuff has been made part of LilyPond over the
years, for example Merge_mmrest_numbers_engraver and \vshape.
There is also \staffHighlight, which serves a purpose that
overlaps a bit with the purpose of AnaLYsis. Long-term, I would
like to see edition-engraver go that route as well (with a
better, iterator-based implementation).

Absolutely I'd also love to see this. (Another task which I didn't put
in my first email is to clean out code that *has* made it into LilyPond.)

Whilst I was able to fix-up the edition-engraver for Guile 2, I am
certainly not up to rewriting it "better" - and I don't expect anybody
else to do that either.




Iterators are currently not Scheme-accessible anyway. It would
have to be done on the C++ level.



My hope is that by making OLL a little more usable and less chaotic, it
might be possible to identify firstly which features are being most
used, and secondly use that information to prioritize moving those into
LilyPond in the best way possible.



Good.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Future of OpenLilyLib

[Mark Knoop]

Thanks Jean for your thoughts, which are not so far from my own. A few comments:

> Maybe what I'm going to say will sadden some, but personally,
> I never quite understood what the advantage of developing
> openLilyLib as a library external to LilyPond, as opposed to
> contributing features to LilyPond itself, was supposed to be.

Having just looked through quite a lot of the code in openLilyLib, I
think there will always be code there that is not suitable for inclusion
in LilyPond, for many reasons (highly specialized use cases, code which
works just-well-enough™, etc...).

It's no criticism of the core LilyPond developers to acknowledge that
not every desired feature will be accepted, and even if so, there is
still a significantly higher hurdle to contributing to LilyPond than to
OpenLilyLib (and rightly so).

Almost all programming languages have non-core features which are
developed in a modular way - this fact would seem to support the case
for something similar for LilyPond.

> I was going to add my lyrics code to LSR, actually. It's just
> more convenient for users to grab, and it's not like this is
> a very large piece of code that really needs version control
> (although version control in LSR *would* be nice).

I see two advantages over LSR, the primary one being version control
(which includes being able to search it locally with git grep); the
other being the potential to include code which is larger in scale and
interacts sensibly. (Once you start importing several LSR snippets into
one project, the potential for adverse side-effects becomes > 0.)

> To be honest, although I wasn't there at the time, it is my
> impression that this split was partly motivated by some personal
> conflicts that reduced Urs' willingness to submit patches to
> LilyPond, which is not relevant for us today.

Indeed, this isn't relevant, except to acknowledge that for whatever
reason, there is at the moment a bunch of useful stuff which is a) not
yet in LilyPond, and b) bit-rotting until it is dealt with.

> Some of the OLL stuff has been made part of LilyPond over the
> years, for example Merge_mmrest_numbers_engraver and \vshape.
> There is also \staffHighlight, which serves a purpose that
> overlaps a bit with the purpose of AnaLYsis. Long-term, I would
> like to see edition-engraver go that route as well (with a
> better, iterator-based implementation).

Absolutely I'd also love to see this. (Another task which I didn't put
in my first email is to clean out code that *has* made it into LilyPond.)

Whilst I was able to fix-up the edition-engraver for Guile 2, I am
certainly not up to rewriting it "better" - and I don't expect anybody
else to do that either.

My hope is that by making OLL a little more usable and less chaotic, it
might be possible to identify firstly which features are being most
used, and secondly use that information to prioritize moving those into
LilyPond in the best way possible.

--
Mark Knoop

Re: Future of OpenLilyLib

[Jean Abou Samra]

Maybe what I'm going to say will sadden some, but personally,
I never quite understood what the advantage of developing
openLilyLib as a library external to LilyPond, as opposed to
contributing features to LilyPond itself, was supposed to be.

I was going to add my lyrics code to LSR, actually. It's just
more convenient for users to grab, and it's not like this is
a very large piece of code that really needs version control
(although version control in LSR *would* be nice).

To be honest, although I wasn't there at the time, it is my
impression that this split was partly motivated by some personal
conflicts that reduced Urs' willingness to submit patches to
LilyPond, which is not relevant for us today.

Some of the OLL stuff has been made part of LilyPond over the
years, for example Merge_mmrest_numbers_engraver and \vshape.
There is also \staffHighlight, which serves a purpose that
overlaps a bit with the purpose of AnaLYsis. Long-term, I would
like to see edition-engraver go that route  as well (with a
better, iterator-based implementation).

So it's a shrug from me: I thank you for your effort in making
the code 2.23.81-compatible, and I'm fine with any reorganizations
you want to make, but I will always feel that this code is not
really at home.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Future of OpenLilyLib

[Mark Knoop]

With the imminent release of LilyPond 2.24, I thought it would be good
to (once again) raise the topic of OpenLilyLib. There has been some
recent movement on this (thanks to Jean and Andrew) to get the code
mostly working with recent LilyPond versions and Guile 2.

I have also just pushed a bunch of commits to resolve (as far as I can
tell) the remaining errors and warnings, at least in the usage examples
included in the repositories. (See pull requests below.)

I believe there is still an important role for OpenLilyLib - the
edition-engraver in particular is an integral part of my own usage of
LilyPond - and it would seem to me to be a much better vehicle than the
LSR for anything more complex than small code examples. The recent
discussions on the lilypond-user list regarding the \alignTo function
and Jean's lyric spacing code would indicate that these would be prime
contenders for inclusion.

It would be good to get a feel from users how much this resource is
used, and which bits are most important to maintain. Following are my
impressions of the current problems with openlilylib and a proposal to
(begin to) address them.

## Problems

- unclear documentation
- too many repositories, duplicated and out-of-date content
- un-maintained code

## Proposal

1. Centralize into main 'entry-point' repository using git submodules
   containing newest, working code. This will contain clear instructions
   as to how to install `openlilylib`.

2. Update, fix or remove non-working code from this core set

3. Only target current stable LilyPond from 2.24.0 onwards (update to
   2.23.81 for now)

### Core repositories

I propose to include these as git submodules.

- `oll-core` :: core functions
- `edition-engraver`, and these packages that depend on it
  - `breaks`, `page-layout`, `partial-compilation`
- `analysis` :: graphical highlighting of musical analysis
- `ji` :: just intonation
- `notation-fonts` :: manage font selection
- `oll-misc` :: various helper functions
- `stylesheets` :: hierarchical stylesheets
- `scholarly` :: toolbox for annotating scores

### Older repositories - propose to deprecate

AFAICT these are deprecated and/or unused. I propose they are
"officially" dropped unless there are any regular users who are able to
maintain them.

- `openlilylib` :: very deprecated - turn this into the 'entry-point' repository
- `LO-ly` :: moved to https://github.com/OOoLilyPond
- `bezier` :: slur-attachment function and improved `\shape`
- `contemporary` :: nothing here
- `gridly` :: music editing in independent segments
- `grob-tools` :: moved to `oll-core`
- `lalily-templates` :: template package
- `lilypond-export` :: export to other formats
- `snippets` :: mostly moved to `oll-misc`
- `templates` :: templates and predefined instruments

## Pull requests

- https://github.com/openlilylib/oll-misc/pull/10
- https://github.com/openlilylib/scholarly/pull/73
- https://github.com/openlilylib/analysis/pull/17
--
Mark Knoop

Re: Once for all and one last time (was Future of openLilyLib)

[Henning Hraban Ramm]

> Am 10.10.2020 um 17:49 schrieb Andrew Bernard :
> 
> There's a term for it. Necroposting! Seriously!

I’m proud of my necromancer badge on stackexchange ;D

HR

Re: Once for all and one last time (was Future of openLilyLib)

[Andrew Bernard]

There's a term for it. Necroposting! Seriously!

Andrew

On Sun, 11 Oct 2020 at 02:24, David Kastrup  wrote:

> Two weeks?  I've replied on occasion to threads that were 10 years old,
> basically because threads tends to be archived and turn up on keyword
> searches.

Re: Once for all and one last time (was Future of openLilyLib)

[David Kastrup]

Simon Albrecht  writes:

>> On 10.10.20 14:11, Simon Albrecht wrote:
>>> Dear Karsten and list,
>>>
>>> On 22.09.20 22:40, Karsten Reincke wrote:
 5) I've learned, that all(?) of you consider this an untenable if
 not silly position and that the PDFs and midi-files compiled by
 Lilypond are never affected by the strong copyleft effect of the
 GPL. That's good to hear. But I don't understand, why - under this
 circumstances - it should be garbage to add a respective clarifying
 statement (the 'include clause' or however you want to name it), if
 it is at least partially conceivable that such a position will be
 taken and if all of you do not want to use / establish its
 consequences. But that's my problem. 
>>>
>>>
>>> I would like to join in asking this question, namely what’s the
>>> reason not to add such an ‘include clause’? (Am I correct in
>>> gathering that LGPL basically means GPL + such an include clause?)
>
> There’s no such thing as retracting an e-mail, but I would like to do it.
>
> Sorry for failing to realise how old the thread was before replying.

Two weeks?  I've replied on occasion to threads that were 10 years old,
basically because threads tends to be archived and turn up on keyword
searches.  So sometimes I feel it makes sense to add crucial information
to them, even if the likelihood that the original participants care is
pretty much zero.

Admittedly, it happens more to discussions concerning vintage digital
cameras, but there have been two or three occasions where I even did it
with LilyPond.  Typically somewhat facetiously when some long-requested
feature or bug had finally been addressed, probably in the wake of
structural changes making it possible in the first place.

-- 
David Kastrup

Re: Once for all and one last time (was Future of openLilyLib)

[Simon Albrecht]

There’s no such thing as retracting an e-mail, but I would like to do it.

Sorry for failing to realise how old the thread was before replying.

Best, Simon

On 10.10.20 14:11, Simon Albrecht wrote:

Dear Karsten and list,

On 22.09.20 22:40, Karsten Reincke wrote:
5) I've learned, that all(?) of you consider this an untenable if not 
silly position and that the PDFs and midi-files compiled by Lilypond 
are never affected by the strong copyleft effect of the GPL. That's 
good to hear. But I don't understand, why - under this circumstances 
- it should be garbage to add a respective clarifying statement (the 
'include clause' or however you want to name it), if it is at least 
partially conceivable that such a position will be taken and if all 
of you do not want to use / establish its consequences. But that's my 
problem. 



I would like to join in asking this question, namely what’s the reason 
not to add such an ‘include clause’? (Am I correct in gathering that 
LGPL basically means GPL + such an include clause?)


Best,
Simon

Re: Once for all and one last time (was Future of openLilyLib)

[David Kastrup]

Simon Albrecht  writes:

> Dear Karsten and list,
>
> On 22.09.20 22:40, Karsten Reincke wrote:
>> 5) I've learned, that all(?) of you consider this an untenable if
>> not silly position and that the PDFs and midi-files compiled by
>> Lilypond are never affected by the strong copyleft effect of the
>> GPL. That's good to hear. But I don't understand, why - under this
>> circumstances - it should be garbage to add a respective clarifying
>> statement (the 'include clause' or however you want to name it), if
>> it is at least partially conceivable that such a position will be
>> taken and if all of you do not want to use / establish its
>> consequences. But that's my problem. 
>
>
> I would like to join in asking this question, namely what’s the reason
> not to add such an ‘include clause’? (Am I correct in gathering that 
> LGPL basically means GPL + such an include clause?)

No, you are not correct.  The LGPL has more lenient conditions.  It also
has a clause that allows it to be replaced by the GPL, and when
combining a GPLed work with an LGPLed work to form a common whole,
invoking that clause is the only way in which you can arrive at a
redistributable whole.

The main problem of adding _anything_ to a license of the GPL/LGPL
flavor is that the result is incompatible to software licensed under
GPL/LGPL without such an addition, defeating the significant goal of
interoperability and reusability of the GNU code base.

-- 
David Kastrup

Re: Once for all and one last time (was Future of openLilyLib)

[Simon Albrecht]

Dear Karsten and list,

On 22.09.20 22:40, Karsten Reincke wrote:
5) I've learned, that all(?) of you consider this an untenable if not 
silly position and that the PDFs and midi-files compiled by Lilypond 
are never affected by the strong copyleft effect of the GPL. That's 
good to hear. But I don't understand, why - under this circumstances - 
it should be garbage to add a respective clarifying statement (the 
'include clause' or however you want to name it), if it is at least 
partially conceivable that such a position will be taken and if all of 
you do not want to use / establish its consequences. But that's my 
problem. 



I would like to join in asking this question, namely what’s the reason 
not to add such an ‘include clause’? (Am I correct in gathering that 
LGPL basically means GPL + such an include clause?)


Best,
Simon

Re: Future of openLilyLib

[Jean Abou Samra]

Le 07/10/2020 à 16:30, Federico Bruni a écrit :
Il giorno mer 7 ott 2020 alle 16:24, Jean Abou Samra 
 ha scritto:
PPS: I see you shut down openlilylib.org. Is the source archived 
somewhere

 so I can better understand openLilyLib?


I think it's here:
https://github.com/openlilylib-documentation/main-site/

Thanks!

Re: Future of openLilyLib

[Federico Bruni]

Il giorno mer 7 ott 2020 alle 16:24, Jean Abou Samra 
 ha scritto:
PPS: I see you shut down openlilylib.org. Is the source archived 
somewhere

 so I can better understand openLilyLib?


I think it's here:
https://github.com/openlilylib-documentation/main-site/

Re: Future of openLilyLib

[Jean Abou Samra]

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib. The
two weeks until yesterday since my (I think pretty strong and explicit)
statement did not trigger *anything* except one stupid and off-topic
discussion. So I realize there is no substantial need for openLilyLib,
and I don't have the resources left (in terms of time and mental or
physical energy) to push it forward without community support. And to
be honest, to include \shapeII into LilyPond or not is definitely not a
matter of having openLilyLib or not.

So today I copied all the relevant repositories to my own Git server
and removed myself from the corresponding Github organizations. I will
use what is there to complete three substantial projects I still have
on my desktop. Everything that is necessary to use and improve the
library and the packages is still freely available and appropriately
licensed, so if anybody considers it worth the effort they can do with
it whatever seems suitable.

Best
Urs


Hi Urs,

Well, for me it's rather that I was initally willing to reply but the
side track turned me off.

I need to admit I have never really tried openLilyLib, mostly because it
requires always running LilyPond with some magic option.

I think there is potential in LilyPond packaging, as the LSR evidences.
(What strikes me most in openLilyLib is its package for alternate notation
fonts.)

I have long had the project of a kind of mix between the LSR and 
openLilyLib's

snippets repository, to combine the Git workflow and a web interface. I will
raise this in my priority list.

Kind regards,
Jean


PS:
Those few who know more about the background shouldn't worry too much
about the final character of this statement ...

No clue what you meant here. Is 'character' as in novels, or strings?

PPS: I see you shut down openlilylib.org. Is the source archived somewhere
so I can better understand openLilyLib?

Re: Future of openLilyLib

[Andrew Bernard]

Urs, I am unable to email you at openlilylib.org. Is there another way 
to contact you off list?



Andrew

Re: Future of openLilyLib

[Carl Sorensen]

I think that Urs did not say he's taking it down.  I think he did say he's not 
making his future improvements public.  He's leaving it up on GitHib, but his 
work will be in a private Git repository.

Thanks,

Carl


Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone
Get Outlook for Android<https://aka.ms/ghei36>


From: lilypond-user  
on behalf of Andrew Bernard 
Sent: Tuesday, October 6, 2020 5:18:03 PM
To: lilypond-user@gnu.org 
Subject: Re: Future of openLilyLib

Urs,

I don't follow. Are you taking down OLL? There are surely many who
depend on it. It's not clear to me what you are saying. I fear you have
reached the wrong conclusion. Even if it is of value to only a dozen
people, is it not still valuable? Don't underestimate the importance - I
could not produce my scores without out. Now I am worried.

Andrew


On 7/10/2020 7:46 am, Urs Liska wrote:
> Well, despite two of today's statements arguing otherwise I must say I
> have come to a different conclusion. I have given myself exactly two
> weeks to make a determination, and I realized I have obviously
> overestimated the value and impact of my pet project openLilyLib.

Re: Future of openLilyLib

[Andrew Bernard]

Urs,

I don't follow. Are you taking down OLL? There are surely many who 
depend on it. It's not clear to me what you are saying. I fear you have 
reached the wrong conclusion. Even if it is of value to only a dozen 
people, is it not still valuable? Don't underestimate the importance - I 
could not produce my scores without out. Now I am worried.


Andrew


On 7/10/2020 7:46 am, Urs Liska wrote:

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib.

Re: Future of openLilyLib

[Urs Liska]

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib. The
two weeks until yesterday since my (I think pretty strong and explicit)
statement did not trigger *anything* except one stupid and off-topic
discussion. So I realize there is no substantial need for openLilyLib,
and I don't have the resources left (in terms of time and mental or
physical energy) to push it forward without community support. And to
be honest, to include \shapeII into LilyPond or not is definitely not a
matter of having openLilyLib or not.

So today I copied all the relevant repositories to my own Git server
and removed myself from the corresponding Github organizations. I will
use what is there to complete three substantial projects I still have
on my desktop. Everything that is necessary to use and improve the
library and the packages is still freely available and appropriately
licensed, so if anybody considers it worth the effort they can do with
it whatever seems suitable. 

Best
Urs

PS:
Those few who know more about the background shouldn't worry too much
about the final character of this statement ...

Am Montag, den 21.09.2020, 17:24 +0200 schrieb Urs Liska:
> Hi all,
> 
> to begin with, I am of the (biased) opinion that openLilyLib is a
> powerful and useful extension infrastructure for LilyPond. There are
> a
> number of versatile and extended ready-to-use packages available,
> most
> notably probably edition-engraver, scholarLY and anaLYsis. But also
> the
> underlying oll-core is versatile and powerful, providing numerous
> building blocks without which I would not start any large-scale
> project
> anymore.
> 
> I can understand why this view is not shared by everyone, most likely
> simply because too much about OLL is obscure or unknown, lacking
> proper
> documentation, although the general introduction at 
> https://openlilylib
> .org should be a good start (and there are substantial manuals for
> the
> scholarLY and stylesheets packages, but only in (undocumentedly)
> self-
> compilable form).
> 
> At this point openLilyLib is completely dependent on my availability,
> at least because I am the only person with knowledge of the basic
> code
> in oll-core. 
> 
> For several reasons which I won't discuss publicly I will have to
> reduce my availablity to work on openLilyLib (and other stuff) and
> may
> be forced to completely withdraw at any point within the next years.
> 
> I would find it a pity if that would mean the end for openLilyLib.
> Therefore I'm looking not for a new maintainer but for more people
> engaging in the project, to build a community around it that can at
> some point continue without my aid.
> 
> The aspects needing support most urgently AFAICT are (in descending
> order):
> 
>  * getting more people familiar with oll-core (using the opportunity
> to
>maybe improve the coding where appropriate)
>  * complete the documentation system in order to make a more complete
>documentation feasible (here the most crucial part is integrating
>consistently scalable score examples in the web site output).
>  * getting more people familiar with the coding of scholarLY
>  * do maintenance of everything, maybe throwing out some less-than-
>useful packages
>  * write a Frescobaldi extension for managing (installing, updating
> the
>library or individual packages, preparing documents) openLilyLib
> and
>providing an API for secondary extensions (e.g. an annotation
>editor/viewer or a tool to graphically insert editionMods).
> 
> If anything of this looks like your cup of tea you are welcome to
> contact me privately or discuss stuff on-list. Of course I am more
> than
> willing to help with any of these tasks.
> 
> Best
> Urs
> 
> 

Re: Future of openLilyLib

[Martín Rincón Botero]

\reshape is nice! I would try to make it clear in the documentation, if 
\reshape is included in the core, that \shape is the legacy form to be 
eventually deprecated and replaced by \reshape. Syntactically, it makes no 
sense to have both functions available for the same thing. If there could be a 
way to simply replace \shape with \shapeII / \reshape, it would be even better.

PS: \shapeII is already part of the project I’m working on. I always wondered 
if there could be a shorthand for \shape. I’m glad I could finally figure out 
today how to clone all the Github OLL repositories!

www.martinrinconbotero.com
On 6. Oct 2020, 18:44 +0200, Karlin High , wrote:
> On 10/6/2020 11:23 AM, Kieren MacMillan wrote:
> > > \reshape ?
> > Dude… nice work. =)
>
> Made me smile, too. I think that's approaching the perfect amount of
> self-reference humor, without crossing the line to guaranteed obscurity
> for newcomers.
> --
> Karlin High
> Missouri, USA
>

Re: Future of openLilyLib

[Werner LEMBERG]

>> \reshape ?
> 
> Dude… nice work.  =)

Care to submit a MR?


Werner

Re: Future of openLilyLib

[Karlin High]

On 10/6/2020 11:23 AM, Kieren MacMillan wrote:

\reshape ?

Dude… nice work.  =)


Made me smile, too. I think that's approaching the perfect amount of 
self-reference humor, without crossing the line to guaranteed obscurity 
for newcomers.

--
Karlin High
Missouri, USA

Re: Future of openLilyLib

[Kieren MacMillan]

> \reshape ?

Dude… nice work.  =)

Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Future of openLilyLib

[Aaron Hill]

On 2020-10-06 8:45 am, Carl Sorensen wrote:
If \shapeII is production ready, then I'm OK with adding it.  But is 
should
NOT be named \shapeII when it goes into core.  It should be something 
like

\shapeControl.  \shapeII reflects the history that it came after the
creation of \shape.  \shape might even be better, but since we have 
code
out there that uses \shape but is not \shapeII compliant, we can't 
really

use \shape.


\reshape ?


-- Aaron Hill

Re: Future of openLilyLib

[Carl Sorensen]

On Tue, Oct 6, 2020 at 8:43 AM Andrew Bernard 
wrote:

> Hi JanPeter,
>
> 
>


> One thing that concerns me with lilypond at the present is what I see
> as a sort of balkanisation of code. We have LSR, OLL, and people
> making one-shot GIT repos, and it's all very fragmented. I don't think
> this is good for newcomers, and splitting like this is never good for
> open source projects. I can see the arguments for all these ways of
> making add-ons for lilypond, but it worries me. Yes, LSR is for
> snippets and exemplars, not necessarily for full blown code as OLL is,
> but lately there has been a lot of the latter in LSR that I feel could
> be in OLL.
>

Balkanization is of concern to me as well.  Although in the past, I was
against having a Lilypond stackexchange be official, my recent experience
with TeX stackexchange has caused me to wonder if we should make an
"official" LilyPond stackexchange to replace the user list.  But this may
be a thread hijack.

>
> And then there is this sort of impedance mismatch balkanisation - I
> think OLL should be a feeder into lilypond core, but it appears this
> may never happen. I'd like to promote that idea more. One example
> comes to mind: \shapeII. I have hammered this to a high degree in
> thousands of uses in hundreds of pages of scores over the years. Yes
> there is a small corner case bug or two with it, but nothing stopping
> it going into lilypond I think. It's probably the function I use in
> lilypond more than any other one. In other words, purely from my
> experience, I think it is pretty well tested and would be a good
> candidate for inclusion. Some of the pedal work that Harm and I did
> ought to be in lilypond also I think. What I am saying is that I see
> OLL as a long term incubator for lilypond features. Just a couple of
> ideas from me.
>

If \shapeII is production ready, then I'm OK with adding it.  But is should
NOT be named \shapeII when it goes into core.  It should be something like
\shapeControl.  \shapeII reflects the history that it came after the
creation of \shape.  \shape might even be better, but since we have code
out there that uses \shape but is not \shapeII compliant, we can't really
use \shape.

Thanks,

Carl

Re: Future of openLilyLib

[Andrew Bernard]

Hi JanPeter,

I have contributed a bit to OLL and its machinery and I think it is an
important and indeed necessary resource. I am not sure why the uptake
is so limited, but I think somehow we have to communicate how easy it
is to install and use more effectively.

One thing that concerns me with lilypond at the present is what I see
as a sort of balkanisation of code. We have LSR, OLL, and people
making one-shot GIT repos, and it's all very fragmented. I don't think
this is good for newcomers, and splitting like this is never good for
open source projects. I can see the arguments for all these ways of
making add-ons for lilypond, but it worries me. Yes, LSR is for
snippets and exemplars, not necessarily for full blown code as OLL is,
but lately there has been a lot of the latter in LSR that I feel could
be in OLL.

And then there is this sort of impedance mismatch balkanisation - I
think OLL should be a feeder into lilypond core, but it appears this
may never happen. I'd like to promote that idea more. One example
comes to mind: \shapeII. I have hammered this to a high degree in
thousands of uses in hundreds of pages of scores over the years. Yes
there is a small corner case bug or two with it, but nothing stopping
it going into lilypond I think. It's probably the function I use in
lilypond more than any other one. In other words, purely from my
experience, I think it is pretty well tested and would be a good
candidate for inclusion. Some of the pedal work that Harm and I did
ought to be in lilypond also I think. What I am saying is that I see
OLL as a long term incubator for lilypond features. Just a couple of
ideas from me.

I am ready, willing and able to work on OLL, so please be aware of that.

Andrew


On Wed, 7 Oct 2020 at 00:33, Jan-Peter Voigt  wrote:
>
> Hi all,
>
> I would like to repeat Urs' call to participate in the work of OLL. I
> share the opinion that it is a very versatile and powerful toolbox. My
> own contributions are mainly the edition-engraver and the
> lalily-templates. If you have any questions about what they are and how
> they work, feel free to contact me via this list or py pm.
>
> Best,
> Jan-Peter

Re: Future of openLilyLib

[Jan-Peter Voigt]

Hi all,

I would like to repeat Urs' call to participate in the work of OLL. I
share the opinion that it is a very versatile and powerful toolbox. My
own contributions are mainly the edition-engraver and the
lalily-templates. If you have any questions about what they are and how
they work, feel free to contact me via this list or py pm.

Best,
Jan-Peter

Am 21.09.20 um 17:24 schrieb Urs Liska:
> Hi all,
>
> to begin with, I am of the (biased) opinion that openLilyLib is a
> powerful and useful extension infrastructure for LilyPond. There are a
> number of versatile and extended ready-to-use packages available, most
> notably probably edition-engraver, scholarLY and anaLYsis. But also the
> underlying oll-core is versatile and powerful, providing numerous
> building blocks without which I would not start any large-scale project
> anymore.
>
> I can understand why this view is not shared by everyone, most likely
> simply because too much about OLL is obscure or unknown, lacking proper
> documentation, although the general introduction at https://openlilylib
> .org should be a good start (and there are substantial manuals for the
> scholarLY and stylesheets packages, but only in (undocumentedly) self-
> compilable form).
>
> At this point openLilyLib is completely dependent on my availability,
> at least because I am the only person with knowledge of the basic code
> in oll-core.
>
> For several reasons which I won't discuss publicly I will have to
> reduce my availablity to work on openLilyLib (and other stuff) and may
> be forced to completely withdraw at any point within the next years.
>
> I would find it a pity if that would mean the end for openLilyLib.
> Therefore I'm looking not for a new maintainer but for more people
> engaging in the project, to build a community around it that can at
> some point continue without my aid.
>
> The aspects needing support most urgently AFAICT are (in descending
> order):
>
>  * getting more people familiar with oll-core (using the opportunity to
>maybe improve the coding where appropriate)
>  * complete the documentation system in order to make a more complete
>documentation feasible (here the most crucial part is integrating
>consistently scalable score examples in the web site output).
>  * getting more people familiar with the coding of scholarLY
>  * do maintenance of everything, maybe throwing out some less-than-
>useful packages
>  * write a Frescobaldi extension for managing (installing, updating the
>library or individual packages, preparing documents) openLilyLib and
>providing an API for secondary extensions (e.g. an annotation
>editor/viewer or a tool to graphically insert editionMods).
>
> If anything of this looks like your cup of tea you are welcome to
> contact me privately or discuss stuff on-list. Of course I am more than
> willing to help with any of these tasks.
>
> Best
> Urs
>
>

Re: Future of openLilyLib

[Jean Abou Samra]

Hi all,

I guess the problem raised here is tough (is LilyPond a markup language
or a programming library, since you in fact mix notes and Scheme programs?).

Nevertheless, I'd like to make a point that seems to have been overlooked
so far: it's absolutely impossible to change the licensing of LilyPond by
now. There are 210 contributors in the Git repository. Adding an exception
to the LilyPond licensing would imply that we must get agreement from all
these contributors. This holds for openLilyLib too (the number of 
contributors

is in dozensor so).

Therefore, it's pretty pointless to discuss adding exceptions to LilyPond's
terms of use (GPL). We cannot do this from the legal point of view, as 
far as

I understand.

At any rate, ***I strongly urge everyone in this**thread to honor a 
one-day timeout***,

until the day after tomorrow. Discussions with repeated posts in short time
frames tend to spiral out of control pretty quickly; let's give everyone the
time to reflect so as to make the talk productive.

Please, no posts this evening and tomorrow. Let everyone cool down.

After that, we can calmly discuss the licensing issue in a separate thread,
as well as address Urs' original question.

Cheers,
Jean

RE: Future of openLilyLib

[Daniel Rosen]

> -Original Message-
> From: David Kastrup  
> Sent: Tuesday, September 22, 2020 8:12 AM
> To: Karsten Reincke 
> Cc: lilypond-user@gnu.org; Carl Sorensen 
> Subject: Re: Future of openLilyLib
>
> Karsten Reincke  writes:
>
> > Summary:
> >
> > If I wrote a piece of music using LilyPond Code (for being interpreted 
> > by the Lilypond interpreter) and if I included OpenLilyLib into my 
> > code,
>
> If you include OLL code by copy into your source code.  If you use its 
> advertised interfaces, however, that does not make it part of your code.

I'm not saying I disagree with your interpretation, I'm just curious: are you 
aware of any legal precedent (in the common-law sense) or law code supporting 
it?

DR

Once for all and one last time (was Future of openLilyLib)

[Karsten Reincke]

Dear ML members;

The thread becomes longer and longer. Hence I am going to summarize my 
concerns and won't repeat myself never again:


1) In the beginning, there was the ask of Urs to be supported by 
developing OLL because he wants to reduce his efforts. For making OLL a 
little more welcoming, I proposed either to re-license OLL under the 
LGPL or to add something like an 'include exception' (for getting the 
similar protection just as the GPL with classpath exception did for Java 
developers using OpenJDK). Additionally, I suggested to become a 
contributor if and when such a clarification has been realized. This 
proposal seems to be rejected. Hence I withdraw my offer.


2) Most of you who see my concerns as ridiculous have in mind, that the 
PDF created by Lilypond is only the output, not another form of the 
Lilypond code, just as the letter written for aunt Tilly is not covered 
by the word processor.


Here I clearly disagree: Lilypond describes itself as a compiler taking 
text written in the LilyPond programming language and compiling this 
text as PDF and/or as midi file. (https://lilypond.org/text-input.html). 
Thus, it does not meet the structure of writing a letter to aunt Tilly. 
The GPL-v3 itself defines, that 'the “source code” for a work means the 
preferred form of the work for making modifications to it. “Object code” 
means any non-source form of a work.' §1 
(https://www.gnu.org/licenses/gpl-3.0.html) A pdf file contains printer 
commands to visualize music. It is a text file too. Thus, one could at 
least argue that the PDF file is the object code of the lilypond source 
code.


Hence, it is not inherently and intuitively clear, that the PDF is the 
autonomous output and has nothing to do with the input of the compiler 
'Lilypond'.


3) If lilypond-code is source-code of a programming language and if it 
can include/use other code licensed under a strong copyleft license then 
it has to be distributed under the same terms, even if it is distributed 
in form of object code (§6 GPL-v3) The relationship between the lilypond 
code of a piece of music and the code being included / used for 
compiling it is the same as the relationship between java code and for 
example the openjdk library: Writing a java program becomes more easy 
for me, because I can use the preliminary work of those programmers, who 
implemented hashes, arrays, etc into the OpenJDK lib. OpenJDK is 
licensed under GHPL-v3. But for not enforcing the using code to be 
licensed under the GPL too, openjdk is released under the GPL with 
classpath exception. This can simply transferred to OLL: I could more 
easily write my lilypond music code, because I could use the preliminary 
OLL work of Urs etc. Unfortunately, OLL does not offer such an 
exception. Hence I have to accept, that my music code (sic!) has to be 
distributed under the terms of the GPL-v3 too, because OLL is licensed 
under the GPL.


4) Point 2 and 3 together can be used to argue, that also a distributed 
pdf file compiled by lilypond has also to be licensed under the GPL.


5) I've learned, that all(?) of you consider this an untenable if not 
silly position and that the PDFs and midi-files compiled by Lilypond are 
never affected by the strong copyleft effect of the GPL. That's good to 
hear. But I don't understand, why - under this circumstances - it should 
be garbage to add a respective clarifying statement (the 'include 
clause' or however you want to name it), if it is at least partially 
conceivable that such a position will be taken and if all of you do not 
want to use / establish its consequences. But that's my problem.


6) For the future
- I won't come back to you with this issue
- I unfortunately cannot work on the further development of the OLL
- I won't use OLL to minimize my risk
- I will use Lilypond ...
  - but I won't distribute my essential work in form of lilypond code
  - and reduce its distribution in form of PDFs to an absolute minimum 
for minimizing my risk.


And as far as I understood you correctly, none of you will try to force 
me to publish it under the terms of the GPL. That's also good to hear. 
Overall, that's not the best result we could get, but it is a result.


With best wishes and sincere thanks for the wonderful Lilypond Composer 
environment


KR

--
  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: Future of openLilyLib

[Lukas-Fabian Moser]

Hi Karsten,

I gratefully appreciate your work on LilyPond. Because of your 
friendly and affectionate way of sharing your knowledge in this 
mailing list - as I was allowed to experience it in the past - I also 
want to believe that OpenLilylib is valuable. Personally, I refrained 
from familiarizing myself with it. The reason was not, that I indeed 
could not quickly activate a 'Hello-World' "song". Even higher entry 
thresholds usually do not prevent me from diving into special areas of 
programming. The reason I ended up putting OpenLilyLib aside was its 
license model.


OpenLilyLib is licensed under the GPL. Thus, the copyleft effect 
forces that all Lilypond files which include OpenLilyLib files, have 
also to be distributed under the terms of the GPL. Moreover, due to 
the fact, that Lilypond is the source code, which will be compiled 
(into scores), one also has to respect the GPL rules of distributing 
compiled versions of the code.


We had this discussion a year ago and I won't repeat the details. The 
last time it ended in a kind of unfruitful shitstorm which did not 
help anyone. But if you now look for supporters, you have to see that 
your license model reduces the list of candidates: They must be 
familiar with music, they must love beautifully designed musical text, 
they must be able to program scheme (LISP) code (in fact not the most 
widely used programming language) and they must be willing to require 
the others to distribute their music under the terms of the GPL.


Nearly all other GPL licensed programming libs/programs had the same 
problem and found solutions. Linus invented the "explicit syscall 
exception" for his kernel, openjdk was released under the "GPL with 
classpath exception". That is why I would like to propose again to 
re-license the OpenLilyLib under the terms of the LGPL. Or, if that is 
not possible, to link the lib with a kind of an "include exception" 
with the purpose, to explicitly prevent the including musical scores  
from also having to be released under the terms of the GPL.


I think that such a clarification would invite collaborators.


Although the discussion has become quite extensive by now, two points 
strike me as not having been emphasized as clearly as they should be in 
my opinion (I'm sorry if I missed them) - one technical/legal, one social:


First, my impression is that, at the root of the discussion, there's a 
distinction that needs to be made more clearly between "including" and 
"\including". When I use an \include directive (e.g. for using the OLL 
framework in a score of mine), I am not incorporating code contained in 
the library into my own score, but telling LilyPond to execute the 
commands of a library that it is the user's duty to make sure can be 
(legally) found on my computer. Not only am I using that library as kind 
of a black box (in that I only know how to use its API, without caring 
about or building on details on its implementation), but I am also not 
"including" the library in a literal sense into my own work (namely, my 
.ly file).
Instead, I create a .ly file that happens to be only compilable (using 
LilyPond) by people who also manage to (legally) get hold of a copy of 
the library - in case of OLL, a feat easily accomplished since OLL is 
GPL and distributed via github.
Or, to put it in a nutshell: Your remarks sound as if you think that 
"\include"ing a library means "including" it into your work, which I 
dispute.


Second - and this is what, frankly, makes me feel sad about your 
endeavour: I think it can be fairly said that your interpretation of the 
legal matter at hand does not seem to be shared by most of the folks on 
the lilypond-user mailing list. Of course, you're perfectly entitled to 
stick to your interpretation and, on that basis, decide that you do not 
want to participate in the OLL development. But in your remarks I 
quoted, you seem to imply that there might be others (and lots) of 
potential contributors that are kept from participating for the same 
reasons that you state for yourself.
I think that's not doing justice to a community (and I'm assuming here 
that a quite large percentage of the people most familiar with LilyPond 
and most capable of handling it, and tweaking and extending it, are 
actually active, at least intermittently, on lilypond-user) that 
continually strikes me with the enormous generosity of its members. I'm 
continually astonished, awed and humbled by the amount of expertise 
shared on lilypond-user on a daily basis, coming from people who provide 
many lines of non-trivial scheme code without ever claiming copyright. 
(A dangerous stance! you might say, yet their behaviour seems to make 
clear that they intend their ideas to be used by whoever might make use 
of them.) I know perfectly well that there might be bloodcurling legal 
difficulties looming as soon as only one of the regular contributors 
raises the legal question of who's using his/her snippets in their 

Re: Licensing (was: Future of openLilyLib)

[Henning Hraban Ramm]

> Am 22.09.2020 um 19:29 schrieb Tim McNamara :

> I am curious- is there a parallel discussion among LaTeX users?  I’ve never 
> used LaTeX nor been part of discussions in the that community, but the 
> operating similarities are strong (a text input file with formatting markup 
> producing an output file such as a PDF).

LaTeX isn’t copylefted, thus the discussion wouldn’t make sense.

see
https://www.latex-project.org/lppl/

According to 
https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
LPPL is not compatible with GPL.


But ConTeXt is under GPL (and its documentation under CC BY-NC-SA).
see https://wiki.contextgarden.net/Read_Me
(It’s a bit contradictory, since distributors are also allowed to assume LPPL – 
basically: we want this to be free software, otherwise we don’t care.)

Yes, we had the discussion a few times.
We (the developers and active users of ConTeXt including the members of ConTeXt 
group*) see it like most in this discussion: The license affects only the code 
of ConTeXt itself, never your works, that can’t be works derived of ConTeXt, 
even if they might contain a few lines of code from the core or from examples.

And ConTeXt’s main developer says explicitely: “don't bother discussing licence 
issues and related things with us for the mere sake of discussing licence 
stuff”.


*) BTW, it would make sense to finally found an official LilyPond users group. 
Or several (international associations are legally difficult).


> If one creates a word processing document using a font, whether copyleft or 
> copyright, does the document publishing have to adhere to the licensing of 
> the font?  Of course not.

Font licensing is a completely different problem.

You can’t handle a font as a copyrighted work, otherwise a user would have to 
license every single use of a character!

But a (commercial) font license is meant to allow the free use of a font for 
all projects of one user or company, while the font files shouldn’t get 
published (like in websites), except in non-extractable form (like in PDFs).

With fonts, the threshold of originality is considered too low for copyrighting 
(as a work of art), since the font must work, well, as a font within the 
restrictions of tradition and readability. Only a more or less unreadable font 
would be regarded a work of art.
The legal concept “sweat of the brow” that allows for copyrighting a work of 
craftsmanship only exists in a few jurisdictions.

A font is also not regarded as a program; while it consists of “code”, that was 
not written by a person, but by a graphical application. (Yes, there are 
exceptions, like ours written in MetaFont.)

That means, all commercial font licenses have no legal foundation! The 
international treaty that handles the problem was never ratified by enough 
countries.
That probably also means that free font licenses are mostly obsolete.

IANAL, but I read a lot on that subject.

OT. EOT.

Hraban

Re: Future of openLilyLib

[Martín Rincón Botero]

Sorry, I meant naturally Mr. Reincke, and not Mr. Karsten ;-).

www.martinrinconbotero.com
On 22. Sep 2020, 19:30 +0200, Tim McNamara , wrote:
> On Sep 22, 2020, at 10:20 AM, Partitura Organum  
> wrote:
> >
> > Karsten […] mentioned the lilypond-files: "OpenLilyLib is licensed under 
> > the GPL. Thus, the copyleft effect forces that all Lilypond files which 
> > include OpenLilyLib files, have also to be distributed under the terms of 
> > the GPL.". Thus, if I use OLL in my lilypond and I want to make my lilypond 
> > files public, I have to do so under the GPL v3 license.
> > Or so Karsten states.
> > Secion 5 of GPL v3 does seem to imply this. The question here is whether 
> > typing something like "include oll.ily" in your own ly-file makes your 
> > ly-file a derivative work of OpenLilyLib. If "yes" the GPL v3 license 
> > demands you license your ly-file as GPL as well if you ever publish it. If 
> > "no", well then it is for you to decide which license works best for you.
>
> Calling what amounts to a subroutine does not cause the subroutine to own the 
> output, which is IMHO all that is being done with "\include oll.ily” (or any 
> \include commands) so the answer to the question is “no.” One may publish 
> one’s input file, although the utility of that is questionable except as a 
> teaching tool, under whatever license one wishes. That may cause a cognitive 
> conflict with the GPL for some users. One may publish the output of the 
> application under whatever license one wishes, including standard copyright 
> within the jurisdiction where one lives. Were the GPL to require creators to 
> license their output under some specific copyleft arrangement, few people 
> would use any GPL software. And indeed, there may be people/entities that 
> refuse to use free software due to that misunderstanding. Lilypond and/or the 
> GPL does not own the user's input or output files- any more than Microsoft 
> owns all documents written in Word- as that would of course contravene the 
> notion of freedom in free software.
>
> I am curious- is there a parallel discussion among LaTeX users? I’ve never 
> used LaTeX nor been part of discussions in the that community, but the 
> operating similarities are strong (a text input file with formatting markup 
> producing an output file such as a PDF).
>
> If one creates a word processing document using a font, whether copyleft or 
> copyright, does the document publishing have to adhere to the licensing of 
> the font? Of course not.
>
>
>

Re: Future of openLilyLib

[Martín Rincón Botero]

I probably shouldn’t be saying anything about this because I’m not an expert in 
licensing. However, Mr. Karsten’s assertion that “my work depends on OLL, not 
because I use lilypond, but because I functions of the OLL” is wrong. It 
implies that the content of a Lilypond file is dependent on Lilypond or OLL. 
The content of a Lilypond file is a musical score (that uses Lilypond’s 
syntax), which is an independent creation that can be formatted in other 
programs or by hand. Lilypond’s syntax is not part of the creation, but only 
the interface to use its formatting options. The presence of OLL doesn’t make 
an artistic work less independent either, since it only extends Lilypond’s 
formatting capabilities (which are all independent of the musical work as 
well). Only in the situation where a musical creation is indeed dependent on 
OLL to exist (say, an algorithmic composition that needs to run OLL every time 
is executed, where OLL provides certain predefined pitch, rhythmic or timbre 
combinations) is where I would be slightly concerned especially if I were to 
sell and distribute this piece of algorithmic music (that would definitely need 
OLL and Lilypond to “exist” and would have to be distributed as well). But OLL 
(nor Lilypond) doesn’t provide any of this, and this hypothetical case doesn’t 
apply.

Regards,
Martín.

www.martinrinconbotero.com
On 22. Sep 2020, 18:18 +0200, Karsten Reincke , wrote:
>
> On 22.09.20 14:58, Tim McNamara wrote:
> > > On Sep 22, 2020, at 4:30 AM, Karsten Reincke  wrote:
> > > Dear Carl;
> > > here is my explanation using the method of showing an analogy:
> >
> > 
> >
> >  If I use Emacs to write a letter to my Aunt Tillie, even though Emacs is 
> > licensed under the GPL my letter to Aunt Tillie remains copyrighted and 
> > private. [...]
> Unfortunately, you are mixing the levels of licensings here:
> If you wrote a letter to aunt Tilly which included a sentence provided by my 
> famous text library to write wonderful letters to aunt Tilli (if such a lib 
> really existed, I of course would have licensed it under the GPL!) and if you 
> therefore had not to type the complete text by yourself, THEN your letter 
> would have to be distributed under the terms of the GPL too - not because, 
> you used the emacs, but because you included parts of my GPL licensed letter 
> lib and the copyleft effect it established.
> That's point here: If I included the OLL into my musical work by using the 
> compiler option lilypond -I ./oll my-score.ly, the my work depends on OLL, 
> not because I use lilypond, but because I functions of the OLL.
> >
> > This is the sort of attack that the GPL and free software has been 
> > subjected to multiple times over decades. It has all been seen and resolved 
> > before.
> It is regrettable that the same methods are used here that the free software 
> community has had to experience for so long, namely personal discrediting as 
> an "argument" in posts without any salutation and any greetings. 
> Nevertheless, there is ever a way to come back to the free and respectful 
> discussion.
> KR
> --
>  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: Future of openLilyLib

[Tim McNamara]

On Sep 22, 2020, at 10:20 AM, Partitura Organum  wrote:
> 
> Karsten […] mentioned the lilypond-files: "OpenLilyLib is licensed under the 
> GPL. Thus, the copyleft effect forces that all Lilypond files which include 
> OpenLilyLib files, have also to be distributed under the terms of the GPL.". 
> Thus, if I use OLL in my lilypond and I want to make my lilypond files 
> public, I have to do so under the GPL v3 license. 
> Or so Karsten states.
> Secion 5 of GPL v3 does seem to imply this. The question here is whether 
> typing something like "include oll.ily" in your own ly-file makes your 
> ly-file a derivative work of OpenLilyLib. If "yes" the GPL v3 license demands 
> you license your ly-file as GPL as well if you ever publish it. If "no", well 
> then it is for you to decide which license works best for you.

Calling what amounts to a subroutine does not cause the subroutine to own the 
output, which is IMHO all that is being done with "\include oll.ily” (or any 
\include commands) so the answer to the question is “no.”  One may publish 
one’s input file, although the utility of that is questionable except as a 
teaching tool, under whatever license one wishes.  That may cause a cognitive 
conflict with the GPL for some users.  One may publish the output of the 
application under whatever license one wishes, including standard copyright 
within the jurisdiction where one lives.  Were the GPL to require creators to 
license their output under some specific copyleft arrangement, few people would 
use any GPL software.  And indeed, there may be people/entities that refuse to 
use free software due to that misunderstanding.  Lilypond and/or the GPL does 
not own the user's input or output files- any more than Microsoft owns all 
documents written in Word- as that would of course contravene the notion of 
freedom in free software.

I am curious- is there a parallel discussion among LaTeX users?  I’ve never 
used LaTeX nor been part of discussions in the that community, but the 
operating similarities are strong (a text input file with formatting markup 
producing an output file such as a PDF).

If one creates a word processing document using a font, whether copyleft or 
copyright, does the document publishing have to adhere to the licensing of the 
font?  Of course not.

Re: Future of openLilyLib

[Tim McNamara]

On Sep 22, 2020, at 10:17 AM, Karsten Reincke  wrote:
> On 22.09.20 14:58, Tim McNamara wrote:
>>> On Sep 22, 2020, at 4:30 AM, Karsten Reincke  
>>>  wrote:
>>> Dear Carl;
>>> 
>>> here is my explanation using the method of showing an analogy:
>>> 
>> 
>> 
>> 
>>  If I use Emacs to write a letter to my Aunt Tillie, even though Emacs is 
>> licensed under the GPL my letter to Aunt Tillie remains copyrighted and 
>> private. [...]
> Unfortunately, you are mixing the levels of licensings here:
> 
> If you wrote a letter to aunt Tilly which included a sentence provided by my 
> famous text library to write wonderful letters to aunt Tilli (if such a lib 
> really existed, I of course would have licensed it under the GPL!) and if you 
> therefore had not to type the complete text by yourself, THEN your letter 
> would have to be distributed under the terms of the GPL too - not because, 
> you used the emacs, but because you included parts of my GPL licensed letter 
> lib and the copyleft effect it established.
> 
> That's point here: If I included the OLL into my musical work by using the 
> compiler option lilypond -I ./oll my-score.ly, the my work depends on OLL, 
> not because I use lilypond, but because I functions of the OLL. 
> 
Dear Karsten-

And, again, I must disagree.  A differentiation exists between the GPL software 
and input/output files used with/resulting from the operation of the software.  
Neither your .ly or .ily file nor the various output options produced by 
Lilypond are required to be released under the GPL or its variants.  Such a 
requirement would just be silly and would result in the termination of the use 
of free software everywhere, practically overnight.  Your input may include 
Scheme or other code to customize the performance of Lilypond for your specific 
purposes, but that is part of your input file and is not part of Lilypond or 
openlilylib and thus not subject to GPL or other such licenses.  Copywrite, 
performance rights, etc., would apply consistent with your local laws.

>> This is the sort of attack that the GPL and free software has been subjected 
>> to multiple times over decades. It has all been seen and resolved before.
> It is regrettable that the same methods are used here that the free software 
> community has had to experience for so long, namely personal discrediting as 
> an "argument" in posts without any salutation and any greetings. 
> Nevertheless, there is ever a way to come back to the free and respectful 
> discussion.
> 
I apologize for being an American and just getting to the point.  It’s how we 
do things and in this culture is not usually considered rude in non-socializing 
settings. I recognize that YMMV and in other cultures our style is considered 
rude.

It may not be your intent, but your argumentation reads like an attack on free 
software via Lilypond/openlilylib in particular.  You seem to be seeing 
obstacles that in practical senses do not exist.  Can you identify any cases in 
which what you are describing has happened in any enforceable manner?  
Hypotheticals can be informative but rarely if ever definitive.

What you are describing has been discussed many times before, in several venues 
in which I have had slight involvement, and has been settled time and again.  I 
have even committed the error I see in your writing.  Software development 
under the GPL has requirements that are not applied to the input or output of 
that software in use cases. 

Re: Future of openLilyLib (to Gilles and David

[Karlin High]

On 9/22/2020 10:50 AM, Karsten Reincke wrote:
2.B) But if yes, 'my' HelloWorld 'song' depends on the program ly- 
and/or scm files under /usr/share/lilypond/2.20.0/. They are licensed 
under the GPLv3. Thus, we have to deal with copyleft effect in any sense 
because a GPL v3 licensed code is integrated into my code and my code 
does not work without that code.


Karsten, to further clarify your position, please comment on this 
variation of the given HelloWorld example:


% BEGIN LILYPOND
\version "2.20.0"

\include "english.ly"

\score {
cf'4
}
% END LILYPOND

Are you expecting that this HelloWorld example is now covered by GPLv3 
due to its dependence on the \include "english.ly" statement?


Now, I am no expert on the questions involved here.

But there are a number of choices available for commercial, proprietary, 
closed-source software that produces sheet music like LilyPond does.


You seem concerned that LilyPond or related projects could assert 
intellectual property rights against work produced with them.


Do have similar concerns about proprietary, closed-source software doing 
the same if you used it? How about if a project needs third-party 
plug-in products for such software?


Again, I have no expertise, just trying to further understand your position.
--
Karlin High
Missouri, USA

Re: Future of openLilyLib

[Karsten Reincke]

On 22.09.20 14:58, Tim McNamara wrote:

On Sep 22, 2020, at 4:30 AM, Karsten Reincke  wrote:

Dear Carl;

here is my explanation using the method of showing an analogy:





 If I use Emacs to write a letter to my Aunt Tillie, even though Emacs 
is licensed under the GPL my letter to Aunt Tillie remains copyrighted 
and private. [...]


Unfortunately, you are mixing the levels of licensings here:

If you wrote a letter to aunt Tilly which included a sentence provided 
by my famous text library to write wonderful letters to aunt Tilli (if 
such a lib really existed, I of course would have licensed it under the 
GPL!) and if you therefore had not to type the complete text by 
yourself, THEN your letter would have to be distributed under the terms 
of the GPL too - not because, you used the emacs, but because you 
included parts of my GPL licensed letter lib and the copyleft effect it 
established.


That's point here: If I included the OLL into my musical work by using 
the compiler option lilypond -I ./oll my-score.ly, the my work depends 
on OLL, not because I use lilypond, but because I functions of the OLL.




This is the sort of attack that the GPL and free software has been 
subjected to multiple times over decades. It has all been seen and 
resolved before.


It is regrettable that the same methods are used here that the free 
software community has had to experience for so long, namely personal 
discrediting as an "argument" in posts without any salutation and any 
greetings. Nevertheless, there is ever a way to come back to the free 
and respectful discussion.


KR

--
  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: Future of openLilyLib

[Karsten Reincke]

Dear Carl; many thanks for your remarks, You'll find my answers int the 
text too


On 22.09.20 15:49, Carl Sorensen wrote:


[...]

But here is where you lost me.  The program using guile-aspell must be 
released under the terms of GPL-v3. But the output of the program need 
not be released under the terms of GPL-v3.  The output can be released 
under any terms the user desires to use.
guile-aspell is a library which is included into your program, which 
therefore depends on the functionality of the guile-aspel lib


[...]

Summary:

If I wrote a piece of music using LilyPond Code (for being
interpreted by the Lilypond interpreter) and if I included
OpenLilyLib into my code, you as the Copyright owners of
OpenLilyLib could me enforce to distribute my work (music'score)
under the terms of the GPL simply by using this analogy. By using
my explanation, you would win every trial in every legal area
which accepted the GPL as an effective license. That's the risk I
would have to take, if I used OpenLilyLib to ease my work.

This is false.  The music score is output, not a program.  It is not a 
derivative work.


It would be a great luck if that was true and if every judge was seen it 
the same way. Unfortunately, there are reasons, that it is not 
necessarily true: Lilypond describes itself as a compiler system which 
takes code and compiles it. Thus, we have the same relationship as 
between source code (lilypond-code) and binaries (PDFs). Please have a 
look at GPL-v3 §6 "Conveying Non-Source Forms": "You may convey a 
covered work in object code form under the terms of [...] " whereby §1 
says that '“Object code” means any non-source form of a work'. 
(https://www.gnu.org/licenses/gpl-3.0.de.html*)*


It is totally clear, that the PDF contains the score in form of printer 
commands and that both, the source and the PDF refer to the same 'music. 
Hence, from the viewpoint of the GPL text itself, the PDF is not only 
output, but a derivative work.


The only thing I am asking for is a clarifying statement of the 
copyright owners, that the copyleft effect of OLL (and Lilypond) does 
not affect the using code so that these arguments do not work



[...]

5) There would be a simple solution for all, for him, for me, and
for the readers of this mailing list: he simply could add an
'including exception' to his licensing statement, which clearly
and explicitly says, that including OpenLilyLib does not cause the
copyleft effect to the including lilypond code. He would not lose
anything: each improvement to OpenLilyLib had to be released under
the terms of the GPL v3, too. And - as he might signal by his
words in this discussion - the using music code remains private.

[...]

The fact, that Mr. Bernard apparently does not want to realize
point 5., puzzles me.

I remain respectfully yours

Karsten Reincke


The inability to recognize the difference between a program and the 
output of a program puzzles me.

I like this 'quotation' ;-)


Sincerely,

Carl


Sincerely,

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: Future of openLilyLib (to Gilles and David

[Karsten Reincke]

On 22.09.20 13:05, Gilles Sadowski wrote:

Hi.

Moving back to the ML; it was not my intention to discuss this
"off-list"; I hope I won't be sued for public disclosure of a private
communication. ;-)
No problem! Moreover, I appreciate your respectful way to clarify 
understandings before jumping into the argumentation!

[...]
Then, I don't understand the rest of the reasoning.[1]

Why do you require a different license for using an *external*
extension (like OpenLilyLib), than for using any of 900+ (".ly"
and ".scm" files bundled with LilyPond) internal ones.

[...]


Dear Gilles,

That indeed touches the heart of the matter. Let me quickly sort the 
situation:


1) Lilypond describes itself as a compiler system: it takes text and 
compiles PDFs. (https://lilypond.org/text-input.html) In general, a 
compiler is an independent program. Its license (normally) does not 
affect the license of its input or output. The GCC (= GPLv3) can be used 
to compile MIT licensed code as well as closed source code. So far, so 
clear I hope.


2) On the first glance - and I had thought, it would be completely true 
- Lilypond seems to be a compiler like the GCC. Now, I've learned by 
you, Gilles, that this is indeed not 100% true: Also my system contains 
60 ly files under /usr/share/lilypond/2.20.0/ly and 93 scm files under 
/usr/share/lilypond/2.20.0/scm. At least many of these files seems to be 
explicitly licensed under the GPLv3 etc.


So, the simple question is this: Is on of these snippets / code 
particles under /usr/share/lilypond/2.20.0/ included=merged with "my" 
following lilypond code


\version "2.20.0"

\score {
    c'4
}

if I insert this code into Frescobaldi (which I did) and let it generate 
the PDF by using the app /usr/bin/lilypond (what it successfully did)


Please read "included/merged" in the meaning of the C Preprocessor: 'my' 
shortened code is expanded to another version which - after this 
expansion - is translated / compiled by the compiler.


2.A) If none of these additional files under /usr/share/lilypond/2.20.0/ 
is included/merged into my code, it does not depend on any GPL licensed 
code and hence I may license it under any license I prefer.


2.B) But if yes, 'my' HelloWorld 'song' depends on the program ly- 
and/or scm files under /usr/share/lilypond/2.20.0/. They are licensed 
under the GPLv3. Thus, we have to deal with copyleft effect in any sense 
because a GPL v3 licensed code is integrated into my code and my code 
does not work without that code.


Whether this inclusion / merging of the system ly/scm code by the 
'preprocessor' into my HelloWorld 'song' which uses this 'system-code' 
shall evoke the relationship of a derivative work, can only be clarified 
by the copyright holder of Lilypond! If they do not want the copyleft 
effect be understood in such a way, that it affects the code that uses 
it, then they must invent an exception clause because the act of merging 
code into another normally creates a derivative work.


So the answer to your question is this: The only difference between OLL 
and the internal Lilypond files is that OLL is external. Hence, them OLL 
copyright owners (and not the copyright owners of LilyPond) must state, 
how they want the copyleft be understood. If the copyleft effect shall 
not affect the calling code, they must create their own exception, 
otherwise one had to assume that the code using the OLL is a derivative 
work of the OLL.


3)  David Castrup stated in another post, that - in opposite to the OLL 
copyright owner - the developers of the LSR perhaps could enforce their 
rights in a trial, because their snippets are adapted / copied into the 
using code (and therefore - as he said - "for LSR code, a GPL license 
would be quite problematic"). But that - as he added - is not how OLL is 
used. Instead of this - he said -if one uses OLL by its advertised 
interfaces, that does not make it part of the using code.


And indeed: for using OLL one only has to download the OLL and has to 
make the OLL availbale by the -I (=include) option of lilypond -I 
~/oll-lib path/to/file.ly. (https://openlilylib.org/getstarted/install.html)


But now we've reached the same point agvain: from this viewpoint it is 
totally clear, that the OLL code is handed over to the compiler lilypond 
in a combination with the using program whose functionality depends on 
the OLL. The OLL is licensed under the GPL-v3, hence the using code is a 
derivative work of the OLL as long as the OLL does not offer an 
exception or statement or whatever, which clearly says, that the 
copyleft effect does not affect the code using the OLL.


So, again, we have the same conclusion: As long as the copyright owner 
of the OLL do not deliver an 'inclusion  exception' which states that 
the copyleft effect shall not affect the code which uses functions of 
the OLL, the users of the OLL have to take the risk to be enforced to 
release their music under the terms of the GPL.


4) Again: The 

Re: Future of openLilyLib

[Partitura Organum]

On 22-9-2020 15:49, Carl Sorensen wrote:


Since the music code is not included in the pdf output, the pdf output 
is not subject to GPL.


The fact, that Mr. Bernard apparently does not want to realize
point 5., puzzles me.

I remain respectfully yours

Karsten Reincke


The inability to recognize the difference between a program and the 
output of a program puzzles me.


Sincerely,

Carl

This is a bit unfair. Karsten did not mention the pdf- or midi-files, he 
mentioned the lilypond-files: "OpenLilyLib is licensed under the GPL. 
Thus, the copyleft effect forces that all Lilypond files which include 
OpenLilyLib files, have also to be distributed under the terms of the 
GPL.". Thus, if I use OLL in my lilypond and I want to make my lilypond 
files public, I have to do so under the GPL v3 license.

Or so Karsten states.
Secion 5 of GPL v3 does seem to imply this. The question here is whether 
typing something like "include oll.ily" in your own ly-file makes your 
ly-file a derivative work of OpenLilyLib. If "yes" the GPL v3 license 
demands you license your ly-file as GPL as well if you ever publish it. 
If "no", well then it is for you to decide which license works best for you.


A nice wrapup from from a softwaredevelopemnt point of view can be read 
here: 
https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/


Regards,
Auke

Re: Future of openLilyLib

[peerceval]

On 22.09.20 14:58, Tim McNamara wrote:

On Sep 22, 2020, at 4:30 AM, Karsten Reincke  wrote:

Dear Carl;

here is my explanation using the method of showing an analogy:





You are conflating the GPL as applied to functional software versus 
the rights of the user for the content produced through the use of 
that functional software. The use of GPL software to produce content 
does not subject the content to the GPL.


GPL software can be used to produce copyrighted material without any 
difficulty whatsoever. If I use Emacs to write a letter to my Aunt 
Tillie, even though Emacs is licensed under the GPL my letter to Aunt 
Tillie remains copyrighted and private. The same is true with music 
produced through the use of Lily Pond; my input document ending in .LY 
is not subject to the GPL. Scheme calls, overrides, etc., are part of 
my content and not part of Lilypond.


This is the sort of attack that the GPL and free software has been 
subjected to multiple times over decades. It has all been seen and 
resolved before.

Re: Future of openLilyLib

[Carl Sorensen]

On Tue, Sep 22, 2020 at 3:08 AM Karsten Reincke  wrote:

> Dear Carl;
>
> here is my explanation using the method of showing an analogy:
>
>
> (1.A) MIT/GNU Scheme:
> (a) is an interpreter of the Scheme programming language
> (b) is licensed under the GPL
> (c) takes Scheme Code & delivers output
>
> (https://www.gnu.org/software/mit-scheme/)
>
> => Any Scheme code being taken as input for the MIT/GNU Scheme interpreter
> may be licensed under any other license. The GPL copy left effect only
> affects the development of the MIT/GNU Scheme interpreter itself.
>
>
> (1.B) guile-aspell
> (a) is a Guile Scheme library for comparing a string against a dictionary
> (b) is licensed under GPL 3+
> (c) is included into an overarching program functionally using this library
> (d) is interpreted by MIT/GNU Scheme in combination with the overarching
> program
>
> https://www.gnu.org/software/guile/libraries/
>
> => Due to §5.c of GPL-v3 (https://www.gnu.de/documents/gpl-3.0.en.html)
> the overarching program using the library guile-aspell must be released
> under the terms of GPL-v3 too because it depends of the functionally of the
> guile-aspell library
>

But here is where you lost me.  The program using guile-aspell must be
released under the terms of GPL-v3.  But the output of the program need not
be released under the terms of GPL-v3.  The output can be released under
any terms the user desires to use.

>
> (2.A) Lilypond:
> (a) is an interpreter of the Lilypond notation language
> (b) is licensed under the GPL
> (c) takes Lilypond code & delivers output
>
> (https://lilypond.org/index.html)
>
> =>  Any Lilypond code being taken as input for the Lilypond program may be
> licensed under any other license. The GPL copy left effect only affects the
> development of the Lilypond program itself
>
>
> (2.B) OpenLilyLib
> (a) is a Lilypond library for the GNU LilyPond music notation software
> (b) is licensed under GPL 3+
> (c) is included into an overarching lilypond music code functionally using
> this library
> (d) is interpreted by the LilyPond interpeter in combination with the
> overarching lilypond music code
>
> https://openlilylib.org/
>
> => Due to §5.c of GPL-v3 (https://www.gnu.de/documents/gpl-3.0.en.html)
> the overarching lilypond code using the library OpenLilyLib must be
> released under the terms of GPL-v3 too because it depends of the
> functionally of the OpenLilyLib library
>

Yes, if you choose to release the lilypond code, it must be released under
GPL-v3.  But if you release only the output of the code, no such
restriction applies.


> Summary:
>
> If I wrote a piece of music using LilyPond Code (for being interpreted by
> the Lilypond interpreter) and if I included OpenLilyLib into my code, you
> as the Copyright owners of OpenLilyLib could me enforce to distribute my
> work (music'score) under the terms of the GPL simply by using this analogy.
> By using my explanation, you would win every trial in every legal area
> which accepted the GPL as an effective license. That's the risk I would
> have to take, if I used OpenLilyLib to ease my work.
>
This is false.  The music score is output, not a program.  It is not a
derivative work.


> Supplement:
>
> Andrew Bernard asked in another mail, whether it would be "my intent to
> shut down lilypond altogether" by pointing out this license issue. He fears
> the "deleterious effect of my post", that "the users and readers of this
> list" could be "deterred from using it". He does not want to " see
> OpenLilyLib because of a complicated legal misrepresentation". Finally, he
> declared my hint "as an attempt to damage openlilylib in people's minds"
> and demanded "Really, enough now."
>
> Once for all:
>
> 1) It was my intention to be enabled to use OpenLilyLib.
>
> 2) It is not a misinterpretation, it is the established viewpoint. Another
> 3rd. example: Due to the same reason, MariaDB has re-licensed its
> connectors under the LGPL for preventing its users from the trap of the GPL
> licensed mysql connectors.
>
But this doesn't require GPL license on reports generated from the
database.

> 3) Mr. Bernard did not consider the difference between the interpreting
> program and the interpreted code. That's his fault and leads to his
> misunderstandings.
>
> 4) Mr. Bernard wants to protect his work (a well understandable objective)
> and tries to protect it be declaring his disputant (me) as an enemy with a
> dishonest hidden agenda. He can do so. But he - and therefore: Urs, who has
> asked for help - has lost a potential contributor.
>
> 5) There would be a simple solution for all, for him, for me, and for the
> readers of this mailing list: he simply could add an 'including exception'
> to his licensing statement, which clearly and explicitly says, that
> including OpenLilyLib does not cause the copyleft effect to the including
> lilypond code. He would not lose anything: each improvement to OpenLilyLib
> had to be released under the terms of the GPL v3, 

Re: Future of openLilyLib

[Tim McNamara]

> On Sep 22, 2020, at 4:30 AM, Karsten Reincke  wrote:
> Dear Carl;
> 
> here is my explanation using the method of showing an analogy:
> 



You are conflating the GPL as applied to functional software versus the rights 
of the user for the content produced through the use of that functional 
software. The use of GPL software to produce content does not subject the 
content to the GPL.

GPL software can be used to produce copyrighted material without any difficulty 
whatsoever. If I use Emacs to write a letter to my Aunt Tillie, even though 
Emacs is licensed under the GPL my letter to Aunt Tillie remains copyrighted 
and private. The same is true with music produced through the use of Lily Pond; 
my input document ending in .LY is not subject to the GPL. Scheme calls, 
overrides, etc., are part of my content and not part of Lilypond.

This is the sort of attack that the GPL and free software has been subjected to 
multiple times over decades. It has all been seen and resolved before.

Re: Future of openLilyLib

[David Kastrup]

Jacques Menu  writes:

> Hello everybody,
>
> The legal subtleties of public licensing never made their way into my
> mind, sorry for being limited…
> What would the difference be, should openLilyLib use LGPL instead of GPL?

You could use and distribute OLL derivatives integrated with non-GPL
licensed software (such as Dorico) as long as you provided the source
code of your OLL derivative in a manner where people could change and
relink with changed versions.

That's more or less all.  I haven't seen anybody wanting to do anything
of that kind, though.

-- 
David Kastrup

Re: Future of openLilyLib

[David Kastrup]

Karsten Reincke  writes:

> Dear Carl;
>
> here is my explanation using the method of showing an analogy:
>
>
> (1.A) MIT/GNU Scheme:
> (a) is an interpreter of the Scheme programming language
> (b) is licensed under the GPL
> (c) takes Scheme Code & delivers output
>
> (https://www.gnu.org/software/mit-scheme/)
>
> => Any Scheme code being taken as input for the MIT/GNU Scheme
> interpreter may be licensed under any other license. The GPL copy left 
> effect only affects the development of the MIT/GNU Scheme interpreter
> itself.
>
>
> (1.B) guile-aspell
> (a) is a Guile Scheme library for comparing a string against a dictionary
> (b) is licensed under GPL 3+
> (c) is included into an overarching program functionally using this library
> (d) is interpreted by MIT/GNU Scheme in combination with the
> overarching program
>
> https://www.gnu.org/software/guile/libraries/
>
> => Due to §5.c of GPL-v3
> (https://www.gnu.de/documents/gpl-3.0.en.html) the overarching program
> using the library guile-aspell must be released under the terms of
> GPL-v3 too because it depends of the functionally of the guile-aspell
> library
>
> (2.A) Lilypond:
> (a) is an interpreter of the Lilypond notation language
> (b) is licensed under the GPL
> (c) takes Lilypond code & delivers output
>
> (https://lilypond.org/index.html)
>
> =>  Any Lilypond code being taken as input for the Lilypond program
> may be licensed under any other license. The GPL copy left effect only 
> affects the development of the Lilypond program itself
>
>
> (2.B) OpenLilyLib
> (a) is a Lilypond library for the GNU LilyPond music notation software
> (b) is licensed under GPL 3+
> (c) is included into an overarching lilypond music code functionally
> using this library
> (d) is interpreted by the LilyPond interpeter in combination with the
> overarching lilypond music code
>
> https://openlilylib.org/
>
> => Due to §5.c of GPL-v3
> (https://www.gnu.de/documents/gpl-3.0.en.html) the overarching
> lilypond code using the library OpenLilyLib must be released under the
> terms of GPL-v3 too because it depends of the functionally of the
> OpenLilyLib library

Sure, you cannot magically remove the GPL from LilyPond just because you
are using it in connection with OLL.  But that's a red herring.

> Summary:
>
> If I wrote a piece of music using LilyPond Code (for being interpreted
> by the Lilypond interpreter) and if I included OpenLilyLib into my
> code,

If you include OLL code by copy into your source code.  If you use its
advertised interfaces, however, that does not make it part of your code.

> you as the Copyright owners of OpenLilyLib could me enforce to
> distribute my work (music'score) under the terms of the GPL simply by
> using this analogy. By using my explanation, you would win every trial
> in every legal area which accepted the GPL as an effective
> license. That's the risk I would have to take, if I used OpenLilyLib
> to ease my work.

That's just garbage, sorry.  It would apply for LSR snippets which are
not used via an interface but are code pieces to be copied and adapted
into your source.  For LSR code, a GPL license would be quite
problematic (by the way, what is the licensensing of LSR pieces?).  But
that is not how OLL is used.

-- 
David Kastrup

Re: Future of openLilyLib

[David Kastrup]

Carl Sorensen  writes:

> On Mon, Sep 21, 2020 at 4:00 PM Karsten Reincke  wrote
> 
>
>>
>> We had this discussion a year ago and I won't repeat the details. The
>> last time it ended in a kind of unfruitful shitstorm which did not
>> help anyone. But if you now look for supporters, you have to see that
>> your license model reduces the list of candidates: They must be
>> familiar with music, they must love beautifully designed musical
>> text, they must be able to program scheme (LISP) code (in fact not
>> the most widely used programming language) and they must be willing
>> to require the others to distribute their music under the terms of
>> the GPL.
>>
>
> What is special about OpenLilyLib that requires LilyPond music to be
> released under the GPL, when music not using OpenLilyLib does not need
> to be released under the GPL?  How does OpenLilyLib change the type of
> license required for the PDF file generated by LilyPond?

It doesn't.  But if you copy OLL code into source code of yours (not via
its interfaces, but by copying actual code), for example because you
want to pin down a particular version of OLL code, this source code and
its derivatives (presumably including the generated PDF) can only be
distributed under the GPL.

That's not the intended way of using OLL, of course.

-- 
David Kastrup

Re: Future of openLilyLib

[Gilles Sadowski]

Hi.

Moving back to the ML; it was not my intention to discuss this
"off-list"; I hope I won't be sued for public disclosure of a private
communication. ;-)

[See quoted text for the two messages that went off-list.]

2020-09-22 12:40 UTC+02:00, Karsten Reincke :
>
> On 22.09.20 12:17, Gilles Sadowski wrote:
>> Hi.
>>
>> 2020-09-22 11:07 UTC+02:00, Karsten Reincke :
>>> Dear Carl;
>>>
>>> here is my explanation using the method of showing an analogy:
>> Is this what your are aiming at:
>>https://www.gnu.org/licenses/gcc-exception-3.1.html
>>https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
>> ?
> Yep, but please keep in mind: I think, tt's not necessary to modify the
> licensing statements of Lilypond itself (the interpreter). The GPL-v3
> seems to be perfect.

Then, I don't understand the rest of the reasoning.[1]

Why do you require a different license for using an *external*
extension (like OpenLilyLib), than for using any of 900+ (".ly"
and ".scm" files bundled with LilyPond) internal ones.

Would it change anything if OpenLilyLib were bundled too (or
downloaded automatically as part of the LilyPond installation
process)?

Regards,
Gilles

[1] IANAL: It would be interesting if you could provide links
to cases where a situation as you described has occurred
(i.e. IIUC a court decision that forced someone to offer his
copyrighted work because it was produced with a copyleft
software).

>> If so, do you confirm that currently you do not use "lilypond" (the
>> software) itself in order to compile music into a score (e.g. PDF)
>> because that exception is *not* mentioned for the software?
>
> No, I do not confirm this. I use Lilypond as probably al the others. I
> write my music scores by using the lilypond language. And I let compile
> my music score into PDF (and midi) files by the Lilypond program.
> Mostly, I use Frescobaldi to edit my music score.
>
> I look at Lilypond at that what it is: a programming language and a
> compiler/interpreter. If you need another analogy: I look at Lilypond
> like I look at php : a programming language and an interpreter.
>
> Now let us switch on the level of Lilypond code (on the level of a php
> program): If a php program includes a lib licensed under the GPL, it has
> to be released under the terms of the GPL too. And so is the
> relationship between Lilypond Music Code and OpenLilyLib.
>
>> If not (and you do use "lilypond"), how is the situation any different
>> with an extension (like OpenLilyLib) from any other extension that
>> is provided when installing LilyPond?
>
> My code does not include any other Library (no include / import
> statement). That'sd the differenct.
>
> If you want to highlight the point, that interpretation of my Lilypond
> code is done by expanding my code by literally replacing my elements by
> 'your' GPL licensed guile scheme code, then indeed we also need an
> exception like the exception for C/C++ include files.
>
>
> with best regards 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: Future of openLilyLib

[Karsten Reincke]

Dear Carl;

here is my explanation using the method of showing an analogy:


(1.A) MIT/GNU Scheme:
(a) is an interpreter of the Scheme programming language
(b) is licensed under the GPL
(c) takes Scheme Code & delivers output

(https://www.gnu.org/software/mit-scheme/)

=> Any Scheme code being taken as input for the MIT/GNU Scheme 
interpreter may be licensed under any other license. The GPL copy left 
effect only affects the development of the MIT/GNU Scheme interpreter 
itself.



(1.B) guile-aspell
(a) is a Guile Scheme library for comparing a string against a dictionary
(b) is licensed under GPL 3+
(c) is included into an overarching program functionally using this library
(d) is interpreted by MIT/GNU Scheme in combination with the overarching 
program


https://www.gnu.org/software/guile/libraries/

=> Due to §5.c of GPL-v3 (https://www.gnu.de/documents/gpl-3.0.en.html) 
the overarching program using the library guile-aspell must be released 
under the terms of GPL-v3 too because it depends of the functionally of 
the guile-aspell library


(2.A) Lilypond:
(a) is an interpreter of the Lilypond notation language
(b) is licensed under the GPL
(c) takes Lilypond code & delivers output

(https://lilypond.org/index.html)

=>  Any Lilypond code being taken as input for the Lilypond program may 
be licensed under any other license. The GPL copy left effect only 
affects the development of the Lilypond program itself



(2.B) OpenLilyLib
(a) is a Lilypond library for the GNU LilyPond music notation software
(b) is licensed under GPL 3+
(c) is included into an overarching lilypond music code functionally 
using this library
(d) is interpreted by the LilyPond interpeter in combination with the 
overarching lilypond music code


https://openlilylib.org/

=> Due to §5.c of GPL-v3 (https://www.gnu.de/documents/gpl-3.0.en.html) 
the overarching lilypond code using the library OpenLilyLib must be 
released under the terms of GPL-v3 too because it depends of the 
functionally of the OpenLilyLib library


Summary:

If I wrote a piece of music using LilyPond Code (for being interpreted 
by the Lilypond interpreter) and if I included OpenLilyLib into my code, 
you as the Copyright owners of OpenLilyLib could me enforce to 
distribute my work (music'score) under the terms of the GPL simply by 
using this analogy. By using my explanation, you would win every trial 
in every legal area which accepted the GPL as an effective license. 
That's the risk I would have to take, if I used OpenLilyLib to ease my work.


Supplement:

Andrew Bernard asked in another mail, whether it would be "my intent to 
shut down lilypond altogether" by pointing out this license issue. He 
fears the "deleterious effect of my post", that "the users and readers 
of this list" could be "deterred from using it". He does not want to " 
see OpenLilyLib because of a complicated legal misrepresentation". 
Finally, he declared my hint "as an attempt to damage openlilylib in 
people's minds" and demanded "Really, enough now."


Once for all:

1) It was my intention to be enabled to use OpenLilyLib.

2) It is not a misinterpretation, it is the established viewpoint. 
Another 3rd. example: Due to the same reason, MariaDB has re-licensed 
its connectors under the LGPL for preventing its users from the trap of 
the GPL licensed mysql connectors.


3) Mr. Bernard did not consider the difference between the interpreting 
program and the interpreted code. That's his fault and leads to his 
misunderstandings.


4) Mr. Bernard wants to protect his work (a well understandable 
objective) and tries to protect it be declaring his disputant (me) as an 
enemy with a dishonest hidden agenda. He can do so. But he - and 
therefore: Urs, who has asked for help - has lost a potential contributor.


5) There would be a simple solution for all, for him, for me, and for 
the readers of this mailing list: he simply could add an 'including 
exception' to his licensing statement, which clearly and explicitly 
says, that including OpenLilyLib does not cause the copyleft effect to 
the including lilypond code. He would not lose anything: each 
improvement to OpenLilyLib had to be released under the terms of the GPL 
v3, too. And - as he might signal by his words in this discussion - the 
using music code remains private.


The fact, that Mr. Bernard apparently does not want to realize point 5., 
puzzles me.


I remain respectfully yours

Karsten Reincke



On 22.09.20 00:26, Carl Sorensen wrote:



[...]

What is special about OpenLilyLib that requires LilyPond music to be 
released under the GPL, when music not using OpenLilyLib does not need 
to be released under the GPL?  How does OpenLilyLib change the type of 
license required for the PDF file generated by LilyPond?

[...]


LilyPond is GPL.  If base LilyPond doesn't require music to be 
released under the terms of the GPL, why does including OpenLilyLib 
suddenly enforce those terms on the music?


[...]

Can you explain 

Re: Future of openLilyLib

[Urs Liska]

Am Dienstag, den 22.09.2020, 17:29 +1000 schrieb Andrew Bernard:
> What would the difference be should _lilypond_ use LGPL instead of
> GPL? I'm sorry, I think the OP amounts to a type of elaborate
> trolling
> of the community. Nothing needs changing.

I think so too.

> 
> This has all been gone through. I can only perceive this as an
> attempt
> to damage openlilylib in people's minds (heavens, why?). 

I will not further engage in this discussion. But I'm sure this is not
intended trolling but a sincere although misguided belief.

> Really,
> enough now.

+1

Urs
> 
> 
> Andrew
> 
> On Tue, 22 Sep 2020 at 16:40, Jacques Menu 
> wrote:
> > Hello everybody,
> > 
> > The legal subtleties of public licensing never made their way into
> > my mind, sorry for being limited…
> > What would the difference be, should openLilyLib use LGPL instead
> > of GPL?
> > 
> > 

Re: Future of openLilyLib

[Andrew Bernard]

What would the difference be should _lilypond_ use LGPL instead of
GPL? I'm sorry, I think the OP amounts to a type of elaborate trolling
of the community. Nothing needs changing.

This has all been gone through. I can only perceive this as an attempt
to damage openlilylib in people's minds (heavens, why?). Really,
enough now.


Andrew

On Tue, 22 Sep 2020 at 16:40, Jacques Menu  wrote:
>
> Hello everybody,
>
> The legal subtleties of public licensing never made their way into my mind, 
> sorry for being limited…
> What would the difference be, should openLilyLib use LGPL instead of GPL?
>
>

Re: Future of openLilyLib

[Jacques Menu]

Hello everybody,

The legal subtleties of public licensing never made their way into my mind, 
sorry for being limited… 
What would the difference be, should openLilyLib use LGPL instead of GPL?

JM

> Le 22 sept. 2020 à 02:34, Andrew Bernard  a écrit :
> 
> Karsten, despite your lengthy discourse on licensing, I am sure you
> have the wrong end of the stick here. Your unique interpretation of
> GPL in relation to lilypond is not shared by anybody as far as I know.
> Users are happily producing scores and works not subject to having to
> provide source code. It's important to point out to users and readers
> of this list that the use of openlilylib changes nothing, so that
> people are not deterred from using it - which is the potential
> deleterious effect of your post.
> 
> You are welcome to your views, but there is such a thing as holding
> incorrect views. I am not being impolite. to you, merely realistic.
> Carl has also questioned the validity of your logic, as previously. Is
> your intent to shut down lilypond altogether? It's not clear what you
> are aiming at.
> 
> I have worked on openlilylib with Urs and it would be a tragedy to see
> it sink because of a complicated legal misrepresentation put about. I
> am fully aware of the previous debate about this matter.
> 
> I thought long before making a post as it may offend you, but that is
> not the intention, and I have been polite. But as someone dedicated to
> the long term success of openlilylib and indeed lilypond, this sort of
> seeding doubt about complex copyright issues can do little to advance
> the cause, and I fear, undermine it in people that you may influence.
> 
> I have worked with GPL for decades or however long it has been around
> in software development, and I have never seen this argument raised in
> relation to applications.
> 
> Andrew
> 

Re: Future of openLilyLib

[Andrew Bernard]

Karsten, despite your lengthy discourse on licensing, I am sure you
have the wrong end of the stick here. Your unique interpretation of
GPL in relation to lilypond is not shared by anybody as far as I know.
Users are happily producing scores and works not subject to having to
provide source code. It's important to point out to users and readers
of this list that the use of openlilylib changes nothing, so that
people are not deterred from using it - which is the potential
deleterious effect of your post.

You are welcome to your views, but there is such a thing as holding
incorrect views. I am not being impolite. to you, merely realistic.
Carl has also questioned the validity of your logic, as previously. Is
your intent to shut down lilypond altogether? It's not clear what you
are aiming at.

I have worked on openlilylib with Urs and it would be a tragedy to see
it sink because of a complicated legal misrepresentation put about. I
am fully aware of the previous debate about this matter.

I thought long before making a post as it may offend you, but that is
not the intention, and I have been polite. But as someone dedicated to
the long term success of openlilylib and indeed lilypond, this sort of
seeding doubt about complex copyright issues can do little to advance
the cause, and I fear, undermine it in people that you may influence.

I have worked with GPL for decades or however long it has been around
in software development, and I have never seen this argument raised in
relation to applications.

Andrew

Re: Future of openLilyLib

[Carl Sorensen]

On Mon, Sep 21, 2020 at 4:00 PM Karsten Reincke  wrote


>
> We had this discussion a year ago and I won't repeat the details. The
> last time it ended in a kind of unfruitful shitstorm which did not help
> anyone. But if you now look for supporters, you have to see that your
> license model reduces the list of candidates: They must be familiar with
> music, they must love beautifully designed musical text, they must be
> able to program scheme (LISP) code (in fact not the most widely used
> programming language) and they must be willing to require the others to
> distribute their music under the terms of the GPL.
>

What is special about OpenLilyLib that requires LilyPond music to be
released under the GPL, when music not using OpenLilyLib does not need to
be released under the GPL?  How does OpenLilyLib change the type of license
required for the PDF file generated by LilyPond?


> Nearly all other GPL licensed programming libs/programs had the same
> problem and found solutions. Linus invented the "explicit syscall
> exception" for his kernel, openjdk was released under the "GPL with
> classpath exception". That is why I would like to propose again to
> re-license the OpenLilyLib under the terms of the LGPL. Or, if that is
> not possible, to link the lib with a kind of an "include exception" with
> the purpose, to explicitly prevent the including musical scores  from
> also having to be released under the terms of the GPL.
>

LilyPond is GPL.  If base LilyPond doesn't require music to be released
under the terms of the GPL, why does including OpenLilyLib suddenly enforce
those terms on the music?

I'm not trying to cause problems.   I just don't understand how  including
OpenLilyLib in your LilyPond music file suddenly changes the license terms.

Can you explain that to me?

Thanks,

Carl

>
>

Re: Future of openLilyLib

[Karsten Reincke]

Dear Urs;

I gratefully appreciate your work on LilyPond. Because of your friendly 
and affectionate way of sharing your knowledge in this mailing list - as 
I was allowed to experience it in the past - I also want to believe that 
OpenLilylib is valuable. Personally, I refrained from familiarizing 
myself with it. The reason was not, that I indeed could not quickly 
activate a 'Hello-World' "song". Even higher entry thresholds usually do 
not prevent me from diving into special areas of programming. The reason 
I ended up putting OpenLilyLib aside was its license model.


OpenLilyLib is licensed under the GPL. Thus, the copyleft effect forces 
that all Lilypond files which include OpenLilyLib files, have also to be 
distributed under the terms of the GPL. Moreover, due to the fact, that 
Lilypond is the source code, which will be compiled (into scores), one 
also has to respect the GPL rules of distributing compiled versions of 
the code.


We had this discussion a year ago and I won't repeat the details. The 
last time it ended in a kind of unfruitful shitstorm which did not help 
anyone. But if you now look for supporters, you have to see that your 
license model reduces the list of candidates: They must be familiar with 
music, they must love beautifully designed musical text, they must be 
able to program scheme (LISP) code (in fact not the most widely used 
programming language) and they must be willing to require the others to 
distribute their music under the terms of the GPL.


Nearly all other GPL licensed programming libs/programs had the same 
problem and found solutions. Linus invented the "explicit syscall 
exception" for his kernel, openjdk was released under the "GPL with 
classpath exception". That is why I would like to propose again to 
re-license the OpenLilyLib under the terms of the LGPL. Or, if that is 
not possible, to link the lib with a kind of an "include exception" with 
the purpose, to explicitly prevent the including musical scores  from 
also having to be released under the terms of the GPL.


I think that such a clarification would invite collaborators. At least I 
would definitely consider, to transfer my harmoni.ly into OpenLilyLib - 
as soon as such a re-licensing has reliably been implemented (= agreed 
by all copyright holders) .


with best regards and  - again - many thanks for your work in the past

Karsten


On 21.09.20 17:24, Urs Liska wrote:

Hi all,

...

I can understand why this view is not shared by everyone, most likely
simply because too much about OLL is obscure or unknown,...

At this point openLilyLib is completely dependent on my availability,
...
Therefore I'm looking not for a new maintainer but for more people
engaging in the project, to build a community around it that can at
some point continue without my aid.

...
Best
Urs



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

Future of openLilyLib

[Urs Liska]

Hi all,

to begin with, I am of the (biased) opinion that openLilyLib is a
powerful and useful extension infrastructure for LilyPond. There are a
number of versatile and extended ready-to-use packages available, most
notably probably edition-engraver, scholarLY and anaLYsis. But also the
underlying oll-core is versatile and powerful, providing numerous
building blocks without which I would not start any large-scale project
anymore.

I can understand why this view is not shared by everyone, most likely
simply because too much about OLL is obscure or unknown, lacking proper
documentation, although the general introduction at https://openlilylib
.org should be a good start (and there are substantial manuals for the
scholarLY and stylesheets packages, but only in (undocumentedly) self-
compilable form).

At this point openLilyLib is completely dependent on my availability,
at least because I am the only person with knowledge of the basic code
in oll-core. 

For several reasons which I won't discuss publicly I will have to
reduce my availablity to work on openLilyLib (and other stuff) and may
be forced to completely withdraw at any point within the next years.

I would find it a pity if that would mean the end for openLilyLib.
Therefore I'm looking not for a new maintainer but for more people
engaging in the project, to build a community around it that can at
some point continue without my aid.

The aspects needing support most urgently AFAICT are (in descending
order):

 * getting more people familiar with oll-core (using the opportunity to
   maybe improve the coding where appropriate)
 * complete the documentation system in order to make a more complete
   documentation feasible (here the most crucial part is integrating
   consistently scalable score examples in the web site output).
 * getting more people familiar with the coding of scholarLY
 * do maintenance of everything, maybe throwing out some less-than-
   useful packages
 * write a Frescobaldi extension for managing (installing, updating the
   library or individual packages, preparing documents) openLilyLib and
   providing an API for secondary extensions (e.g. an annotation
   editor/viewer or a tool to graphically insert editionMods).

If anything of this looks like your cup of tea you are welcome to
contact me privately or discuss stuff on-list. Of course I am more than
willing to help with any of these tasks.

Best
Urs