----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, February 2, 2013 8:35 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
[...]
What are the maintenance problems solved by copying binaries into new directories?
The point is to reduce complexity and exceptions to consistency. Once example where just copying an external would reduce complexity is taking an object out of zexy. Zexy has a very complicated build system because it has a huge array of objects, many of which will not build on every system, things like [lpt]. Therefore the build system needs to configure itself based on what is available.
A standard library would only have things that build on every system, so a much simpler build system can be used (like the library template).
But you're evidently keeping zexy for compatibility reasons, so how would this create less maintenance for you?
Also-- you will end up with objects that have different licenses in the
same lib.
Is there a precedent for that in any programming language?
You will be able to consider the whole GPLv3+.
You are wrong-- there are libraries currently under GPLv2, some under GPLv3, some GPLv2+, some 3-clause BSD, some Tcl/Tk license, and maybe a few others.
You cannot automagically change the GPLv2 and GPLv3 to GPLv3+, and if you change the 3-clause BSD to GPLv3+ it needs to be explicit-- i.e., changing it in the pd META patch. For the other versions of the GPL someone would need to contact all the original authors and get them to release it under GPLv3+.
(Btw-- please don't start a thread on licenses here. If you don't understand the problems then email the fsf and they can explain it, and you can paste their response here.)
These changes will turn into a lot of documentation work, not to mention changing existing docs to point to the standard libs instead of the legacy ones where possible, and changing FLOSS manual stuff and Pd manual stuff as well as any other extant tutorials widely used by the Pd community to clearly explain the new libs so that new users don't get stuck learning half legacy stuff and half new lib stuff (thus making it even more difficult to get around in the language). Not to mention documenting the legacy stuff and its relationship to the new stuff, while making the new stuff more easily discoverable in the docs and the search plugin. (Oh, and contacting legacy lib devs and seeing who is willing to relicense under GPLv3+.)
If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed. I suspect it'd be about two or three months of full-time work. If people are willing to pay me to make these changes I'm happy to do them. As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes. (As well as testing that the results worked across platforms.)
-Jonathan
There will need to be other copyirght notices from BSD licensed code, but that's manageable.
.hc