Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Please correct me if I am wrong here.

From my understanding, using LGPL v2 code in console releases is fine since v2 does not have a tivoization clause (i.e. even if the end-user cannot re-link the program because the platform is locked down, that's still ok).

However, websockify.js (and perhaps other dependencies) are LGPL v3, which means they cannot be included on a platform like the Nintendo Switch as the end-user cannot replace that component.

Is Unity excluding such components on locked down platforms, or are they simply in violation of LGPL v3?



> Please correct me if I am wrong here

Will do! :-) The good news is that what you got wrong is something that probably 99% of people get wrong about *GPLv3: the scope of the Tivoization clause.

The Tivoization clause was written quite narrowly to stop what Tivo was doing, which was selling a device with a locked down OS that includes *GPLv3 software. It applies if and only if:

1. the software is conveyed in a "User Product", and

2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.

A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.

For the Nintendo Switch it means that Nintendo cannot include any *GPLv3 software in the Switch itself or in anything that comes with the Switch when you buy it.

Add on software that you obtain and install later, including software sold by Nintendo through their online store or on physical media, is not covered by the Tivoization clause. As far as the Tivoization clauses goes there is no problem with Unity including *GPLv3 code for any locked down platforms they use and for any developers who use Unity to write games for those platforms.

Where there might be a problem is with other parts of *GPLv3. For example when software is distributed through app stores such as Apple's or Nintendo's and you buy that software it is Apple or Nintendo that is making and distributing the copy that you download. That's fine because they have permission from the copyright owner.

But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering. That violates *GPLv3. If the owner of the copyright owns the copyright on all the code they used they can grant Apple or Nintendo a license that allows the distribution.

If they have included some third party *GPL library in the app or game and the third party has not granted such a license to the store owner then that app or game cannot be distributed on that store.


The GPLv3 does not stop what Tivo actually did, and both GPLv2 and GPLv3 do stop what became known as Tivoization (preventing modification).

What Tivo actually did was break their proprietary software when you modified the GPL parts of the system.

Some related links:

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...


> But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering.

LGPL has it a requirement that the application needs to be distributed in a form where you can replace and modify the LGPL bits. Either via dynamic linking or separately-distributed object files. I'm not sure how you could be considered in compliance with this when the development environment for consoles is an expensive devkit you have to sign an agreement for and the SDK/APIs etc are trade secret. At the very least, I imagine a court would take a very dim view of "well we technically shipped object files in this encrypted container that you can't read or Nintendo will sue you up the ass".

If Unity didn't get an exception license for their LGPL bits, then them and pretty much every indie dev that has shipped on console is violating the license. Bonus points for the fact that the termination clause on *GPLv2 is basically one-strike-and-your-out, so they would have to individually go to each LGPL library Unity touched and beg for forgiveness before ever using those libraries ever again.

On iOS, any iCloud account can get a development profile set up to build and run code signed for your device. And on the App Store you can write custom EULA language that says "any activity required to exercise your rights under LGPL is explicitly allowed, App Store TOS not-withstanding." The biggest problem is just getting access to the object files and assets in order to relink the app. iOS application binaries are encrypted, and app bundles, while not encrypted, are a pain in the ass to get a copy of on a real desktop OS where the developer tools can run. For a fully FOSS app, you can just link to a Git repository to satisfy the GPL copyleft, but I doubt proprietary developers want to distribute a whole unlinked copy of their code just so you can link it in.

There was a problem with VLC on iOS a decade ago, but it mainly has to do with the fact that Apple wants team accounts to be verified with DUNS numbers. VLC is a nonprofit, which apparently made it a pain in the ass to get a DUNS number; but that was fixed a long time ago and VLC is on the iOS App Store.


No, you're right. Here's the best "article" I can find about this at the moment:

https://opensource.stackexchange.com/questions/7387/what-is-...

(copy paste from a dead link.)

Apple has the same problem as unity. Try this on a mac:

   % bash --version
   GNU bash, version 3.2.57...
   Copyright (C) 2007 Free Software Foundation, Inc.
They can't upgrade bash past 3.2 (which is the last GPLv.2 release), so they're maintaining an ancient version themselves (it's old enough to smoke + vote + go to war in the US!), and they're trying to get users to switch to zsh.

I looked at the LGPL 2.1, and the "or later" bit of the license is weird. Users can convert it to any version of GPL >= 2.1 at their discretion. However, the author of the library needs to specify LGPL (= any version), LGPL 2.1 (= exactly 2.1), or (recommended) "LGPL 2.1 or later" in a COPYING file.

Unity says they "deprecated" LGPL code. That makes sense unless the code pins the LGPL version. Upstream LGPL vendors could rug-pull them, bash-style, at any moment.

However, VLC's libraries are listed as "LGPL 2.1 only" here, so they explicitly claim they cannot rug pull (unless they jump to GPL3 -- that wouldn't be too surprising, since most of their stuff is AGPL, though it'd probably cause a fork):

https://code.videolan.org/explore/projects/starred

Except VLC didn't incorporate the license properly (COPYING and COPYING.lib don't say if they pin LGPL versions), and their README.md says:

> libVLC, the engine is released under the LGPLv2 (or later) license. This allows embedding the engine in 3rd party applications, while letting them to be licensed under other licenses.

https://code.videolan.org/videolan/vlc

So, Unity's probably right to be worried. "or later" includes v3, which is specifically incompatible with stuff like anti-cheat technology and consoles.

However, my best guess is that Unity's worried about pissing off third parties that have patents on the algorithms VLC implements, and they use the LGPL thing as an excuse to avoid revealing the details of those private deals.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: