search

tanersener / mobile-ffmpeg

FFmpeg for Android, iOS and tvOS. Not maintained anymore. Superseded by FFmpegKit.
https://tanersener.github.io/mobile-ffmpeg
GNU General Public License v3.0
3.87k stars 790 forks source link

LGPL? (effectively GPL) #346

Closed koush closed 4 years ago

koush commented 4 years ago

Just an FYI, this project is effectively GPL on iOS. There's no way on iOS to meet the LGPL clause of being able to replace the library on a running system so that the dependent app uses the replacement instead.

It's possible, on Android, via some PathClassLoader hackery, but difficult.

koush commented 4 years ago

Also, replacing native libraries in an apk will not work. Any app that uses Google Play Services (which has various signature checks) will fail.

https://github.com/tanersener/mobile-ffmpeg/issues/260#issuecomment-546747014

tanersener commented 4 years ago

Also, replacing native libraries in an apk will not work. Any app that uses Google Play Services (which has various signature checks) will fail.

I don't claim that it is possible to replace native libraries in an apk. I didn't try it and I don't know. What I'm trying to stay is; if you allow users to change LGPL licensed libraries you will be complaint with LGPL. I don't know whether that application will work or can be submitted to App Store, Google Store. As I said before, it I didn't try it.

Also, please note that I'm not a lawyer. I'm just trying to explain what needs to be done to use this library. My scope is mostly statements of LGPL and GPL.

koush commented 4 years ago

Yep, I'm just leaving some feedback, if you want to add this to the README or something. libvlc for android has similar notice.

tanersener commented 4 years ago

Thanks for the heads up. Where is the notice of libvlc for android?

alexcohn commented 4 years ago

this project is effectively GPL on iOS […] It's possible, on Android, […], but difficult.

I beg to disagree. Anyone can repackage an IPA or APK and sign the result with their dev key. The resulting app package is installable on a developer's device.

Possibly, this becomes tricky for an app that verifies its certificates or uses other anti-tampering techniques.

koush commented 4 years ago

@alexcohn yes, that is true, but as I said, various play services things verify the signature, which can render the app unusable, and thus violate the license. this includes: in app purchasing, paid app licensing checks, oauth, firebase apis, and more.

of course, apps that do not have any signature verification (or use google play services check signatures) will be fine. read the lgpl license closely in this regard.

https://github.com/videolan/vlc-android

koush commented 4 years ago 
Also, you must do one of these things:

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.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it

a) This is is only possible if:

b) Possible with PathClassLoader. It is tricky. It is how I am working with libvlc.

c) (same as a)

d) (same as a)

e) (same as a)

alexcohn commented 4 years ago

of course, apps that do not have any signature verification (or use google play services check signatures) will be fine. read the lgpl license closely in this regard.

https://github.com/videolan/vlc-android

I read https://github.com/videolan/vlc-android#license and what they say is that the nature of the platform shifts the license for their app from GPLv2 to GPLv3. Still, the core library is licensed under LGPLv2 (except some GPL optional modules). There is a special press-release that explains why VLC and libVLC stay with (L)GPLv2 and don't move to v3. TL;NR: the latter is not compatible with embedded consumer electronics devices.

IMHO, this distinction applies also to Android or iOS, and all kinds of certificate protection that are part of these platforms or services routinely running there.

I am not a loyer, and the nuances of the licenses depend also on the national legislation in each relevant country, but I believe that the Wiki does already go an extra mile to explain the situation.

alexcohn commented 4 years ago

BTW, there is no technical limitation to switch this project to shared lib on iOS, too. This would make LGPL fully applicable for both platforms.

koush commented 4 years ago

BTW, there is no technical limitation to switch this project to shared lib on iOS, too. This would make LGPL fully applicable for both platforms.

I'm not an iOS dev, but out of curiosity, how does an app store application link to a 3rd party lib (outside of the app, not provided by the iOS platform)? To clarify, it's not just a matter of it simply being a shared library-- the shared library must be replaceable by the user. (section 6b)

alexcohn commented 4 years ago

how does an app store application link to a 3rd party lib (outside of the app, not provided by the iOS platform)?

It's just "like Android"😉

The shared libraries are delivered within a signed zip by the Store. So, the process for a user to replace such lib is essentially same on both platforms: download the zip to personal computer, unpack, drop in the replacement liib, pack and sign with your dev certificate

The original app could add custom certificate verification, but from the point of view of the platform, the new app is completely legitimate. For all kinds of reasons you could also choose to rename the app bundle id.

I don't know if there exist additional restrictions for payed apps or in-app purchases, on either platform. I do know that some devs pay significant sums of money for SDK that verifies that the app zip was not tampered with, including checks that the shared libraries were not replaced.

alexcohn commented 4 years ago

@koush I highly respect your work and I value the VLC project very much, but I believe that there is some conceptual misunderstanding regarding the licensing issues with the library on Android (and iOS). I would be glad to discuss these issues with you in private (not because of discreteness, but rather because such discussion won't be relevant for 99.999% of people who come here).

koush commented 4 years ago

@alexcohn No worries. I am aware I may be mistaken. I am just taking the strictest interpretation here (as I'm investigating it for use in a commercial project, and would err on the side of caution). I'll take your clarifications into consideration.

Ultimately, and unfortunately, any question enforcement and defense comes down to who can afford lawyers. 🤣

alexcohn commented 4 years ago

For a commercial closed-source Android app to comply with LGPL beyond any reasonable doubt seems to be a trivial task. Let the code that loads the LGPL native library look for a user's replacement on external storage first.

This, unfortunately, won't work on Android 10 and higher. So, the fall-back is to let the user repackage and resign the APK.

thegarlynch commented 4 years ago

can you post the result of your discussion here please ?