Yes, this is correct. I was wrong in the last mail.
Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries.
I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD.
Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at wrote:
From: "Scott R. Looney" <scottrlooney@gmail.com mailto:scottrlooney@gmail.com> Date: November 7, 2015 at 12:24:44 PM MST To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] looking for other vanilla filters or abstractions for libPD
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
Actually, as I recall, LGPL is kosher *if* you also publish the source code so users can rebuild the software. Isn’t this correct Jonathan? At least that was how I was approaching PdParty.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:57 PM, Dan Wilcox danomatika@gmail.com wrote:
Yes, this is correct. I was wrong in the last mail.
Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries.
I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD.
Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: "Scott R. Looney" <scottrlooney@gmail.com mailto:scottrlooney@gmail.com> Date: November 7, 2015 at 12:24:44 PM MST To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] looking for other vanilla filters or abstractions for libPD
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
Clarification: LGPL v2 YES, LGPL v3 NO :D
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 2:00 PM, Dan Wilcox danomatika@gmail.com wrote:
Actually, as I recall, LGPL is kosher *if* you also publish the source code so users can rebuild the software. Isn’t this correct Jonathan? At least that was how I was approaching PdParty.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:57 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Yes, this is correct. I was wrong in the last mail.
Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries.
I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD.
Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: "Scott R. Looney" <scottrlooney@gmail.com mailto:scottrlooney@gmail.com> Date: November 7, 2015 at 12:24:44 PM MST To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] looking for other vanilla filters or abstractions for libPD
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
And checking the expr~ License.txt it’s LGPL v3, so again I’m wrong. Doh.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 2:02 PM, Dan Wilcox danomatika@gmail.com wrote:
Clarification: LGPL v2 YES, LGPL v3 NO :D
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 2:00 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Actually, as I recall, LGPL is kosher *if* you also publish the source code so users can rebuild the software. Isn’t this correct Jonathan? At least that was how I was approaching PdParty.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:57 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Yes, this is correct. I was wrong in the last mail.
Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries.
I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD.
Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: "Scott R. Looney" <scottrlooney@gmail.com mailto:scottrlooney@gmail.com> Date: November 7, 2015 at 12:24:44 PM MST To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] looking for other vanilla filters or abstractions for libPD
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
There are some things also that can't be translated out of expr into vanilla Pd, so allowing users to swap in files is kind of abstract. The lack of a vanilla bitwise XOR [^] in vanilla has been killing me lately. It's in expr, but there's really no viable substitute for it using vanilla objects. I'm sure there are others, but that's the one on my mind lately, and the only thing from expr I routinely use.
Matt
On Sat, Nov 7, 2015 at 4:04 PM, Dan Wilcox danomatika@gmail.com wrote:
And checking the expr~ License.txt it’s LGPL v3, so again I’m wrong. Doh.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 2:02 PM, Dan Wilcox danomatika@gmail.com wrote:
Clarification: LGPL v2 YES, LGPL v3 NO :D
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 2:00 PM, Dan Wilcox danomatika@gmail.com wrote:
Actually, as I recall, LGPL is kosher *if* you also publish the source code so users can rebuild the software. Isn’t this correct Jonathan? At least that was how I was approaching PdParty.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 1:57 PM, Dan Wilcox danomatika@gmail.com wrote:
Yes, this is correct. I was wrong in the last mail.
Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries.
I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD.
Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at wrote:
*From: *"Scott R. Looney" scottrlooney@gmail.com *Date: *November 7, 2015 at 12:24:44 PM MST *To: *"pd-list@lists.iem.at" pd-list@lists.iem.at *Subject: **Re: [PD] looking for other vanilla filters or abstractions for libPD*
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It's kosher in the same general sense that a "don't murder using drones" clause is kosher if you don't murder people with drones. In both cases you are probably following the "spirit" of the license, but that has nothing to do with license compatibility with the app store (or in PIDIP's case, the validity of the license itself[1]). -Jonathan
[1] http://pure-data.cvs.sourceforge.net/viewvc/pure-data/externals/pidip/LICENS...
On Saturday, November 7, 2015 4:00 PM, Dan Wilcox <danomatika@gmail.com> wrote:
Actually, as I recall, LGPL is kosher *if* you also publish the source code so users can rebuild the software. Isn’t this correct Jonathan? At least that was how I was approaching PdParty.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 1:57 PM, Dan Wilcox danomatika@gmail.com wrote:
Yes, this is correct. I was wrong in the last mail. Since the externals are built and linked when building libpd as iOS doesn’t allow dynamic linking, there’s no way to satisfy the distribution clause in the LGPL. I was thinking about *abstraction* libraries earlier which are OK as long as you can allow users to update them. I do this in PdParty by exposing the lib folder and make it easy to swap in new versions of those files. Of course this works since they are not binary compiled libraries. I was hoping for expr adopting a BSD license for this issue, but I also understand if the authors choose not to. I’m pretty sure everything else distributed in the pd vanilla sources is BSD. Also, I’m sure there are apps running with expr~ etc in the App Store. You only have to add those files to your build tree when building libpd and call their setup function. I doubt there is a automatic mechanism Apple is using to detect such things.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 7, 2015, at 1:08 PM, pd-list-request@lists.iem.at wrote: From: "Scott R. Looney" scottrlooney@gmail.com Date: November 7, 2015 at 12:24:44 PM MST To: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] looking for other vanilla filters or abstractions for libPD
thanks Jonathan. this is what i assumed re LGPL when i saw a discussion about using fluidsynth in a build, which has a LGPL variant but not anything more permissive. so one question would be if anyone here on the list had a paid app rejected or accepted on the App Store due to using an LGPL license? expr and expr~ are very useful for a variety of things but for now i'm not using them due to this offchance.
i would further guess that FSF's exact words on LGPL were probably pretty dark on using the iTunes Store in general. i've seen some announcements from them in the past that made it clear how they feel about walled gardens.
-
Dan Wilcox -
Jonathan Wilkes -
Matt Barber