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

[Hans-Christoph Steiner]

On 02/03/2013 01:19 PM, Jonathan Wilkes wrote:
> ----- 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.)

Only the copyright holder can change the license, I'm not proposing any
license changes.  I am saying that if the overall library is licensed under
the GPLv3+, then code licensed under the GPLv2+, BSD, Tcl license will be
compatible and can be freely incorporated into the GPLv3+ library.  This
library would have to keep the copyright licenses intact, according to the
terms of the other licenses.  Code licensed GPLv2-only like the Linux kernel
would not be compatible, for example, but I haven't found any Pd code that's
licensed GPLv2-only.


> 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

These things are all true, I think its worth it. I think you might be thinking
that there will be more changed than there need to be.  Most of the objects
would not need documentation changes, or just small changes.  There are a
number of libraries that I continue to maintain only because of a couple
objects (like [ENV] in cxc, or [getenv] and [system] in Motex).  My plan is to
stop my maintenance work on those libs once the standard lib makes them
unneeded.  Of course anyone else is welcome to maintain them.

Another thing is that there will be less to document.  For example, newbies
won't need to learn about loading libraries until much later.  And the current
system of separate libraries loaded by default in a specific order is fragile
and causes many weird, hard to understand bugs for no good reason.

.hc

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