[PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

Jonathan Wilkes jancsika at yahoo.com
Sun Feb 3 19:19:49 CET 2013

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-list at iem.at" <pd-list at 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.)


> There will need to be other
> copyirght notices from BSD licensed code, but that's manageable.
> .hc

More information about the Pd-list mailing list