Since the MacOS app is free, does the creator need to do anything but give attribution? Seems like the place to focus on for license issues is the iOS app which costs $10.
As it contains GPLed code, the MacOS app's source code must be distributed or offered for distribution under the GPL to anybody who has a copy of the binary.
Is that true? My understanding is that so long as you clearly segregate GPL and non-GPL code by using wrapper classes and linking (rather than copypasta), the core application can remain non-GPL.
> Is that true? My understanding is that so long as you clearly segregate GPL and non-GPL code by using wrapper classes and linking (rather than copypasta), the core application can remain non-GPL.
Sort of. If you license your main source code under, say, the MIT license, you can distribute that source code, and any object code compiled from it, under the terms of the MIT license.
However, once you distribute a binary containing that source code and some GPLed source code linked together, you have to distribute all that source code (including any other libraries) under GPL-compatible licenses, such that the user can compile and distribute the application themselves.
The LGPL allows you to keep your main source code closed-source while using an LGPLed shared library, so long as a user can replace the shared library with their own version.
Except for OS libraries and similar, distributing two components intended to be runtime-linked together is generally not sufficient separation to be considered "mere aggregation". I would personally not even patch a GPL app to expose a custom API with the intention of using it from a separate non-GPL process; that also seems like it's more than "mere aggregation". (Using an existing / common API seems fine.)
and specifically Steve Jobs asking Richard Stallman if he could avoid having the Objective-C compiler be under GPL:
I say this based on discussions I had with our lawyer long ago. The
issue first arose when NeXT proposed to distribute a modified GCC in
two parts and let the user link them. Jobs asked me whether this was
lawful. It seemed to me at the time that it was, following reasoning
like what you are using; but since the result was very undesirable for
free software, I said I would have to ask the lawyer.
What the lawyer said surprised me; he said that judges would consider
such schemes to be "subterfuges" and would be very harsh toward
them. He said a judge would ask whether it is "really" one program,
rather than how it is labeled.
I am personally not a fan of that answer, but between recent caselaw like Oracle v. Google and some clarifications in GPLv3 around "Standard Interfaces" and the aggregation clause, it seems like betting on any other answer is a bad plan.
Usually, the litmus test is: Does the software work at all without the GPL'd parts? If not, it doesn't matter how segregated you think it is, because it's still dependent on that GPL'd code.
As an example, consider a video player with a codec plugin system. The player ships with a noop plugin, a proprietary plugin for MPEG-1 video, and a general plugin that leverages GPL code. It is my understanding that the video player can still be non-GPL, but that wrapper to the GPL code must be GPL
This seems exactly analogous to the CLISP/libreadline example I just linked in another comment, where it was agreed that CLISP needs to be under the GPL.
The situation is, probably, a bit different if the video player authors have no intention of using GPL code and just develop an interface, and someone else unrelated comes along and writes a GPL plugin. But if the app's authors ship the GPL plugin or worse write it, they're on shaky ground.
(This gets you into some slightly silly situations where author A writes GPL software A linking software B, software B can make use of a GPL-incompatible library C, all of A, B, and C can legally redistribute their software on their own, but Debian has to make sure A doesn't link C because they're shipping the whole thing.)
If you're distributing them all together, all of it would have to be under the GPL. If you're distributing them separately, otoh, only the GPLed bits would have to be under the GPL.
I don't think that's correct as it is most of the point of the LGPL. I think it's how QT was able to sell licenses to closed source software despite being GPL'd as well (dual license).
They must release the source to anyone they give a copy of the binaries, which - since the software is free - is anyone who goes to their website and clicks "download."
It's not as simple as "if they ask" - if you choose not to distribute the source code with the binary or provide it for download, you must explicitly provide a written offer valid for 3 years for the source code.
I wouldn't think so (you'd need wording like "I agree to distribute source code to you on request to <address>"), but I doubt it's been challenged - it's an obscure use case of the GPL.
Not that obscure; lots of hardware vendors use Linux in their routers/TVs/tablets/phones/etc and distribute the sources separately. In fact, every manufacturer of Android phones should have such an offer included with their device.
