LGPL code in the Mac App Store?

[Demitri Muna]

Hi,

I’m working on a program that I will be submitting to the Mac App Store that uses LGPL code. I have recently learned that the license requires the capability for the end user to create their own version of the LGPL library to link against the application (I have been compiling the source directly into the library). Presumably this would be done dynamically at launch time, or else the user can build their own version of the library and replace the static version in the app bundle. With code signing (and potentially the sandbox), is this possible/allowed? Is there some other mechanism that could be used to make this work?

Frameworks appear to be a possible way around this. I could wrap the LGPL library into a framework that ships with the app, but then at runtime load a user’s version of the framework if one is available (fulfilling the license requirements). Does anyone know if this is possible/allowed?

Cheers,
Demitri

[Matthew Smollinger]

Hi Demitri,

  I'm 99% positive this won't work with Mac App Store apps because of code-signing issues. I'm fairly certain Apple code signs all dynamic frameworks when they go through the MAS so trying to load something the user has installed on their system won't work.

--

Matt

[Ulf Buermeyer]

Hi Demitri,

+1 to Matthew, that won't work.

But IMHO you misconstrued what the LGPL terms stipulate: You needn't
make your app work with libraries that users compiled themselves. The
idea is that you need to make accessible all LGPL'ed code that you're
using / changing so that the code remains available and people can
compile it themselves, but NOT necessarily to use such modules within
your app.

"The license allows developers and companies to use and integrate
software released under the LGPL into their own (even proprietary)
software without being required by the terms of a strong copyleft
license to release the source code of their own components. The license
only requires software under the LGPL be modifiable by end users via
source code availability."

"The main difference between the GPL and the LGPL is that the latter
allows the work to be linked with (in the case of a library, 'used by')
a non-(L)GPLed program, regardless of whether it is free software or
proprietary software. The non-(L)GPLed program can then be distributed
under any terms if it is not a derivative work."

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

Best, Ulf

> --
> --
> You received this message because you are subscribed to the Google
> Groups "CocoaHeadsNYC" group.
> To post to this group, send email to cocoah...@googlegroups.com
> Please observe the guidelines at
> http://www.cocoaheadsnyc.org/mailing-list-rules/
> To unsubscribe from this group, send email to
> cocoaheadsny...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/cocoaheadsnyc?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "CocoaHeadsNYC" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cocoaheadsny...@googlegroups.com
> <mailto:cocoaheadsny...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Matthew Smollinger]

I would stick to Apache / MIT / BSD licensed code. Far simpler. 

--

Matt

You received this message because you are subscribed to a topic in the Google Groups "CocoaHeadsNYC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cocoaheadsnyc/Ovd8aWGmf7o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cocoaheadsny...@googlegroups.com.

[jal...@red-sweater.com]

It’s great to stick with code that has simpler licenses, when such code is available.

I ship LGPL licensed code in MarsEdit, which is available on the Mac App Store.

I have always shared Ulf’s interpretation of the license, that the source could should be made available to any LGPL library that is bundled. My further reading of that is it’s only necessary to make the source code available yourself if you’ve made any changes to the original project. Finally, because the LGPL code in MarsEdit happens to be JavaScript, it ships in the app bundle as plain-text, readable source code that anybody could copy out of the bundle and use as they like. So I have considered any customer who downloads MarsEdit as having been delivered the pertinent source code in question.

I have been satisfied that this accommodates the letter and spirit of the LGPL. Of course, if you have concerns about legal liability, you should consult a lawyer before shipping any 3rd party licensed code.

Daniel

> To unsubscribe from this group and stop receiving emails from it, send an email to cocoaheadsny...@googlegroups.com.

[Benjamin Ragheb]

On Feb 25, 2016, at 4:40 AM, Ulf Buermeyer <u...@kicks-apps.com> wrote:

> But IMHO you misconstrued what the LGPL terms stipulate: You needn't make your app work with libraries that users compiled themselves. The idea is that you need to make accessible all LGPL'ed code that you're using / changing so that the code remains available and people can compile it themselves, but NOT necessarily to use such modules within your app.

Unfortunately, your interpretation directly contradicts the text of the license itself. <http://www.gnu.org/licenses/lgpl.html>

LGPL, version 3, section 4, "Combined Works":

> You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

...

> d) Do one of the following:
> 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

> 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

Older versions of the GPL are less explicit about this, so you might be able to argue this is not necessary if the library is licensed under an earlier version of the LGPL.

If you could build the library code into a bundle that could be loaded at runtime, so the user could choose an alternate version to load, that would be a way to comply with the terms of the license. Ironically, it is probably impossible to do this in a way that doesn't violate Apple's sandbox restrictions.

* * *

For what it's worth, I spent a day or two studying GPL + App Store when I decided to release the source code to an app I was no longer able to maintain. The regular GPL is incompatible with the App Store for a much simpler reason: the App Store "may not impose any further restrictions on the exercise of the rights granted or affirmed under" the GPL. But that's what the App Store does with the DRM layer that is applied to all downloaded applications.

As a software developer, this is frustrating, but the GPL is about protecting the rights of users, not developers. And watching computers become more and more tightly locked down, year after year, I've really come to appreciate that.

-- Ben

[Demitri Muna]

Thanks all for the comments.

I’ve spent more time than I’d have cared to reading the licenses (v2 and v3), as well as articles people have written on the web. Opinions vary significantly, but the one thing that everyone can agree upon is that they are not lawyers. And that’s partly the problem; the (L)GPL licenses seem to be deliberately difficult to parse.

My original understanding was Daniel’s interpretation, but the more time I spent on it my interpretation/understanding is closer to what Ben outlined. Is this a problem with the App Store? It entirely depends on the author, I feel. I’ve come across authors who put their code under LPGL with the intent of “free to use if unmodified”, and others who are militant about the letter of the license (e.g. “I don’t have a problem with you doing x, but the license says this and that’s the one I choose so you can’t”, which just makes me scratch my head).

And yes, as a rule I tend to avoid (L)GPL licensed code when I can, but in this one case the library is extremely specialized and I have little choice. The best way forward I think is to ask the author, “Hey, can I use your code unmodified in my App Store app, or if I modify them publish my changes in a GitHub repo?” and if the answer is “sure”, then the license is irrelevant, you have permission, and the author won’t sue you. No one else has standing to say anything about it.

I don’t have time to test this in the short term (partly as I don’t have an app in the App Store), but maybe someone else here will know if this is possible. This would satisfy the letter of the license. Put the LGPL code into a framework, dynamically linked at run time. Put the project that creates the framework on GitHub. The user gets the app from the App Store, and also checks out the framework. They make modifications to the framework (without changing the API) and build their own copy. They then strip all code signing from the app, replace the framework in the bundle, and run the program.

Is this technically possible? I don’t know. But I think it would satisfy the license. Is it recommended? Absolutely not, but then again, I’m 100% sure zero of my users will want to do this.

Demitri

[jal...@red-sweater.com]

What if you have your app look for and load the library dynamically: usually from within its own app bundle, but optionally from within a designated location in the app’s sandbox container? Then a user could theoretically supply their own modified copy by installing it in your container.

Daniel

> --
> --
> You received this message because you are subscribed to the Google
> Groups "CocoaHeadsNYC" group.
> To post to this group, send email to cocoah...@googlegroups.com
> Please observe the guidelines at http://www.cocoaheadsnyc.org/mailing-list-rules/
> To unsubscribe from this group, send email to
> cocoaheadsny...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/cocoaheadsnyc?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "CocoaHeadsNYC" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to cocoaheadsny...@googlegroups.com.

[Demitri Muna]

On Feb 27, 2016, at 2:33 PM, jal...@red-sweater.com wrote:

What if you have your app look for and load the library dynamically: usually from within its own app bundle, but optionally from within a designated location in the app’s sandbox container? Then a user could theoretically supply their own modified copy by installing it in your container.

Doesn’t anything executable have to be signed?

Demitri

[jal...@red-sweater.com]

I wasn’t aware of this requirement, but if so, the user could sign it themselves.

Daniel