Unity's Open-Source Double Standard: The Ban of VLC

Well, TBH it didn’t have the impact I thought it might (and that RMS feared — obviously I disagreed with him). Libraries qua libraries aren’t distributed / sold so much any more as standalone packages and now we mostly have no-cost binary blobs tied to hardware or a priced API or MIT-ish-licensed stuff (like boost or npm), sadly neither of which empower any right to repair.

That decade of Cygnus was a lot of hard yakka first to legitimize the idea of free software at all (in 1989 it was mostly both obscure and insane outside academia) and then popularize it. Obviously other people started working hard on this too later in the decade.

The thing that made probably the most significant difference was the process of forking gcc which was a lot of negotiation — at that time forking a code base was widely considered a tragedy, despite the whole structure of free software!). Making forking good rather than a tragedy, coming up with an independent steering committee, and in that case getting the FSF to stop complaining decide to try to run out in front of the parade* was really hard but in the long term it became an approach that most important open source projects have taken, providing stability and progress. That’s definitely been an opment!

And then within a few years…I was on to other, more important things. It felt like the free software / open source world was no longer an embryo so didn’t need me. Plenty of other people are doing great work, better than I would have the enthusiasm for these days.

* Yes yet another case where RMS was furious about something that in the long term was a big win for the FSF too.

It's basically the HN equivalent of "Well, when I first created the Earth in 7 days I didn't really imagine..."

> I've never understood the problem with (L)GPL code on iOS devices. Sure, users don't have the possibility to replace the code on that platform. But the restriction is not imposed by the people distributing the code, but by external circumstances (Apple).

In the case of the App Store, Apple is the one doing distribution, so Apple must also comply with the terms of the license (in addition to the app developer). Apple has decided they will not do that (that is, people they distribute to will not have the ability to modify the LGPL code, relink the final executable, and run it on their devices), so Apple cannot legally distribute binaries that contain LGPL code.

It only makes sense, then, that Apple should preemptively reject apps that link in LGPL code, as they know that they will not abide by the licensing terms.

> If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store.

That's not permitted by the license. The (L)GPL prohibits a third party from adding extra conditions to exercising the rights granted in the license. "Pay Apple for a developer account and get their permission" is an extra condition. Even if there is a jailbreak-y method of getting around the extra conditions, I don't think that would fly.

> Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons.

Agreed, but I'm not convinced this is one of those cases.

Within limits, all it takes to get the OK from Tim Cook is $99/yr to the Apple Developer Program. Which isn't $0, but the LGPL doesn't say someone else can't charge money to press the button. You don't get arbitrary code execution for those $99, but you get enough access to playback video. You'd have to create your own app and get it blessed by Apple in order to distribute it to other people, but doesn't that satisfy the letter of the law here? As a 3rd party developer with my own developer account, I can get the source and the object code and run my own binary that links against it on the same platform, iOS.

> I've never understood the problem with (L)GPL code on iOS devices

AFAIK Apple just doesn’t allow apps which don’t that on the app store regardless of how the developer would chose to interpret the license

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.

    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.

    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.)

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.

> I've never understood the problem with (L)GPL code on iOS devices. Sure, users don't have the possibility to replace the code on that platform. But the restriction is not imposed by the people distributing the code, but by external circumstances (Apple).

That seems very forest-for-the-trees. It's true, but it mistakes a micro-statement of a problem (the app vendor isn't "at fault" for the LGPL violation) with the actual problem (copyleft code of any kind is effectively impossible on the most popular mobile platform in the industrial world).

The bottom line is that it's not possible to distribute a binary containing *GPL code on iOS in any way remotely in keeping with the letter of the license. People do it anyway because this code is important and useful. But Apple has effectively banned the license and that's always going to lead to friction like this.

This discussion has reminded me why I stopped using LGPL and started using MPL for libs. OWN THE LIBS… I mean share them. Share the libraries.

The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL.

If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point.

MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.

Dynamic linking will result in a program in memory at runtime that is under the copyleft terms.

The separate pieces on disk are of course as you say.

I thought that the license for B says you can't distribute it along side A.

Not that copyright propagates.

Obviously, a zip archive containing A and B is a derived work of B. Hence, license of B can say you can't distribute such works.

Does distributing A without B make any sense?

Using open source development tools is fine. What matters is what you distribute to end users (i.e. the output of those tools). I think the issue with unity is that VLC ends up being distributed as part of unity applications.

I'm not a lawyer but this might indeed have some valid issues associated with it depending on how this is done. So, I can see an argument for Unity simply not wanting to put their customers in a situation where they have to worry about these issues. It seems a bit drastic though given how useful it is.

Banning companies/accounts seems like it's simply unprofessional/rude and unnecessary. Sounds like they need to have a conversation with whomever thought that was a good idea about professional conduct.

So I could be missing something, but the editor itself is not getting shipped to iOS devices, only the resulting binaries are.

The original was used, IIRC to license glibc when Steve Chamberlain and I (mainly him I’m pretty sure) were starting out on it — I think that was the motivation. You’re right: I’m not sure we actually shipped a glibc with that version.

This was long before we hired Drepper.

Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.

> Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code?

The freedom of the user to modify the library and use it was the most important part. It’s a fundamental “right to repair”.

FWIW the people involved were just me, plus John Gilmore who said “why not explicitly make dynamic linking automatically qualify?” which was obviously a good idea, and RMS who was bitterly opposed.

To me, CDDL/MPL 2.0-style licenses are much more sane than GPL based ones.

The definition of what is a derivative work is IMHO overreaching in GPL based licenses.

IANAL but you identified the core issue. I'm having trouble finding precedent for this, mainly because private businesses are legally allowed to choose who they do business with, which can be a form of legally protected discrimination.

The closest thing I found is the 2023 Students for Fair Admissions v. Harvard Supreme Court decision which effectively ended affirmative action in the US, since Harvard is a private college "doing business with" its students (customers):

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

https://www.scotusblog.com/2023/06/supreme-court-strikes-dow...

SCOTUS said that race/ethnicity and gender identity are protected classes, so discriminating by them is illegal, meaning that affirmative action can't legally be imposed on universities anymore.

Now, there are extenuating circumstances with that due to the US's civil rights battles and entrenched practices in other areas like policing and access to capital which impose additional struggle on individuals, depending on which protected classes apply to them. So throwing out affirmative action may give individuals unaffected by those practices an additional advantage (privilage). Meaning that the court's decision may have an effect opposite to the one intended, as stated by the dissenting justices. I'm providing this for context, because it's an example of how the letter of the law can be in conflict with the spirit of the law.

As a private entity, Unity must still follow federal antidiscrimination laws. It's not allowed to remove an app from its store based on the race/ethnicity/gender of its author(s) for example.

But prominance/budget and potential liabilities from lawsuits by intellectual property trolls are not protected classes. Currently Unity appears to be free to de-list any app for any reason outside protected classes.

But that discriminitory freedom is also being challenged for antitrust reasons. If a store is dominant to the point that competitors are not widely known by the mainstream, then any type of discrimination could potentially become collusion. For example if Apple delisted an app that competed with its own in order to noncompetitively boost its own sales, then that can be challenged in court. And two or more companies collaborating to remove competing apps in each other's stores can also be challenged in court.

The realities of software development are daunting. It often takes many years of work by countless individuals and budgets in the multiple thousands or even millions of dollars to ship an app. The libraries which the app relies upon are also unique in that an alternative may not be available, either for budgetary reasons around refactoring or for compliance with controversial laws like the DMCA. So an app's dependencies and licenses could be thought of as an ethnic identity for software because they can't be changed in practice. It's what they are.

Main takeaways:

1. A unilateral ban of an app by a company can represent a power imbalance resulting in injustice because the guidelines the app must follow to regain entry are not tenable. In other words dependencies, licences and other nonfungible aspects of software may need to become protected classes.

2. Is the law being applied unequaly between VLC and other apps with LGPL dependencies, or with preferential treatment?

3. What recourse do developers have other than to sue? Will their case have merit? Are there financial barriers and opportunity costs to such actions? The realities of such recourse can impose such hardship on injured parties that their involuntary surrender represents a kind of injustice that favors moneyed parties.

Keywords and avenues to pursue:

unequal application

preferential treatment

protected class

Would lawsuits against other companies along these lines reduce productivity in the tech sector by making it more difficult to do business, highlighting a need to reform legislation around this issue?

Not really. They could just distribute things anyway, and simply invoke the license-termination clauses as soon as any infringement is detected by claimants - similarly to how (I expect) they would treat claims of copyright infringements on game assets.

They are just being obtuse - which looks fishy when coupled with VLC's claims that they wouldn't allow them back in even if all LGPL code was removed. They probably don't want competition for some component.

I'd say it is even debatable whether Unity is really re-distributing in the sense of the LGPL or merely hosting. Redistribution is something between licensor and licensee, your web hoster or your telecom is not involved.

But I guess that's another thing they don't want to test in court and it's easier to say they don't want it.

I think your guess is correct. GPL/LGPL is a contract that puts certain obligations on all parties; just by being a redistributor, Unity now becomes a party to a contract they never signed or even intended to sign.

It's easier for them to refuse to be a party to that contract by not allowing any software under that license on their property to begin with.

> there are technical barriers (code signing, DRM) that get in the way of an end user being able to exercise their right to replace LGPL components with modified versions

I wonder if that is an issue for LGPLv2. Pretty sure that for LGPLv3, the distributor would have to give instructions explaining how to do it (which they could not do), but LGPLv2 does not require that, right?

As in, wouldn't code signing and DRM count as some kind of tivoization?

LGPL is a regular license, it is not a viral license.

GPL is a viral license.

The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls. If LGPL had been a viral license too, all programs would have been affected.

At the risk of seeming pedantic, the proper term is copyleft, not viral licensing. If memory serves, viral licensing has its origins in Microsoft fear-mongering (predating the modern positive use of viral, as in go viral).

> LGPL doesn't impose combined redistribution requirements, does it?

It does, in that if you modify the source-code of an LGPL-licensed library and distribute the binary, you are required to also distribute the source (i.e. the source of your modified version). Your modified source must also use the LGPL licence.

If you distribute an unmodified binary for an LGPL-licensed library, you must also provide access to the unmodified source. (This isn't to say you need to bundle it into the same archive file.)

It differs from the vanilla GPL in that an LGPL-licensed library permits you to dynamically link to it from application code that doesn't need to use any particular licence.

(This is at least the gist of the matter as it applies to application code. This isn't legal advice, I'm not a lawyer, etc.)

See the final point on this page from the FSF (authors of the GPL and LGPL) - https://www.fsf.org/bulletin/2014/fall/common-gpl-misconcept...

What you say is not correct.

Only linking with a GPL library makes GPL applicable to the whole program.

This is the difference between LGPL and GPL. LGPL is a normal license that applies only to the library.

Since glibc uses LGPL, if your theory had been true than almost all programs run on a Linux system, regardless of their origin, would have been covered by LGPL.

> With an LGPL asset now you have to let customers be able to edit that addon and rebuild your game

> so now your game code is also under the LGPL and you have to publish your game code.

AFAIK, that's only true of the GPL, not the LGPL.

I would wage against it. It's as shitty as Blockbuster. No reason they won't end up selling for peanuts

> I'm curious, does the LGPL state explicitly that the licensor guarantees that the licensee can excercise their granted rights in practice?

It feels like such a requirement would mean you would have to test each potential user for technical skills to determine if they are capable of doing the things that you are giving them the right to do.

I think you are looking at it the wrong way. The licensor doesn't guarantee that the licensee can exercise the granted rights. But the license requires that the distributor can guarantee that the recipient can exercise those rights.

If I write up a license that says anyone distributing my software must give the recipient the right to drive a tank on their property, I can distribute it, because I am the copyright holder and can do whatever I want. But in practice that software cannot be redistributed, because those license terms probably cannot be fulfilled by any redistributors.

If VLC wants to put something on the Unity Store that includes LGPL code, then their responsibility (and the Unity Store's responsibility, as they are now distributors as well) is that people downloading that Unity VLC bundle in order to use it in their game must be able to replace the LGPL code in it with modified versions. And that part may actually be possible, so this may be ok.

But then the game developer that uses the Unity VLC bundle must also pass along the ability to their end users (that is, the people that buy and play their game, for example) to replace the LGPL code with modified versions. I think that's just not possible with the Unity Store model[0], so the terms of the LGPL cannot be fulfilled.

If this is the case, it's not unreasonable for Unity to ban LGPL code in bundles, because they know that their customers (game developers) will not be able to abide by the terms of the license.

[0] Similarly to how an end-user wouldn't be able to replace LGPL code in an iOS app with a modified version and then run that on their iPhone, at least not without paying Apple for the privilege, which is an added restriction that violates the terms of the LGPL.

IANAL, but when it comes to contracts/licences, intent, good faith and fair dealing are important. Allowing someone a right that you know cannot be exercised would likely fail under all three of those. Your intent is not for them to have that right, you're not acting in good faith in claiming they have the right and you're misrepresenting the possibility.

The law is not as prescriptive on the exact text as many programmers think. What typically matters in court is what people mutually understand/understood terms to mean, and clear attempts to mislead are typically judged against the one doing the misleading.

So, yes, if it went to a court that was otherwise supportive of (L)GPL, providing (L)GPL code on a platform on which users certainly cannot exercise their rights would likely be a failure to provide and hence abide by the licence.

You're right, but there is the large counterpoint of the fact that Unity is doing exactly that for other software licenced under the LGPL.

LGPL leverages copyright and is triggered under distribution/copying. Users of a multitenant system are not receiving a copy of anything. At least this is how GPL2 worked. I don't know if 3 substantially changed that.

What you're describing sounds more like the AGPL to me.

If that were true, then if Unity decided to ban MIT and Apache licensed software from the store, that would mean that MIT and Apache are actually kinda shit. Seems there's a pretty clear error in your logic.

Also, your appraisal seems to be assuming that the only goal of the GPL/LGPL is to release software through Unity, which is not correct.

The issue is with locked down appstores, your inability to exercise your freedoms given by the license is caused by the store not the software.

Thank goodness there are oracle licenses to save you. :)

Without those you would be suffering NT servers, IIS and ActiveX.

Right, sorry, forgot that. Edited!

"$$$$$$$$$$$$$$$$$$$$$$$"

The CEO has been fired since then.