LGPL is not compatible with IOS

[Yepher]

FFMPEG is such a nice library. It would be great to be able to use it in commercial IOS/Android application. Unfortunately Apple App Store does not allow static linking.

Many LGPL licensed software have added a static linking exception for this very reason.

My quick survey of the Media apps in the IOS market seems to indicate many folks are using FFMPEG anyway even though the license disallows this.

Here is one such example:

​http://itunes.apple.com/us/app/tunein-radio/id418987775?mt=8 (I pick on them because they are quite public about their use)

It seems to me in the spirit of LGPL it should be allowed to happen and it is really just a semantic issue.

I would really love to use FFMPEG in several projects on my horizon but it is not possible unless there is a static linking exception.

Thank you for your consideration.

[Carl Eugen Hoyos]

Replying to yepher:

FFMPEG is such a nice library. It would be great to be able to use it in commercial IOS/Android application. Unfortunately Apple App Store does not allow static linking.

How is this related to the LGPL?

Please understand that it is simple to comply with the LGPL when distributing applications in the Apple App Store (you just have make sure that re-linking is possible, apart from complying with the usual rules that include providing sources etc.), it may be possible that you cannot fulfill Apple's requirements and the LGPL at the same time, I don't know (and I don't care).

Please also understand that FFmpeg does not have single author, but an uncountable number of contributors, a license change is therefore impossible.

[Gili]

cehoyos,

So if I understand you correctly, so long as we publish all object code (.o and .a files) necessary to relink our application we can use use FFMPEG on Apple App Store without releasing the source-code for our application. Is that correct?

[Carl Eugen Hoyos]

Replying to cowwoc:

So if I understand you correctly, so long as we publish all object code (.o and .a files) necessary to relink our application we can use use FFMPEG on Apple App Store without releasing the source-code for our application. Is that correct?

No.

Please understand that "usage" of FFmpeg is completely unlimited, what you are asking for are the rules for distribution. You have to follow either the requirements of the LGPL or the requirements of the GPL, depending on which optional features of FFmpeg you choose when you run ./configure.
If you decide to enable GPL-only features of FFmpeg, you have to follow the GPL which includes (beside other requirements) the requirement for providing the complete source code for the application that is based on (contains) FFmpeg.
If LGPL is enough for you, you have to provide the exact FFmpeg source code you used, but not the source code of the application that links against FFmpeg. Several other requirements exist, either read the LGPL or ​http://ffmpeg.org/legal.html - if you cannot (or don't want to) follow item 2 (and 16), i.e. if you are not using dynamic linking, you have to provide the necessary object files to allow static (re-)linking of your whole application.

[Gili]

cehoyos,

Okay, so you're saying that if I restrict myself to LGPL-only features and I use static linking (since there is no alternative on iOS) and I publish the necessary object files to allow static relinking of the whole application then I am complying with the license. Is that correct?

I would like to bring one final issue to your attention. Some people argue that LGPL is incompatible with the Apple App Store license because although you can re-link the aforementioned application with the provided object files, you cannot redistribute it without paying for an App Store account. Others argue this is no different than paying for development kits under embedded platforms.

I'm not asking you to be a lawyer. Rather, I'm asking the ffmpeg authors to offer a licensing "clarification" that they are aware of the aforementioned dispute and in gstreamer's case this does not violate the license if the remaining terms are respected.

[reimar]

You are at the very least missing "offer the source of the FFmpeg version you used". And there are more specific requirements, I think the only option you will be able to take a advantage of is the section 6c) of LGPL (though I can't comment on the specific legal implications of the term "written").
Also I am a bit surprised about your questions, IMHO section 6a) is rather clear on what is needed.
Next, there is no way you can ask "the FFmpeg authors", there are probably over 1000, if not more of them.
However I believe that you must have misunderstood the discussion concerning compatibility with the App Store or listened only to the clueless people. The requirement for e.g. code signing was considered to be not an issue for (L)GPL v2, and was the reason that the GPLv3 was introduced (which obviously means you should not compile your FFmpeg with --enable-version3).
Now if you want to have my opinion based mostly on guessing what else might go wrong (assuming you provide the stuff required in 6a/c):
1) I believe that Apple (did?) require you in the developer agreement to own the rights to the code you distribute. That is between you and Apple though.
2) I believe that it is in fact Apple, not you, doing the (commercial) distribution (they make loads of copies, they get paid loads of money for it, 30% I believe). As such, it is Apple's responsibility to provide for the (L)GPL requirements according to section 6. This is between the (e.g. FFmpeg) authors and Apple, though depending on 1) Apple might have claims against you afterwards...

[Yepher]

So when is the FFmpeg legal team (aka authors?) going to go after Apple for all those applications that are currently using the Library without adhering to the terms? ;)

@Reimar,

So if I understand, what you are saying above is:

FFMpeg legal would not attempt to prosecute an entity that sells "closed source application that contains FFMPeg statically linked" if:

1. The entity offers the source of the FFmpeg version they used.
2. Address LGPLv2 "6C" by providing a written offer to provide the source code of FFMPeg used for the application. (this presumably also clears Apple?)
3. ensure FFMPeg was built as LGPL and not GPL

Did I understand you properly?

Thank you for your patience on this issue.

[reimar]

I assume it is clear I can't give more than personal opinion.
There is no "FFmpeg legal team" so the questions don't really make any sense. It is not possible to predict with certainty what each of about 1000 people will do. Though you can look at historic data and to the best of my knowledge it will indicate that people making the (possibly modified) code of the LGPL part available hassle-free don't really risk lawsuits.
The original question was about static vs. non-static linking, reading 6a) should answer that question.
You still have to follow the rest of the terms, I will _not_ spend the time to try and come up with a water-proof complete list, even more since I certainly can't say anything about any 3rd-party obligations you may have (note in particular "provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications" in section 6).
6c requires the entity doing the distribution to make the offer, so you making such an offer certainly doesn't get Apple into compliance.
The closest to that might be to try to fulfill 6d) by including a download link in the App Store description, but I do not offer any legal advice here (not that I could anyway), and in particular not whether you placing the link that the shows up on Apple's side counts as Apple "offering access", nor whether linking to your server counts as "equivalent access" to an App Store download.
And I certainly don't know what Apple's opinion will be on you doing that.