[PD] Licensing issues (was rjdj is gone, robotcowboy is coming ...)

[Scott R. Looney]

for me, it's more a matter that a lot of objects are available that make
the basic coding and patch building tasks themselves much easier. the one
that currently comes to mind is [coll] which is part of cyclone. i really
have no idea what can be substituted for it that only requires PD vanilla,
but i'm coming from Max, and not having good list management is an obstacle.

is there is a good way for PD-vanilla to read and manipulate a list of
lists like coll? or split lists? i can make my own [counter] and [swap]
objects easily enough, but having no obvious and apparent means of
storage/recall/manipulation, except arrays and tables which are one index
one value. not trying to pull this off the licensing discussion, but i'm
trying to point out a genuine storage/manipulation need here. i'm happy to
stay with vanilla only if PD can do these things. [qlist] + [textfile] are
the closest but seem to come with severe manipulation restrictions. cyclone
comes with [zl] manipulation.

if i'm needlessly complaining please let me know. i'm just a midrange
MaxMSP guy trying to see how to get something running on iOS.

scott



On Sat, Nov 3, 2012 at 10:51 AM, Dan Wilcox <danomatika at gmail.com> wrote:

> I'll chime in on what Peter said.
>
> Pd-Extended itself doesn't have a global license, the licenses are
> individual to the externals. libpd itself is BSD so we can use it on iOS
> while some externals are GPL and we can't. I personally would *like* to
> have some available, but I also value the GPL and would not wish anyone to
> change a license just for my convenience at a cost to protections the GPL
> is designed to ensure. I'm not anti-Apple or anti-GPL, it's just a
> pragmatic approach to getting a working solution on good hardware.
> Unfortunately, Android still does not have good audio latency worked out,
> for instance.
>
> As I told Frank B, I've seen the "vanilla light". There is a whole lot you
> can do without externals and I'd highly recommend checking out rjlib:
> https://github.com/rjdj/rjlib. I will be rebuilding my patch library to
> work with rjlib and be vanilla compatible as it's the best way to know it
> works in libpd-land as well as on desktop.
>
> On Nov 3, 2012, at 11:08 AM, pd-list-request at iem.at wrote:
>
> *From: *Peter Kirn <peter at createdigitalmedia.net>
> *Subject: **Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is
> coming ...)*
> *Date: *November 3, 2012 7:17:06 AM EDT
> *To: *pd-list <pd-list at iem.at>
>
>
> Hello, I just want to chime in here.
>
> I don't think it's accurate to say pd-extended is "GPL." pd-extended is
> essentially a distribution of externals, abstractions, and other
> conveniences. Obviously, developers are free to use what license they want.
>
> Yes, libpd and Pd-vanilla use an extremely permissive license.
>
> I believe it's possible to develop free software for iOS. I think on
> reflection it makes a stronger statement to reach that platform -
> locked-down as it may be - with free software than it does to ignore it.
> This means using a BSD- or MIT-style license and not GPL or LGPL; the
> earlier thread was right. Note that I think you *can* use a copyleft
> license for your patches, because these will run independently of iOS.
>
> There are other reasons - compatibility and simplicity being foremost - to
> favor vanilla in development with libpd whether or not you're using iOS. I
> think we may be overstating the problem here a bit.
>
> In other words, yes, Apple has a problem with GPL. But libpd developers I
> think don't have a problem with Apple, if that makes sense. And I think we
> make a stronger statement by showing how well the free solution works than
> we do banging our head against a brick wall.
>
> I believe in the GPL license, which is why we're using it on MeeBlip. But
> I think the short answer is, use BSD with libpd, try to default to vanilla,
> and maximize the contexts with which your software can be used. Add GPL or
> copyleft to patches to encourage others to share. That for me seems a
> pretty nice solution.
>
> Now, Apple aside, it does seem that it makes sense for external developers
> to use the same license as Pd. (Patches and abstractions are a different
> issues, because they're effectively content rather than part of your code.)
> But that's up to developers.
>
> Peter
>
>
> --------
> Dan Wilcox
> danomatika.com
> robotcowboy.com
>
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121103/2c725216/attachment.htm>