Re: Copyright/licensing action plan + a sample [PATCH]
On Sun, Sep 20, 2009 at 01:46:56AM +0200, Reinhold Kainhofer wrote: > Am Samstag, 19. September 2009 20:18:14 schrieb Joseph Wakeling: > > Guile I think is LGPLv3 although parts may be GPL -- but that's only for > > the current development release (i.e. 1.9.x). 1.8.x is still under > > LGPLv2+. > > Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond can't use > guile any more, because LGPLv3 is not compatible with GPLv2... So, lilypond > then has to switch to GPLv3... No, that's nonsense. Guile 1.8.7 was still released under LGPLv2, so we simply continue to link to that in GUB. If somebody compiles lilypond from the source and links to guile 1.9 or 2.0, then that's *their* problem. We're not distributing those versions. Now, at some point, there will be some important bug fix or new feature in guile 1.9, which is only published under v3. *Then* we'd have problems... but wait! If guile is truly under LGPL, and not GPL, then there should be no problems. I mean, if you can link to closed-source apps (the whole point of LGPL), then surely a mere GPLv2 app can still link to the library? ** please note the above was not an informed opinion. It would be nice if somebody looked into all these reasons, in a calm and collected way, so that we could see exactly which libraries might "force" us to use GPLv3, which version numbers this started at. > But then we have a problem with freetype, which > is FTL (BSD with advertising clause, thus incompatible with GPL) or GPLv2 > only... I don't think there's any problem with linking to a BSD library. ** please note that I don't really know what freetype does, or if it's actually a library at all. *** NB: I know that the FSF has a different definition of "linking" than other people (i.e. BSD guys), so this would also be worth looking into. Fundamentally, the current discussion is too shrill, with too many semi-informed people (no offense to anybody) making dire predictions and proclaiming that lilypond _must_ do X, Y, and Z. 1) The first step is to gather information about the licensing requirements for any external projects we use. Pay particular attention to the *actual* requirements, i.e. not just "we include project X in GUB, so we must foo" or "project Y has a 3 in the license name, so we must use GPLv3". 2) The next step is to consider whether any change needs to be made at all. I'm pretty certain that right now, everything is kosher. 3) If any change might be desirable in the future (for example, Guile -- *if* guile wasn't LGPL), then we can begin looking at which developers consent to such a change. 4) If anybody can't be reached or doesn't consent, *then* we look at exactly what that person wrote, and either abandon the change idea (knowing exactly what that entails as far as using libraries or finding replacement libraries), or rewrite their constributions. Starting with step 4 is just silly. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 20. September 2009 09:10:20 schrieb Graham Percival: > On Sun, Sep 20, 2009 at 01:46:56AM +0200, Reinhold Kainhofer wrote: > > Am Samstag, 19. September 2009 20:18:14 schrieb Joseph Wakeling: > > > Guile I think is LGPLv3 although parts may be GPL -- but that's only > > > for the current development release (i.e. 1.9.x). 1.8.x is still under > > > LGPLv2+. > > > > Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond can't > > use guile any more, because LGPLv3 is not compatible with GPLv2... So, > > lilypond then has to switch to GPLv3... > > No, that's nonsense. Guile 1.8.7 was still released under LGPLv2, > so we simply continue to link to that in GUB. > > If somebody compiles lilypond from the source and links to guile > 1.9 or 2.0, then that's *their* problem. We're not distributing > those versions. Putting your head into the sand isn't going to solve the problem. After all, every distribution compiles from source and distributes those versions. You can't seriously expect all distributions to change their build system just for lilypond. > Now, at some point, there will be some important bug fix or new > feature in guile 1.9, which is only published under v3. *Then* > we'd have problems... but wait! If guile is truly under LGPL, and > not GPL, then there should be no problems. I mean, if you can > link to closed-source apps (the whole point of LGPL), then surely > a mere GPLv2 app can still link to the library? No, because LGPL has additional restrictions. The problem is not that we would be violating guile's license, but lilypond's license does not allow linking to a LGPLv3 library. So basically, you are telling all package maintainers of all distributions to violate the copyright of all lilypond contributors. > It would be nice if somebody looked into all these reasons, in a > calm and collected way, so that we could see exactly which > libraries might "force" us to use GPLv3, which version numbers > this started at. It is our own restrictive license, where the lilypond developers have practically been saying (by licensing as GPLv2only) that they don't want lilypond to link to any (L)GPLv3 libraries. > > But then we have a problem with freetype, which > > is FTL (BSD with advertising clause, thus incompatible with GPL) or GPLv2 > > only... > > I don't think there's any problem with linking to a BSD library. It's BSD WITH advertising clause (three-clause version!), which is not compatible with GPL. It is not the two-clause version, which is compatible with the GPL. > 2) The next step is to consider whether any change needs to be > made at all. I'm pretty certain that right now, everything is > kosher. So far, I couldn't find a problem, either. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKtdkiTqjEwhXvPN0RAnCyAJ0VAGRo+sfd+HHNYE/dgPFCNBhDSgCfQm48 SnlzFZsUK52n3+796UNuNmo= =5xVv -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
On Sun, Sep 20, 2009 at 09:26:25AM +0200, Reinhold Kainhofer wrote: > Am Sonntag, 20. September 2009 09:10:20 schrieb Graham Percival: > > > Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond can't > > > use guile any more, because LGPLv3 is not compatible with GPLv2... So, > > > lilypond then has to switch to GPLv3... > > > > No, that's nonsense. Guile 1.8.7 was still released under LGPLv2, > > so we simply continue to link to that in GUB. > > > > If somebody compiles lilypond from the source and links to guile > > 1.9 or 2.0, then that's *their* problem. We're not distributing > > those versions. > > Putting your head into the sand isn't going to solve the problem. After all, > every distribution compiles from source and distributes those versions. You > can't seriously expect all distributions to change their build system just > for > lilypond. I'm not putting my head in the sand. Distributions can take care of themselves. Now, when guile 2.0 comes out as LGPLv3, I'm sure that distributions would *like* us to switch to GPLv3. I'm not saying that we shouldn't *consider* switching. In fact, I'll go so far as to say that it would be *nice and polite* for us to switch. However, it is false to say that "lilypond can't use guile any more". We *can* still use it (albeit an older version), and I'm not going to panic just because not switch would make redhat's job harder. We will switch after serious consideration, at a time that is convenient for us. Please note that I'm confident that ultimately we _will_ switch. But I -- and certain other developers -- disgusted by the shrill claims that we MUST do X, especially when it turns out that there is no such legal necessity at all. > > Now, at some point, there will be some important bug fix or new > > feature in guile 1.9, which is only published under v3. *Then* > > we'd have problems... but wait! If guile is truly under LGPL, and > > not GPL, then there should be no problems. I mean, if you can > > link to closed-source apps (the whole point of LGPL), then surely > > a mere GPLv2 app can still link to the library? > > No, because LGPL has additional restrictions. The problem is not that we > would > be violating guile's license, but lilypond's license does not allow linking > to > a LGPLv3 library. So basically, you are telling all package maintainers of > all > distributions to violate the copyright of all lilypond contributors. No, I am not telling them to do that. I am saying that, if guile 2.0 comes out and we have not switched, they should link to guile-1.8 if they want to legally distribute lilypond. Perhaps there is a problem of language here -- the word "must" is very strong in English. For example, "if x is greater than 5, then it must be greater than 4". "must" means that there is no possibility of an alternate option. In the case of linking to a specific verison number of a library, I agree that it would be quite inconvenient. But "quite inconenient" is not the same thing as "impossible". So therefore, the word "must" is incorrect. I'd also like more details about the GPLv2 linking to LGPLv3 library issue. > > It would be nice if somebody looked into all these reasons, in a > > calm and collected way, so that we could see exactly which > > libraries might "force" us to use GPLv3, which version numbers > > this started at. > > It is our own restrictive license, where the lilypond developers have > practically been saying (by licensing as GPLv2only) that they don't want > lilypond to link to any (L)GPLv3 libraries. Nobody has said that they "don't want" lilypond to link to LGPLv3. If there is a solid legal reason why GPLv2 cannot link to a LGPLv3 license, please state it clearly. I am not arguing that there *isn't* such a solid legal reason; I have not spent an hour reading those licenses recently. But at the same time, I am not aware of any such reason. > > > But then we have a problem with freetype, which > > > is FTL (BSD with advertising clause, thus incompatible with GPL) or GPLv2 > > > only... > > > > I don't think there's any problem with linking to a BSD library. > > It's BSD WITH advertising clause (three-clause version!), which is not > compatible with GPL. It is not the two-clause version, which is compatible > with the GPL. I think you mean "four-clause version", but agreed. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 07:45:46PM +0100, Anthony W. Youngman wrote: > In message <1253377160.11679.1824.ca...@localhost>, John Mandereau > writes >> On the opposite, note that snippets from LSR are public domain, not FDL. > > Aarrgghh. > > The snippets are [insert incorrect information here] Ahh, sweet irony. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 11:28:11PM +0100, Anthony W. Youngman wrote: > >The snippets are taken from the LSR and a condition of submission to the > >LSR is that you consign your work to the public domain (and that you > >have the right to do so). I know, because I submitted a couple of > >snippets to the LSR and they later made it into the Lilypond docs' > >selection of snippets. > > What happens if you're German :-) > > (I don't know, but there's been a fair bit of discussion, on and off, on > debian legal as to whether it is even *possible* for some people to > consign their work to the public domain - the *law* apparently says they > *can't*) "public domain" in germany (and maybe other european countries) doesn't exist in the sense that an author can't drop authorship and decline all responsibility for his work. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB - Failed target: darwin-x86::cross/gcc
Op donderdag 17-09-2009 om 18:19 uur [tijdzone -0700], schreef Patrick McCarty: > Doing a "make -f lilypond.make bootstrap", GUB halts at > darwin-x86::cross/gcc. Could you look into that? > The end of the build.log is attached. Could you look into that? I cannot reproduce this. Greetings Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Reinhold Kainhofer wrote: > Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond can't use > guile any more, because LGPLv3 is not compatible with GPLv2... So, lilypond > then has to switch to GPLv3... But then we have a problem with freetype, > which > is FTL (BSD with advertising clause, thus incompatible with GPL) or GPLv2 > only... Argh. I wasn't aware of the LGPLv3/GPLv2 incompatibility until now. That's nasty. :-( > I really love it how FSF handles the GPL purely for political reasons... > (Which might make sense from an abstract viewpoint, but in daily developer > life that is just counterproductive and hindering productive development!) > > To be honest, as an open source developer, I'm really starting disliking the > GPL, simply for practical reasons. Well, they are a political organisation. They aren't there to make your life as a developer easy -- and if you follow their practical advice, you don't end up in these situations. (They are also generally pretty good about taking into account the practical issues that will be raised by any licensing change, and trying to minimise them.) >> That was one of the motivations for tracking who was OK with GPLv2+ -- >> to have an advance list of people ready for such an eventuality. > > See e.g. what KDE did a while ago: > http://techbase.kde.org/Projects/KDE_Relicensing > > I propose we also keep such a list (publicly available) about what the devs > allow with regards to their licenses. I am already doing so, although not as detailed as KDE's. http://spreadsheets.google.com/ccc?key=0AkXkBLpoZm-_dHdkUUZRRVJvX2ZHWVpOeloyTU00SHc&hl=en It's on Sheet 2 :-) Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 20. September 2009 10:11:54 schrieb Graham Percival: > > No, because LGPL has additional restrictions. The problem is not that we > > would be violating guile's license, but lilypond's license does not allow > > linking to a LGPLv3 library. So basically, you are telling all package > > maintainers of all distributions to violate the copyright of all lilypond > > contributors. > > No, I am not telling them to do that. I am saying that, if guile > 2.0 comes out and we have not switched, they should link to > guile-1.8 if they want to legally distribute lilypond. Okay, and what do you think will happen in reality? I don't think distributions will be willing to spend time and resources on providing outdated software/libraries, simply because lilypond wants old versions. I'd rather say lilypond will be dropped instead, citing licensing issues with lilypond. > Perhaps there is a problem of language here -- the word "must" is > very strong in English. For example, "if x is greater than 5, > then it must be greater than 4". "must" means that there is no > possibility of an alternate option. What I didn't write down, but implicitly assumed was the half-sentence "if we/they want to use the current, installed library versions". Then it is a MUST. > I'd also like more details about the GPLv2 linking to LGPLv3 > library issue. [...] > > It is our own restrictive license, where the lilypond developers have > > practically been saying (by licensing as GPLv2only) that they don't want > > lilypond to link to any (L)GPLv3 libraries. > > Nobody has said that they "don't want" lilypond to link to LGPLv3. > If there is a solid legal reason why GPLv2 cannot link to a LGPLv3 > license, please state it clearly. See: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility > I am not arguing that there *isn't* such a solid legal reason; I > have not spent an hour reading those licenses recently. But at > the same time, I am not aware of any such reason. The LGPLv3 also includes the patents clause and the anti-DRM clause, which both add additional restrictions, which the GPLv2 does not have. On the other hand, all lilypond contributors -- by putting their code under GPLv2only -- explicitly say that they do not agree to any additional restrictions. Thus lilypond can't link to any (L)GPLv3 library, which would add additional restrictions. > > > > But then we have a problem with freetype, which > > > > is FTL (BSD with advertising clause, thus incompatible with GPL) or > > > > GPLv2 only... > > > > > > I don't think there's any problem with linking to a BSD library. > > > > It's BSD WITH advertising clause (three-clause version!), which is not > > compatible with GPL. It is not the two-clause version, which is > > compatible with the GPL. > > I think you mean "four-clause version", but agreed. Of course. OTOH, the FTL is not the BSD, as my mail might suggest (sorry for the confusion). It is rather a completely different license containing some attribution clause, making it incompatible with GPLv2 (for the same reasons as the 4-clause BSD lisense). But apparently it is compatible with GPLv3, so we don't have any problems with FT, should we switch to GPLv3. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKthNXTqjEwhXvPN0RAlA7AJ4utIuEPYxPKZpiSB0E5a1UOpgJaQCgia3a n6IcEl3i2R096PIfM3SQOBo= =9/rh -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Hi Carl,
That will work, but it's still a work-around. We'd be avoiding setting
it as a context property to keep the architectural thinking clean, while
at the same time duplicating the functionality of a property by hand.
What we're in effect doing here is duplicating the behaviour of a
property, we're hiding the parser variable and writing a function to
write to it. So why not
pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable?
string?)
(set! parser-variable new-value)
(make-music 'SequentialMusic 'void #t))
then do
\book {
\pvset output-suffix "gibbon-vole-aardvark"
{... \score blocks and things ...}
}
But I'm still bothered we may be re-inventing the wheel here. We've got
properties in lily already, and defined ways of setting them (\set,
\override and even assigning them in the relevant block).
Could we not add a new define-parser-variable-properties.scm with
(define-public all-pv-properties '())
(define (pv-property-description symbol type? description)
(if (not (and
(symbol? symbol)
(procedure? type?)
(string? description)))
(throw 'init-format-error))
(if (not (equal? #f (object-property symbol 'translation-doc)))
(ly:error (_ "symbol ~S redefined" symbol)))
(set-object-property! symbol 'translation-type? type?)
(set-object-property! symbol 'translation-doc description)
(set! all-pv-properties (cons symbol all-translation-properties))
symbol)
(define-public all-pv-properties
(map
(lambda (x)
(apply pv-property-description x))
`(
(output-suffix ,string? "Text to append to the output
filename for the current @code{\\book} block")
;;; Maybe add all the other supported parser variables here?
)))
The above should work as I've adapted it unashamedly from
define-context-properties.scm
Remaining things to do would be
* add define-parser-variable-properties.scm to build /(whimper...)/
* get the property access routines to use the new all-pv-properties list
This would be more work, but give us a cleaner result and it would be
less likely to fall foul of a fatwah from new Syntax Standardization
project when it gets going.
Opinions?
Cheers,
Ian
Carl Sorensen wrote:
On 9/19/09 7:27 AM, "Ian Hulin" wrote:
Hi Carl, Neil,
I'm quite happy to re-think the proposal if what I have in mind contravenes
existing design architecture.
Put it down to relative inexperience and the fact I don't get opportunity to
work on lilly as often as I'd like.
Anyhow, here are some of the reasons why I'd like to do something with this
stuff:
* Using parser variables to configure things is evil, because it requires
users to drop into Scheme to set the parser variable. I feel we need to
replace #(define output-suffix "gibbon-vole-aardvark") with something handled
at the lilypond language level.
*
* At the moment, output-suffix is de facto a property of a \book block.� There
is a design assumption (informal club rule) in lilypond� that we only produce
one back-end output file (.pdf, .png whatever) per \book block.
* However, there is as great big exception to this in the form of midi files,
one of which one is output for every \score block with a \midi present. At the
moment the file name generation code kludges its way around this but it not
very clean, unclear and all this stuff is barely documented.
* So what I'd like to do is to have some way of replacing the Scheme
definition either -
* \book {
* ��� \set output-suffix "gibbon-vole-aardvark"
* ��� {... \score blocks and things}
* }
* , or
* \book \with {output-suffix = "gibbon-vole-aardvark"}
* {
* �� {... \score blocks and things}
* }.
Could one define a void music function
setOutputSuffix =
#(define-music-function (parser layout new-output-suffix) (string?)
(define output-suffix new-output-suffix)
(make-music 'SequentialMusic 'void #t))
then do
\book {
\setOutputSuffix "gibbon-vole-aardvark"
{... \score blocks and things ...}
}
I haven't tried it, but I think it may work.
Carl
---
Join the Frogs!
__
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Licensing dependencies
Have had a look through the licenses of dependencies as listed in the Contributor's Guide. It looks like the problems are FreeType (GPLv2 only or GPL-incompatible permissive license, so blocks upgrade); Guile (future versions will be LGPLv3+, so GPLv2-only-incompatible); and potentially Pango (if it upgrades to LGPLv3+). None are a present, active problem but all are clear risks. Best wishes, -- Joe --- Running requirements: FreeType: FreeType license (GPL-incompatible due to advert clause) or GPLv2 only FontConfig: Permissive license, seems to be GPL-compatible (it's pretty much identical to the advertising-clause-free version of the BSD license; if there is anything wrong we're as buggered with GPLv2 as 3+). http://cgit.freedesktop.org/fontconfig/tree/COPYING Pango: Development version downloaded from Git is LGPLv2+. Guile: as already discussed, 1.8.x is LGPLv2+. Development version (1.9.x) is LGPLv3+. Python: GPL-compatible: see, http://www.python.org/download/releases/2.6/license/ Ghostscript: GPLv3+, but LP doesn't link to it, so it's OK. Dejaview: can't find any info on this, what is its provenance? Build requirements: FontForge: new BSD license (i.e. GPL-compatible) Metafont: seems a bit weird and uncertain (TeX licenses, some GPL) but this is just called, not linked to, no? t1utils: permissive license, seems GPL-compatible Guile: see above Texinfo: GPLv3+, but we only call it, don't link (?) g++: GPLv3+, but we only call it Python: see above GNU Make: GPLv3+, but we only call it Gettext: GPLv3+, but we only call it Flex: new BSD license (GPL-compatible) Perl: Artistic License/GPLv1 (!) but seems to be OK as we only call it and don't link. GNU Bison: GPLv3+, but we only call it Doc build requirements: texi2html: GPLv2+ (we only call it anyway) netpbm: seems horribly complicated, but we only call it imagemagick: own license, claims GPL compatibility (but we only call it in any case) rsync: GPLv3+, but we only call it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Licensing dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 20. September 2009 13:46:32 schrieb Joseph Wakeling: > It looks like the problems are FreeType (GPLv2 only or GPL-incompatible > permissive license, so blocks upgrade); The FTL is GPLv2-incompatible, but according to the FSF, it's GPLv3- compatible... See http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses No blocker here. > Guile (future versions will be > LGPLv3+, so GPLv2-only-incompatible); and potentially Pango (if it > upgrades to LGPLv3+). > > None are a present, active problem but all are clear risks. Yes, that's the only possible license issue in the future that I can see. Everything else appears okay... >Python: GPL-compatible: see, >http://www.python.org/download/releases/2.6/license/ We don't link anyway. >Dejaview: can't find any info on this, what is its provenance? It appears only in the compiling instructions for FreeBSD. I don't think we link to it. From the description it seems that dejaview simply makes the FBSD fonts available to lilypond (at least that's what the CG says). >FontForge: new BSD license (i.e. GPL-compatible) We don't link, just call. >Metafont: seems a bit weird and uncertain (TeX licenses, some GPL) > but this is just called, not linked to, no? yes, we just call mf or mf-win >Texinfo: GPLv3+, but we only call it, don't link (?) exactly. >GNU Bison: GPLv3+, but we only call it The code it puts in the output file (which is linked into lilypond) is GPLv2+ with additional exception to use for any larger work (except other parser generators). Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKthyxTqjEwhXvPN0RApwYAJ9jMFfk6BA5Q0Gw4XYYP70d8HGaMQCgnBgc vsBSTYY+sZ2c9rzAT6tNr1U= =A/jV -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On 9/20/09 5:40 AM, "Ian Hulin" wrote:
> Hi Carl,
> That will work, but it's still a work-around. We'd be avoiding setting it as
> a context property to keep the architectural thinking clean, while at the same
> time duplicating the functionality of a property by hand.
OK, I guess I agree with what you said.
> What we're in effect doing here is duplicating the behaviour of a property,
> we're hiding the parser variable and writing a function to write to it. So why
> not
>
> pvSet =
> #(define-music-function (parser layout parser-variable new-value) (variable?
> string?)
> (set! parser-variable new-value)
> (make-music 'SequentialMusic 'void #t))
>
> then do
>
> \book {
>\pvset output-suffix "gibbon-vole-aardvark"
>{... \score blocks and things ...}
> }
Yes, this is more general than my suggestion.
> But I'm still bothered we may be re-inventing the wheel here. We've got
> properties in lily already, and defined ways of setting them (\set, \override
> and even assigning them in the relevant block).
>
> Could we not add a new define-parser-variable-properties.scm with
> (define-public all-pv-properties '())
> (define (pv-property-description symbol type? description)
> (if (not (and
> (symbol? symbol)
> (procedure? type?)
> (string? description)))
> (throw 'init-format-error))
>
>
> (if (not (equal? #f (object-property symbol 'translation-doc)))
> (ly:error (_ "symbol ~S redefined" symbol)))
>
> (set-object-property! symbol 'translation-type? type?)
> (set-object-property! symbol 'translation-doc description)
> (set! all-pv-properties (cons symbol all-translation-properties))
> symbol)
> (define-public all-pv-properties
> (map
> (lambda (x)
> (apply pv-property-description x))
> `(
> (output-suffix ,string? "Text to append to the output filename
> for the current @code{\\book} block")
> ;;; Maybe add all the other supported parser variables here?
>
> )))
>
> The above should work as I've adapted it unashamedly from
> define-context-properties.scm
This seems like a good idea to me. However, I'm not really strong on parser
variables. But if this does work, I think it would be an improved way of
handling point-and-click, because, as you say, it would tie into the
existing LilyPond syntax.
>
> Remaining things to do would be
> * add define-parser-variable-properties.scm to build (whimper...)
No (whimper...) needed here; this is trivial to do. Just add an entry to
scm/lily.scm.
> * get the property access routines to use the new all-pv-properties list
I'm not sure I have this vision. How would \set know whether to set a
context property or a pv property?
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Similarly, the validity of "This work is released by me, the author, into the public domain" in the US is under debate, because US law allows authors to retain the right to redact licenses to their copyright works. There is an argument that the moment you put something in the PD, you lose the redaction right. There is also an argument that the redaction right cannot be waived. So really, it is impossible as Valentin points out. But in practice, there is clear intent when you say "public domain" and I doubt any judge would rule against someone who used such a work. -Travis On Sun, Sep 20, 2009 at 4:36 AM, Matthias Kilian wrote: > On Sat, Sep 19, 2009 at 11:28:11PM +0100, Anthony W. Youngman wrote: >> >The snippets are taken from the LSR and a condition of submission to the >> >LSR is that you consign your work to the public domain (and that you >> >have the right to do so). I know, because I submitted a couple of >> >snippets to the LSR and they later made it into the Lilypond docs' >> >selection of snippets. >> >> What happens if you're German :-) >> >> (I don't know, but there's been a fair bit of discussion, on and off, on >> debian legal as to whether it is even *possible* for some people to >> consign their work to the public domain - the *law* apparently says they >> *can't*) > > "public domain" in germany (and maybe other european countries) > doesn't exist in the sense that an author can't drop authorship and > decline all responsibility for his work. > > Ciao, > Kili > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] COPYING rewrite to clarify licensing
Following the earlier discussion with Graham and others, this patch slightly rewrites the COPYING file to clarify the Lilypond licensing situation. It might also be sensible to add a line mentioning that docs are released under GFDL, and a separate COPYING.DOCUMENTATION file that contains that license. Best wishes, -- Joe From d1ee19e7d7dd10d0504ebec2a621d675087f0f70 Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Sun, 20 Sep 2009 15:58:09 +0200 Subject: [PATCH] COPYING rewrite to clarify licensing. * Text is closer to FSF guidelines and explicitly states that Lilypond is released under GPLv2 only. --- COPYING | 38 -- 1 files changed, 20 insertions(+), 18 deletions(-) diff --git a/COPYING b/COPYING index 3ad0007..da2d00d 100644 --- a/COPYING +++ b/COPYING @@ -1,21 +1,23 @@ -If you want to redistribute LilyPond, you must comply with the GNU -General Public License (reproduced below). This license applies to -LilyPond with the following exceptions: - -- It does not apply to example input files (which are in -the subdirectory input/) that explicitly specify another license. - -- If you create a document which uses fonts included in LilyPond, and -embed this font or unaltered portions of this font into the document, -then this font does not by itself cause the resulting document to be -covered by the GNU General Public License. This exception does not -however invalidate any other reasons why the document might be covered -by the GNU General Public License. If you modify this font, you may -extend this exception to your version of the font, but you are not -obligated to do so. If you do not wish to do so, delete this exception -statement from your version. - - +GNU Lilypond is free software; you can redistribute it and/or modify +it under the terms of version 2 of the GNU General Public License as +published by the Free Software Foundation. A copy of the license is +contained in this file. + +The following exceptions are granted to this license: + + -- It does not apply to example input files (contained in the +subdirectory input/) that explicitly specify another license. + + -- If you create a document which uses fonts included in Lilypond, +and embed this font or unaltered portions of this font into the +document, then this font does not by itself cause the resulting +document to be covered by the GNU General Public License. This +exception does not however invalidate any other reasons why the +document might be covered by the GNU General Public License. +If you modify one or more of the fonts, you may extend this +exception to your version of the fonts but you are not obliged +to do so. If you do not wish to do so, delete this exception +statement from your version. GNU GENERAL PUBLIC LICENSE -- 1.6.3.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Licensing dependencies
Reinhold Kainhofer wrote: > Am Sonntag, 20. September 2009 13:46:32 schrieb Joseph Wakeling: >> It looks like the problems are FreeType (GPLv2 only or GPL-incompatible >> permissive license, so blocks upgrade); > > The FTL is GPLv2-incompatible, but according to the FSF, it's GPLv3- > compatible... See > http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses > No blocker here. Oh, great. Missed that when reading the compatible license list. >> Guile (future versions will be >> LGPLv3+, so GPLv2-only-incompatible); and potentially Pango (if it >> upgrades to LGPLv3+). > >> None are a present, active problem but all are clear risks. > > Yes, that's the only possible license issue in the future that I can see. > Everything else appears okay... So, the upshot is that, while not an absolute necessity, it would be highly convenient to gain GPLv3 compatibility. If there are no objections I will continue to track contributors and ask for their licensing preferences -- specifically, what is the most permissive license they are willing to permit (i.e. GPLv2/3, GPLv2+, BSD-style, etc.) -- and record in the publicly-viewable Google Doc mentioned previously. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Carl Sorensen wrote:
On 9/20/09 5:40 AM, "Ian Hulin" wrote:
Hi Carl,
That will work, but it's still a work-around.� We'd be avoiding setting it as
a context property to keep the architectural thinking clean, while at the same
time duplicating the functionality of a property by hand.
OK, I guess I agree with what you said.
What we're in effect doing here is duplicating the behaviour of a property,
we're hiding the parser variable and writing a function to write to it. So why
not
pvSet =
#(define-music-function (parser layout parser-variable new-value) (variable?
string?)
(set! parser-variable new-value)
(make-music 'SequentialMusic 'void #t))
then do
\book {
\pvset output-suffix "gibbon-vole-aardvark"
{... \score blocks and things ...}
}
Yes, this is more general than my suggestion.
But I'm still bothered we may be re-inventing the wheel here.� We've got
properties in lily already, and defined ways of setting them (\set, \override
and even assigning them in the relevant block).
Could we not add a new define-parser-variable-properties.scm with
(define-public all-pv-properties '())
(define (pv-property-description symbol type? description)
(if (not (and
(symbol? symbol)
(procedure? type?)
(string? description)))
(throw 'init-format-error))
(if (not (equal? #f (object-property symbol 'translation-doc)))
(ly:error (_ "symbol ~S redefined" symbol)))
(set-object-property! symbol 'translation-type? type?)
(set-object-property! symbol 'translation-doc description)
(set! all-pv-properties (cons symbol all-translation-properties))
symbol)
(define-public all-pv-properties
(map
(lambda (x)
(apply pv-property-description x))
`(
(output-suffix ,string? "Text to append to the output filename
for the current @code{\\book} block")
;;; Maybe add all the other supported parser variables here?
)))
The above should work as I've adapted it unashamedly from
define-context-properties.scm
This seems like a good idea to me. However, I'm not really strong on parser
variables. But if this does work, I think it would be an improved way of
handling point-and-click, because, as you say, it would tie into the
existing LilyPond syntax.
Remaining things to do would be
* add define-parser-variable-properties.scm to build (whimper...)
No (whimper...) needed here; this is trivial to do. Just add an entry to
scm/lily.scm.
Wouldn't I need to add a dependency to the build, too?
* get the property access routines to use the new all-pv-properties list
I'm not sure I have this vision. How would \set know whether to set a
context property or a pv property?
Presumably the same way it decides whether to access a context property,
music property, or grob property currently.
That's something I'll have to dig into. I was sort of assuming the \set
code did a lookup of available property lists, I'll undertake further
research.
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On Sun, Sep 20, 2009 at 2:41 PM, Carl Sorensen wrote: > This seems like a good idea to me. However, I'm not really strong on parser > variables. But if this does work, I think it would be an improved way of > handling point-and-click, because, as you say, it would tie into the > existing LilyPond syntax. I could update the tracker page accordingly... Can you guys help me? :-) Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
midi2ly continued
Hi,
I have been hacking around a little bit with the midi2ly script.
Some time ago I reported a problem with tunes that were not in
3/4 time.
But as reaction I got a "sorry, midi2ly is not supported anymore"
So I decided to try a little Python hacking myself.
I found the problem was in format-1 MIDI files, where track 1 often
(always ?) contains Time and Tempo information, but no notes. And the
midi2ly script only writes out tracks if they contain notes. Result:
everything will get the default 4/4 time and the default 4=60 tempo.
Bad.
Then I started hacking.
Here's my ChangeLog:
- TrackA(time and tempo events, but no notes) and TrackB are combined
in one Staff. Time signature and Tempo are correctly used now.
- I have added some commandline options
-T --time NUM/DEN manually force a global time signature
-P --partial DURspecify an upbeat duration
--skip use invisible rests (s) for rests.
I have changed the default behaviour to
use visible rests (r)
-w --warranty The warranty message was broken. Fixed.
- I use the variable program_version in more places in the script.
For example \version is no longer written as "2.7.18" but uses the
actual program_version ("2.13.3") .
I have attached my version of midi2ly. Anyone who is interested may take
a look at it or just try it. There are still some serious problems (
like (long) notelengths that cross barlines ) but I think my version
already works a little better than the previous one.
I have just started learning Python, and am not very good with git.
Maybe someone more experienced can evaluate my version of the script,
maybe improve or correct it, and then take it to the git ?
--
Martin Tarenskeen
#!/usr/bin/python
#
# midi2ly.py -- LilyPond midi import script
#
# source file of the GNU LilyPond music typesetter
#
# (c) 1998--2009 Han-Wen Nienhuys
# Jan Nieuwenhuizen
'''
TODO:
* test on weird and unquantised midi input (lily-devel)
* update doc and manpage and translations
* simply insert clef changes whenever too many ledger lines
[to avoid tex capacity exceeded]
* do not ever quant skips
* better lyrics handling
* [see if it is feasible to] move ly-classes to library for use in
other converters, while leaving midi specific stuff here
* split notes that cross barlines, use ties
* better handling of polyphony in one staff.
* make barcheck and barcount work even after meter changes
* split midifile format-0 files into separate tracks ??
* test and debug using more, complex example MIDI files
'''
import os
import sys
"""
This generic code used for all python scripts.
The quotes are to ensure that the source .py file can still be
run as a python script, but does not include any sys.path handling.
Otherwise, the lilypond-book calls inside the build
might modify installed .pyc files.
"""
program_version = '2.13.3'
program_name = sys.argv[0]
authors = ('Jan Nieuwenhuizen ',
'Han-Wen Nienhuys ')
for d in ['/usr/share/lilypond/%s' % ( program_version ),
'/usr/lib/lilypond/%s' % ( program_version )]:
sys.path.insert (0, os.path.join (d, 'python'))
# dynamic relocation, for GUB binaries.
bindir = os.path.abspath (os.path.dirname (sys.argv[0]))
for p in ['share', 'lib']:
datadir = os.path.abspath (bindir + '/../%s/lilypond/current/python/' % p)
sys.path.insert (0, datadir)
"""
"""
import midi
import lilylib as ly
global _;_=ly._
## CONSTANTS
LINE_BELL = 60
scale_steps = [0, 2, 4, 5, 7, 9, 11]
global_options = None
clocks_per_1 = 1536
clocks_per_4 = 0
time = 0
reference_note = 0
start_quant_clocks = 0
duration_quant_clocks = 0
allowed_tuplet_clocks = []
errorport = sys.stderr
def identify ():
sys.stdout.write ('%s (GNU LilyPond) %s\n' % (program_name,
program_version))
def warranty ():
identify ()
ly.encoded_write (sys.stdout, '''
%s
%s
%s
%s
''' % ( _ ('Copyright (c) %s by') % '2001--2009',
'\n '.join (authors),
_ ('Distributed under terms of the GNU General Public License.'),
_ ('It comes with NO WARRANTY.')))
def progress (s):
ly.encoded_write (errorport, s + '\n')
def warning (s):
progress (_ ("warning: ") + s)
def error (s):
progress (_ ("error: ") + s)
raise Exception (_ ("Exiting... "))
def system (cmd, ignore_error = 0):
return ly.system (cmd, ignore_error=ignore_error)
def strip_extension (f, ext):
(p, e) = os.path.splitext (f)
if e == ext:
e = ''
return p + e
class Duration:
allowed_durs = (1, 2, 4, 8, 16, 32, 64, 128)
def __init__ (self, clocks):
self.clocks = clocks
if clocks <= 0:
self.clocks = durat
Re: midi2ly continued
On Sun, Sep 20, 2009 at 6:29 PM, Martin Tarenskeen wrote: > I have been hacking around a little bit with the midi2ly script. Hi Martin, thanks for working on that. I have opened a tracker page and marked it as "started" to keep track of your work: http://code.google.com/p/lilypond/issues/detail?id=839 If you're interested in maintaining midi2ly, I think LilyPond can greatly benefit from it. (For instance, there's a bounty on the Win midi2ly bug: http://code.google.com/p/lilypond/issues/detail?id=834 ). You might also be interested in subscribing to the unofficial mailing list I've created to discuss MIDI-related stuff: http://lists.lilynet.net/midi/ Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB-OSX 2.13.4
Thanks, modified accordingly. Cheers, - Graham On Sat, Sep 19, 2009 at 12:26:53PM -0400, Travis Briggs wrote: > The only thing I can tell is that you need to remove the part about > needing python, since (as the doc says) Python is now bundled. > > Other than that, the rest looks accurate and complete to me. > > -Travis > > On Fri, Sep 18, 2009 at 1:41 AM, Graham Percival > wrote: > > On Thu, Sep 17, 2009 at 04:42:43PM -0700, Patrick McCarty wrote: > >> On Wed, Sep 16, 2009 at 6:15 AM, Graham Percival > >> wrote: > >> > An initial version of 2.13.4, OSX-x86 version, is available at: > >> > http://lilypond.org/~graham/ > >> > > >> > It's completely untested, and it isn't the real 2.13.4 release, > >> > but it would be awesome if somebody could test it, so anybody > >> > needed it for doc building can continue and stuff. > >> > >> The binary and convert-ly seem to work fine here from both command > >> line and GUI on 10.5.6 (x86). I also tested the PPC build on this > >> machine, and the PDF-generation issue has gone away (Issue 811). > > > > Right. > > > > Now, could somebody please do what I asked, and fix the > > instructions for OSX command-line on general->Download->MacOS X ? > > > > Cheers, > > - Graham > > > > > > > > > > ___ > > lilypond-devel mailing list > > lilypond-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/lilypond-devel > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
On Sat, Sep 19, 2009 at 08:18:14PM +0200, Joseph Wakeling wrote: > Graham Percival wrote: > > There's a *ton* of other janitorial work to be done, especially by > > people who have proven that they're willing to do work (about 50% > > of people who say "hey, I want to help out" never do anything!). > > And not only that, but you're capable of using git! There's lots > > of stuff that needs doing for the new website, for example. > > OK. I have not been following those discussions closely but if you can > give me a rough todo list I will see what I can contribute in that > respect and prioritise it over any copyright work. I would have thought that http://lists.gnu.org/archive/html/lilypond-devel/2009-09/msg00438.html was right up your alley. If you're not interested, I made a post on -user in Aug when people were whining about how much they wanted to help but couldn't learn git. There were approximately 6 items that could be done without touching any source code, but nobody did any significant work on any of them. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 09:19:35PM +0200, John Mandereau wrote: > Le samedi 19 septembre 2009 à 18:34 +0100, Graham Percival a écrit : > > I'd rather not keep track of individual licenses in the source > > tree. Since he's stated that his work is in public domain, > > there'd be no problems with people extracting it for any CC stuff. > > ... err wait, are we talking about Trevor Daniels, or Trevor Baca? > > Bloody mao, we're talking about the autor of cary.ly :-) I was confused because Joseph keeps on talking about wanting to copy "code" from the documentation, and Trevor Daniels recently said "you know what? you guys are nutters. Do whatever you want with my stuff, now shut up and do work". ... ok, he didn't say that. But it would have been awesome if he *had* said that. > > HOWEVER, I'm quite willing to re-open the debate about licenses or > > relicensing or whatever -- as long as it's done at a convenient > > time. Right now is not convenient. > > Sure, so right now isn't convenient either to remove cary.ly and other > so-said problematic files. I'm fine for replacing cary.ly as soon as somebody makes a replacement. Should take about 15 minutes, which makes this Yet More Job Wherein We Spent Longer Talking About It Than It Would Take To Actually Do It (tm). ... of course, has anybody actually asked Trevor Baca if he'd be willing to put those two bars under the FDL? If he _was_ willing, it could save much gnashing of teeth. As for input/, that's waiting for the new website and build system to be read. And _that's_ on hold while I deal with GUB during university hours, and deal with this copyright garbage in non-university hours. > > where the most restrictive search pattern selects the license. > > We already stamp each snippet in Documentation/snippets "public domain", > and state it at the beginning of Snippets document, so it shows up in > PDF, Info and HTML. We could protect the first page of the document > under FDL, but would that make any sense? Good point; I'll dump something to that effect in snippets.tely. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 06:23:06PM +0200, Joseph Wakeling wrote: > Graham Percival wrote: > >>> This is fixed on the new website. > >> But not on the current one, which is still live ... :-) > > > > Patches accepted. > > I'll see what I can do. (Depending on the timeline for launch of the > new site. Not much point patching the current one if you're going to > launch the new one in a couple of weeks' time.) I'm glad you see it my way. > OK, well. Perhaps I should say 'credit on a per-file basis' rather than > licensing[1]. The reason I can see is this: if I decide I want to use a > file from Lilypond in my own piece of code, it's helpful to me to know > exactly who the authors and copyright holders are for that particular > file. With such a notice I immediately know who I have to contact if I > need/want further permissions, I know who I have to credit in my AUTHORS > file, etc. etc. But since the notices will be out of date, you'll need to look in the git log anyway. > So, I see maintaining good file-by-file contribution records as being > both helpful to Lilypond (it helps us track who did what) and courteous > to people receiving the code (it helps facilitate the process of > adapting parts of the code for other projects). Unless we have a dedicated legal secretary spending 5 hours a week maintaining such notices, they will be out of date and therefore useless. > [1] Where the licensing issue might be important is this: what if > someone forks Lilypond and adds a bunch of their own code with a > different but compatible license statement -- like GPLv2+? Huh? If somebody forks lilypond, that's their problem. > The other motivation is if there _is_ a desire to alter the license it > might be useful to be able to do this incrementally, e.g. move to (say) > GPL2+ all those files where the authors give permission as soon as that > permission is given. No. Changing the license will be an all-or-nothing affair. > > No. If there's a detailed file-by-file, "Copyright 2003, 2008 by > > X who wrote 38 lines, copyright 2005 by Y who wrote 123 lines", > > then that creates pressure to maintain it. That wastes > > *everybody's* time. > > I think there are good reasons for wanting to maintain such > documentation (see above), and I don't think it's so hard to sustain it > -- most files are worked on by relatively few people (so the author list > stays constant) and it's not so difficult for contributors to change the > year of copyright or just add their name to an author list. > > It doesn't need to be as detailed as 'wrote X lines' or 'wrote functions > A, B, C', just a list of major (i.e. justifiably copyright-owning) > contributors and year(s) of their contributions, as in the sample patch > I put forward. (I mentioned tweaks as well, but that was just a > courtesy to the tweakers rather than something that needs to be tracked.) You severely underestimate the effort involved in the documentation. For example, I recently moved the command-line info from the AU into the new website. At a complete guess, - 5-30 lines came from Han-Wen - 5-30 lines came from Mats - 5-20 lines were corrected by Werner - 5-20 lines had a correction sent to a mailist by random users, and were added by Graham or Mats. - 20-50 lines had English grammatical fixes by Graham, but no actual content changes Now, if 15 lines is the magical cut-off, who gets their name added to Documentation/general/download.itely ? I'd have to hunt through the git log for all these lines -- looking at both grammatical/spelling fixes *and* content fixes -- to decypher whether I used 14 of Han-Wen's original lines or 16. I'm not going to do that. It's a gargantic amount of wasted effort. I mean, everybody in that list is deeply involved in lilypond, we all want the best for lilypond, and we all agree to the same license. Spending an hour looking through git logs every time I want to clarify the documentation helps *nobody*. For this reason, I categorically refuse to have file-specific ownership. Documentation is documentation; any doc committers will be listed in the same place. It's true that code doesn't change as much as the docs, although I could well imagine some kinds of useful reshuffling that would require hours of extra work if we had file-specific ownership. (say, what if we decided to split \mark into \markText and \markRehearsal ? Oops, now we need to track down exactly who wrote which lines in the relevant file(s), to make sure that info gets into the new file(s)). I still think it would be a complete waste of time, but if you really want to track down file ownership of source code, _I_ won't stop you. You'd better check that everybody else is ok with this, though. And by "ok", I mean "agrees to you doing the initial work, *and* commits to maintain such info in the future". Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.g
[off-topic] re: Copyright/licensing action plan
On Sun, Sep 20, 2009 at 01:34:46PM +0200, Reinhold Kainhofer wrote: > Am Sonntag, 20. September 2009 10:11:54 schrieb Graham Percival: > > > So basically, you are telling all package > > > maintainers of all distributions to violate the copyright of all lilypond > > > contributors. > > > > No, I am not telling them to do that. I am saying that, if guile > > 2.0 comes out and we have not switched, they should link to > > guile-1.8 if they want to legally distribute lilypond. > > Okay, and what do you think will happen in reality? This thread isn't about reality. The entire discussion is some kind of twisted parody of sadomasochism where we rely on thinly-veiled slurs instead of metal-studded whips. In reality, I think we'll relicense before it becomes an issue. But the whole point is arguing about what's legally required, because either we enjoy it, or achieve some kind of sick pleasure from it. ... which, I guess, is still enjoying it. But it sounds dirtier if I say "sick pleasure". Hmm, actually, I should add an [off-topic] marker to this thread. > I don't think > distributions will be willing to spend time and resources on providing > outdated software/libraries, libc5? > simply because lilypond wants old versions. I'd rather say > lilypond will be dropped instead, citing licensing issues with > lilypond. I'm still not scared. Everybody else gets lilypond directly from the website. If distributions decide not to support the software their uses want, that's their problem. > > Perhaps there is a problem of language here -- the word "must" is > > very strong in English. For example, "if x is greater than 5, > > then it must be greater than 4". "must" means that there is no > > possibility of an alternate option. > > What I didn't write down, but implicitly assumed was the half-sentence "if > we/they want to use the current, installed library versions". Then it is a > MUST. Yes, well, you know what they say about making assumptions. Look, don't blame me. I'm not the person who decided to drive a wedge between free software developers and cause hours of wasted time. This mess is squarely the FSF's fault. > > I am not arguing that there *isn't* such a solid legal reason; I > > have not spent an hour reading those licenses recently. But at > > the same time, I am not aware of any such reason. > > The LGPLv3 also includes the patents clause and the anti-DRM clause, Really?!?! the library license which allows linking to proprietary software still contains an anti-DRM clause?! Wow, the BSD guys were right all along. > On the other hand, all lilypond contributors -- by putting their code under > GPLv2only -- explicitly say that they do not agree to any additional > restrictions. No. We're saying that we want to improve lilypond, and that the existing license is GPLv2only, and so we submit stuff under that license. The *implicitly* states that the code distributed in lilypond has no additional restrictions, but anybody is free to release their lilypond contributions under other licenses. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unsecure assoc calls
Hi Neil, thanks for reviewing and applying. I think what now should be done is to check all assoc-get calls whether they should use strict_checking or not. In some cases this can be quite difficult IMHO and it's a far more time-consuming task than what I've done. Maybe Mark can do this? I think he digged pretty deep into the scheme code recently. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: > For this reason, I categorically refuse to have file-specific > ownership. Documentation is documentation; any doc committers > will be listed in the same place. About docs, I completely agree. I didn't have to spend long in the git logs to realise that it just wasn't feasible to meaningfully identify contributors -- there's too much moving, renaming, copy-pasting, etc. > I still think it would be a complete waste of time, but if you > really want to track down file ownership of source code, _I_ won't > stop you. You'd better check that everybody else is ok with this, > though. And by "ok", I mean "agrees to you doing the initial > work, *and* commits to maintain such info in the future". I think with code it has more value, and ought to be reasonably easy to maintain. There's also the fact that the code, unlike the docs, _does_ contain per-file copyright notices, and that these are wrong. If we're going to have them, they ought to be accurate. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Graham Percival wrote: > I would have thought that > http://lists.gnu.org/archive/html/lilypond-devel/2009-09/msg00438.html > was right up your alley. Yep. I was having a bit of a look through what's there to see what would be involved. I'll see what I can do ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] New margin handling - final version (updated)
Neil Puttock wrote: 2009/9/14 Michael Käppler : Hmm, I can't reproduce this here. Can you try again and send me an png if it still fails? It's still pretty bad; see the attached image. This is weird. I've just checked out a fresh master, did a make clean and compiled. When compiling granados.ly, it looks (as I can compare this) exactly the same and it also outputs the warning "cannot find line breaking that satisfies ..." Let's sum up: - 2.13.3 definitely doesn't have this problem (but there were >many< changes since) - the git master I've just compiled gives the warning and the bad spacing - your git master compiles without warning and with proper spacing (?, please proof) - the example png at kainhofer.com looks fine, though I'm not sure if it's compiled with git, since it's on the new website preview. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On 9/20/09 9:04 AM, "Ian Hulin" wrote: > Carl Sorensen wrote: >> >>> >>> Remaining things to do would be >>> * add define-parser-variable-properties.scm to build (whimper...) >>> >>> >> >> >> No (whimper...) needed here; this is trivial to do. Just add an entry to >> scm/lily.scm. >> >> >> > Wouldn't I need to add a dependency to the build, too? No. The dependency for the build is determined by its presence in the scm/ directory. That part of the build system is really quite fine and easy to use. >> >>> >>> * get the property access routines to use the new all-pv-properties list >>> >>> >> >> >> I'm not sure I have this vision. How would \set know whether to set a >> context property or a pv property? >> >> > Presumably the same way it decides whether to access a context property, music > property, or grob property currently. > That's something I'll have to dig into. I was sort of assuming the \set code > did a lookup of available property lists, I'll undertake further research. Please do. If this works, I think it would be a great addition. But we still haven't heard what Neil thinks about it, and he has a much more complete grasp of LilyPond internals than I do. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
On 9/20/09 9:41 AM, "Valentin Villenave" wrote: > On Sun, Sep 20, 2009 at 2:41 PM, Carl Sorensen wrote: >> This seems like a good idea to me. However, I'm not really strong on parser >> variables. But if this does work, I think it would be an improved way of >> handling point-and-click, because, as you say, it would tie into the >> existing LilyPond syntax. > > I could update the tracker page accordingly... Can you guys help me? :-) I think that we shouldn't yet add a tracker for the general solution. We're still working on the output-suffix issues, which might have a more general solution. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unsecure assoc calls
Hi Michael, Thanks for your work on this. I think this is excellent architectural support for the future. On 9/20/09 2:11 PM, "Michael Käppler" wrote: > I think what now should be done is to check all assoc-get calls whether > they should use strict_checking or not. > In some cases this can be quite difficult IMHO and it's a far more > time-consuming task than what I've done. Maybe Mark can do this? I think > he digged pretty deep into the scheme code recently. I don't think that it's worth spending time on this. I believe that virtually all of the assoc-get calls as currently written are written to allow defaults without throwing a programming error, and do not need strict_checking. As future developments come, or as people are working on code to improve it, if they want to add strict_checking, that would be fine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
