I realize I'm dredging up an old thread here - I'd just like
clarification on the subject. . . .
1. iPhone apps must statically link libraries, can't use dynamic linking
2. An ECL-using iPhone App will need to link in ECL runtime elements.
3. Apple would pass the app and let it onto the App store.
In order to be in compliance with the ECL's licensing:
With these assumptions, say an app, FoobarBlasters, was made with ECL
and put on the app store. . . .
Is compliance with ECL licensing possible at this stage - if so, what
would that take? Published source code for all of FoobarBlasters?
Published FoobarBlasters binary that can be dynamically linked with a
dynamic ECL (not possible if assumption correct).
Can ECL be used for a closed-source (at least for the non-ECL
components) commercial App Store app?
On 1/31/2011 6:41 PM, Matthew Mondor wrote:
> On Mon, 31 Jan 2011 20:24:28 +0100
> Juan Jose Garcia-Ripoll <juanjose.garciaripoll@...> wrote:
>> The discussion is about GPL and then the author jumps off the wagon and says
>> it applies also to LGPL "because it is basically the same". This is not
>> true. LGPL does not force anyone to provide the sources of the files they
>> link against the library. GPL does.
> I also wouldn't have considered ECL for any serious project if it was
> under the GPL; Although I tend to prefer working with MIT/BSD style
> licensed code (I also release my own code under BSD-style licenses),
> the LGPL is fortunately sane enough, indeed.
> Toolchains under the GPL are problematic and need additional exception
> clauses, like GCC provides for GCC library code, autoconf for the
> configure script it produces, etc.
> As for the ECL dependencies, fortunately libgmp is also under the LGPL,
> boehm-gc and libffi under MIT/BSD-style licenses. For those using a
> GNU OS, glibc is also LGPL licensed.
> So I agree that there should be no problem other than perhaps due to
> the ignorance of some distribution services.