Hello, I just want to chime in here.<div><br></div><div>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.</div>
<div><br></div><div>Yes, libpd and Pd-vanilla use an extremely permissive license.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. <br>
<br>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.<br>
<br>Peter</div>