4 ms·
Let's imagine I'm making MortPlayer, a video player for iOS which uses a version of the VLC libraries which are licensed under LGPL 2.1 (since that's what you'r
by mort96 3y ago
Let's imagine I'm making MortPlayer, a video player for iOS which uses a version of the VLC libraries which are licensed under LGPL 2.1 (since that's what you're focusing on). Let's say I want MortPlayer to be closed source.
In other words, VLC owns the libraries, and I want to license them under the LGPL 2.1.
The LGPL 2.1 says:
6. As an exception to the Sections above, you may also combine or link a "work that
uses the Library" with the Library to produce a work containing portions of the
Library, and distribute that work under terms of your choice, provided that the
terms permit modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
Okay, so I must distribute MortPlayer under terms which permit modification and reverse engineering. I can do that. Maybe Apple's terms conflict, but let's assume that's not an issue, let's read on.
You must give prominent notice with each copy of the work that the Library is used
in it and that the Library and its use are covered by this License. You must supply
a copy of this License. If the work during execution displays copyright notices, you
must include the copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.
Okay, no problem.
Also, you must do one of these things:
Oh boy.
a) Accompany the work with the complete corresponding machine-readable source code
for the Library including whatever changes were used in the work (which must be
distributed under Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that uses the Library",
as object code and/or source code, so that the user can modify the Library and then
relink to produce a modified executable containing the modified Library. (It is
understood that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application to use the
modified definitions.)
Okay. I can accompany the work (MortPlayer) with the source code for VLC's libraries, no problem. MortPlayer is executed and linked with VLC's libraries, so I need to 'accompany the work with ... the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library".
I think that's doable with app stores? I can certainly distribute a zip file with the object files for MortPlayer so that the user can link them against their own version of VLC. The user wouldn't be able to then run the recompiled application, on their device, but that's not specified in the terms...
Honestly I'm a bit surprised, I fully expected to find that this section a) included wording which requires the user to be able to run the resulting linked application, which Apple forbids (asterisk), and then go through b) and conclude that iOS doesn't have a "suitable shared library mechanism" due to its restrictions etc. But I'm instead forced to conclude that you're probably right, at least by the letter of the license.
I read the corresponding parts of LGPL 3 as well, and I can't find anything which requires the re-linked application to be immediately executable on the user's machine there either.
I think my conclusion is that LGPL, both 2.1 and 3.0, is fully compatible with app stores so long as you distribute your application as object code which can be linked against the LGPL licensed libraries? I would be very interested to hear from someone with opposing views about why I may be wrong. I, as they say, ANAL.
- naasking 3y agoIt should be compatible with app stores. How would the inability to swap out the VLC library be any different from a program that you can't change because it's on a system managed by a sysadmin? Of course you, as a user, can run LGPL programs on mainframes or other third-party managed systems, this was a well known use case when the LGPL was written.
- actionfromafar 3y agoIt's all about the distribution of copyrighted material. The "user" then is the admin which received the program. The other used without admin, is just using some remote service. (With telnet/ssh. No distribution of copyrighted material is going on there, just input/output from a remote service, like a web site running LGPL code.)
- hedora 3y agoAre these new changes with LGPL 2.1? I don’t remember it containing the modification and relinking restrictions in the past. It kind of defeats the purpose of the LGPL IMO. As an aside, it really bugs me that the GPL morphed into this thing that gives developers the freedom to run privacy violating and user-abusing cloud services, but doesn’t allow manufacturers to ship the same stuff on physical (and perhaps offline) hardware the end users have physical control over. When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time. Anyway, I guess the above restriction means I won’t be using LGPL for stuff I write at work, even though most of what we do gets open sourced anyway.
- mort96 3y agoHuh? The whole point of the LGPL is to say, "you can use the LGPL'd code in your closed-source product, but the user must be able to replace the LGPL part of your product with their own version". The way to achieve that is to either use some kind of dynamic linking where the user can provide their own .so/.dll/.dylib of the LGPL'd library, or to provide the object files so that the user can statically re-link the application with their own version of the LGPL'd library. This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version. What purpose of the LGPL is defeated?