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, [email protected] wrote: > From: Peter Kirn <[email protected]> > Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming > ...) > Date: November 3, 2012 7:17:06 AM EDT > To: pd-list <[email protected]> > > > 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
