[HN Gopher] Unity's Open-Source Double Standard: the ban of VLC
___________________________________________________________________
Unity's Open-Source Double Standard: the ban of VLC
Author : cempaka
Score : 453 points
Date : 2025-05-07 12:33 UTC (10 hours ago)
(HTM) web link (mfkl.github.io)
(TXT) w3m dump (mfkl.github.io)
| mouse_ wrote:
| Big companies hate GPL
|
| No surprise here
| diggan wrote:
| But they still use libraries under GPL themselves:
|
| > It gets better... Unity itself, both the Editor and the
| runtime (which means your shipped game) is already using LGPL
| dependencies! Unity is built on libraries such as Lame,
| libiconv, libwebsockets and websockify.js (at least). Full list
| of open-source Unity dependencies here.
|
| So what they hate seem to be "publishers and Unity users using
| GPL libraries", not using it themselves.
| HenryBemis wrote:
| Nothing wrong to use someone else's work to make money for
| yourself. Plenty wrong to use someone else's work to make
| money for others.
|
| Oversimplification I know.. but.. right?
|
| The Ferenghi would be proud of Unity!
| bitmasher9 wrote:
| GPL/LGPL is more about treating users fairly than not
| making money. It's just that most software companies
| exploit their users to various degrees.
| matheusmoreira wrote:
| Open source is just the transfer of property and capital
| from well meaning developers straight into the pockets of
| corporations and billionaires. Developers are well advised
| to always apply the AGPLv3 to everything they make. It's
| either AGPLv3 or all rights reserved, everything in between
| makes no sense.
|
| https://zedshaw.com/blog/2022-02-05-the-beggar-barons/
|
| > To the Beggar Baron, open source's value is its free
| donation.
|
| > You would never stand on the street and offer to buy the
| wallets off people who are about to donate a few dollars to
| you.
|
| > That'd be stupid. They're _giving_ you their money for
| free. Take it and run.
| kragen wrote:
| Your comment makes no sense: first it attacks "open
| source" with derogatory language, then it strongly
| recommends using a certain open-source license, and then
| it returns to attacking "open source" with derogatory
| language pasted from a clueless blog post by a plonker
| renowned for his clueless rants.
| Dylan16807 wrote:
| It makes sense when you add the fact that 99% of open
| source is not AGPL. Criticizing "open source" is slight
| hyperbole.
| matheusmoreira wrote:
| Free software and open source software are not the same.
| AGPLv3 is not an open source license, it is the strongest
| copyleft free software license available at this point in
| time.
|
| https://www.gnu.org/philosophy/open-source-misses-the-
| point....
|
| https://www.gnu.org/philosophy/words-to-avoid.html
|
| And it's hard to disagree with the clueless guy when what
| he says is happening keeps happening.
|
| https://twitter.com/FFmpeg/status/1775178803129602500
|
| https://twitter.com/FFmpeg/status/1775178805704888726
|
| https://trac.ffmpeg.org/ticket/10341#comment:4
| kragen wrote:
| Those libraries are under the LGPL, not the GPL, which is a
| huge difference in this context.
| diggan wrote:
| Ah, you're very right, I misread it somehow when I first
| came across it... Thanks for the correction!
| Dylan16807 wrote:
| I'm assuming mouse_ was including LGPL when they said GPL
| because otherwise their comment has nothing to do with the
| article.
| zorgmonkey wrote:
| libVLC the library is LGPL licensed, VLC the application is
| GPL licensed. This plugin was of course just using libVLC
| so it being GPL was not the issue. As you said several
| other libraries unity uses are also LGPL licensed.
| tempfile wrote:
| It's the LGPL, not the GPL. Huge difference.
| badgersnake wrote:
| This is about the LGPL, which is a very different licence. I've
| not heard of it causing any problems. Glibc is licensed in this
| way, everything uses that.
| kragen wrote:
| The LGPL is a very different license, but glibc is not
| licensed under it, nor under the GPL.
| actionfromafar wrote:
| Someone should update this then. Isn't glibc the poster
| child for LGPL? https://en.wikipedia.org/wiki/Glibc
| pmontra wrote:
| It's got a number of different licenses for it's various
| components. LGPL 2.1 is among them.
|
| License file at https://sourceware.org/git/?p=glibc.git;a=b
| lob_plain;f=LICEN...
|
| Source at https://sourceware.org/git/?p=glibc.git;a=summary
| badgersnake wrote:
| That's not what it says here:
| https://www.gnu.org/software/libc/#license
| rawling wrote:
| [2024]?
| Alifatisk wrote:
| (2024)
| tokai wrote:
| No surprise here. Unity is such a horrible company.
| adzm wrote:
| Interesting 5.10.4 does not seem to exist in the provider
| agreement? https://unity.com/legal/provider
|
| At one point this used to contain the clause:
|
| > 5.10.4 Provider represents and warrants that its Assets shall
| not contain (a) any software licensed under the GNU General
| Public License or GNU Library or Lesser General Public License,
| or any other license with terms that include a requirement to
| extend such license to any modification or combined work and
| provide for the distribution of the combined or modified
| product's source code upon demand so that Customer content
| becomes subject to the terms of such license; or (b) any software
| that is a modification or derivative of any software licensed
| under the GNU General Public License or Library or Lesser Public
| License, or any other license with terms similar thereto so that
| Customer content become subject to the terms of such license.
|
| However this was removed sometime between December 3rd and
| December 12th according to the Wayback Machine.
| daveoc64 wrote:
| The post is over a year old (January 2024).
| red_trumpet wrote:
| The relevant email is even dated 31st of August 2023.
| axus wrote:
| Looks like it was moved into the "Submission Guidelines 1.2.b"
| linked from 5.10.1:
|
| https://assetstore.unity.com/publishing/submission-guideline...
| jdlyga wrote:
| Clearly, the legal team got bad information and made it part of
| their agreement. Like the article says, not only do tons of Unity
| assets use LGPL dependencies, but Unity uses LGPL assets
| themselves. Even shipped games created using Unity use LGPL
| assets. The intent was probably only to screen out GPL
| dependencies. For those who don't know, there's a huge difference
| between the GPL and LGPL. The LGPL is specifically designed to
| allow proprietary applications to link to open-source libraries
| without requiring the proprietary application's source code to be
| released, provided certain conditions are met. This is
| particularly true when the LGPL-licensed library is used in a way
| that allows users to modify or replace it independently of the
| proprietary application.
|
| In contrast, the GNU General Public License (GPL) has stricter
| requirements. If your software incorporates GPL-licensed code,
| the entire derivative work must also be licensed under the GPL,
| which includes releasing the source code.
| zoobab wrote:
| "but Unity uses LGPL assets themselves."
|
| So Unity will ban itself?
| armada651 wrote:
| As the devil's advocate I'd like to argue that legal is
| probably more comfortable with Unity's own use of LGPL
| libraries, because they can ensure that Unity only links
| dynamically to those libraries. And given how critical these
| dependencies are to the engine, legal is willing to take the
| "risk" of allowing LGPL dependencies.
|
| The ban of LGPL in assets on the asset store is probably due
| to legal being concerned that someone would publish an asset
| that statically links to an LGPL library and that it would
| allow anyone to demand the source/object code of any Unity
| game that uses that asset.
|
| Legal probably sees it as too much effort to vet every asset
| to see if it links correctly to LGPL libraries and simply
| instituted a blanket ban to simplify enforcement.
| phkahler wrote:
| >> The LGPL is specifically designed to allow proprietary
| applications to link to open-source libraries without requiring
| the proprietary application's source code to be released,
| provided certain conditions are met. This is particularly true
| when the LGPL-licensed library is used in a way that allows
| users to modify or replace it independently of the proprietary
| application.
|
| That requires the library to be dynamically linked. Not sure if
| that's in play here.
| jcelerier wrote:
| It does not. https://www.gnu.org/licenses/gpl-
| faq.en.html#LGPLStaticVsDyn...
| Epa095 wrote:
| This is the relevant part: >If you
| statically link against an LGPLed library, you must also
| provide your application in an object (not necessarily
| source) format, so that a user has the opportunity to
| modify the library and relink the application.
|
| And is this easy? I don't know much about how this works,
| but would it be trivial for unity to distribute a version
| of unity with statically linked LGPL libraries where you
| can also easily relink?
| voxic11 wrote:
| I wouldn't call it completely trivial at the scale and
| complexity of something like unity, but its certainly
| possible.
| phkahler wrote:
| In practice it's probably easier to dynamically link the
| library.
| arka2147483647 wrote:
| I think you would find it very difficult to find even a
| single game which has done this.
| Maxatar wrote:
| It's as easy as building the project in the first place.
| Anytime you build your application you also build the
| object files for it as well.
|
| As an end user having to take those object files and
| relink them can be difficult for sure, but that's not
| something the distributor has to do. The distributor
| simply has to provide some additional files that their
| build process will already produce.
| Sophira wrote:
| Of course, those build files won't be stripped, meaning
| that it would be easier to reverse-engineer them - which
| might not be something the distributor wants.
| voxic11 wrote:
| It doesn't strictly require it to be dynamically linked but
| does place additional requirements on applications which
| are statically linked to LGPLed libraries.
|
| > If you statically link against an LGPLed library, you
| must also provide your application in an object (not
| necessarily source) format, so that a user has the
| opportunity to modify the library and relink the
| application.
| jsiepkes wrote:
| > The LGPL is specifically designed to allow proprietary
| applications to link to open-source libraries without requiring
| the proprietary application's source code to be released,
| provided certain conditions are met.
|
| It's not that simple. The LGPL says that one must basically be
| able to make modifications to the opensource library, rebuild
| the library and be able to reintegrate this new library in the
| existing application. And you, as a developer using an LGPL
| library, need to make this "possible". What this practically
| means, is open to interpretation. This is also why lawyers (and
| companies) don't like the LGPL, because it contains even more
| of this "open to interpenetration" text than the GPL.
| torginus wrote:
| Afaik not necessarily. You migh make modifications to the
| LGPL library (such as changing the API) and then use that in
| your proprietary app.
|
| Although the modified library would still be LGPL, it would
| be both practically useless to everyone on the street, and
| unfortunately the (L)GPL doesn't even specify how you must
| share the source. It's perfectly legal to say 'send us a
| request and we email you the modified sources'
| Scaevolus wrote:
| No. Read the license.
| https://www.gnu.org/licenses/lgpl-3.0.en.html
|
| "4. Combined Works.
|
| You may convey a Combined Work under terms of your choice
| that, taken together, effectively do not restrict
| modification of the portions of the Library contained in
| the Combined Work and reverse engineering for debugging
| such modifications, if you also do each of the following:
|
| - d) Do one of the following:
|
| -- 0) Convey the Minimal Corresponding Source under the
| terms of this License, and the Corresponding Application
| Code in a form suitable for, and under terms that permit,
| the user to recombine or relink the Application with a
| modified version of the Linked Version to produce a
| modified Combined Work, in the manner specified by section
| 6 of the GNU GPL for conveying Corresponding Source.
|
| -- 1) Use a suitable shared library mechanism for linking
| with the Library. A suitable mechanism is one that (a) uses
| at run time a copy of the Library already present on the
| user's computer system, and (b) will operate properly with
| a modified version of the Library that is interface-
| compatible with the Linked Version."
| em-bee wrote:
| if your application contains LGPL code then as a user of
| your application i must be able to make changes to that
| LGPL code. that means i need either the code of the whole
| application or at least object files and infrastructure so
| that i can relink my changed LGPL code to your application.
| Maxatar wrote:
| >at least object files and infrastructure so that i can
| relink my changed LGPL code to your application.
|
| This part is true but I'd like to emphasize that the
| infrastructure is on the user to acquire. The distributor
| of the application is not required to make that
| infrastructure available.
| em-bee wrote:
| i am not sure about that. isn't it required that i get
| everything needed to rebuild the application? if it's a
| standard compiler, sure. but any config files,
| nonstandard tools to link, say if the non-LGPL part is
| written in an inhouse language with a non-public compiler
| and linker, you still need to give me the tools to relink
| the objects. i mean that's very unlikely to happen, but
| if it does, those tools need to be shared.
| Maxatar wrote:
| Yes that's true, if it's a non-public compiler, linker,
| operating system, or whatever... then the source code for
| all of those need to be provided.
| em-bee wrote:
| not the source code, but binaries that can run on the
| same target machine.
| Maxatar wrote:
| The license specifies that it must be the source code.
| Binaries are not sufficient.
| nightpool wrote:
| > What this practically means, is open to interpretation.
|
| Is it? It seems very straightforward to me--just use a DLL.
| The LGPL even says explicitly that it's fine as long as you
| use a shared library.
|
| The situation gets trickier for Android or Xbox games I
| guess. I'm curious how Unity complies with the LGPL
| provisions there. But for any normal desktop platform this
| should be trivial to comply with.
|
| EDIT: ah, upthread they mention this is only a provision for
| the LGPLv3. I would expect that the LGPLv3 is pretty rarely
| used for this reason.
| reverius42 wrote:
| "Just use a DLL"
|
| Like you say, it gets trickier for Android, or Xbox games,
| or...
|
| iOS, which requires each library binary to be signed by the
| publisher, or...
|
| Rust or Go, which encourage static linking of all
| dependencies...
|
| These days a "normal desktop platform" is really a minority
| of software.
| jmull wrote:
| I don't know much about the way unity apps are distributed, but
| I'd be a little surprised if they are only intended to be
| distributed in a way that satisfies LGPL.
|
| I would have thought, e.g., that apps distributed only through
| stores to platforms that require apps to be signed could not
| contain LGPL components, since you would not be able to modify
| the LGPL components. (Maybe it would be OK if the software was
| available for download freely and side loading wasn't too
| difficult??? IDK.)
|
| Legal specifics aside (IANAL after all), my general point is
| that despite being more flexible than full GPL, LGPL is still
| pretty restrictive. Proprietary software generally may need to
| keep things simple or be careful (probably including consulting
| an attorney with the relevant expertise) to ensure they are
| compliant.
|
| In that light, I can see why Unity would disallow LGPL
| software. It's not that it couldn't be done properly, but that
| it's probably not feasible to do a proper legal review of every
| asset added to the sure (not for Unity and not for the asset
| providers).
| roblabla wrote:
| > I would have thought, e.g., that apps distributed only
| through stores to platforms that require apps to be signed
| could not contain LGPL components, since you would not be
| able to modify the LGPL components. (Maybe it would be OK if
| the software was available for download freely and side
| loading wasn't too difficult??? IDK.)
|
| IIRC, That's a difference between LGPLv2 and LGPLv3 - LGPLv3
| has the same anti-tivoization clauses that GPLv3 has - while
| LGPLv2 does not. So afaict, it's totally OK to distribute
| software in ways that does not allow the user to modify the
| library when that library is licensed LGPLv2.
|
| VLC is licensed under LGPLv2.1, which is not subject to the
| tivoization clause.
| voakbasda wrote:
| > So afaict, it's totally OK to distribute software in ways
| that does not allow the user to modify the library when
| that library is licensed LGPLv2.
|
| Legally that might be true, but that interpretation stands
| directly opposed to the intention of the license. In that
| light, it is unambiguously unethical to use that loophole.
| socalgal2 wrote:
| Plenty of projects intentionally stay on older GPL
| licenses because they want that permissiveness.
| Pxtl wrote:
| Doesn't that mean the anti-tivoization clause makes LGPL3
| software unusable on most mobile platforms since they're
| all fixated on signing libraries?
| notpushkin wrote:
| I don't think so, at least on Android. If you replace a
| library in an app, you just sign it with your own keys.
| giancarlostoro wrote:
| > require apps to be signed could not contain LGPL
| components, since you would not be able to modify the LGPL
| components.
|
| You COULD make the changes, but you MUST keep the changes to
| the LGPL'd software made available in some way. This is not
| going to affect the rest of your project, only the LGPL'd
| library. I think not including any private keys or signed
| files will still satisfy the LGPL as long as any code changes
| you made are included. I don't think configuration that
| compromises your security is within scope, and I'd feel like
| RMS would agree there.
|
| Its really interesting the goal of the LGPL is to allow for
| LIBRE libraries to exist where there's proprietary components
| that already do a solid job, so in order to convince people
| to use GPL / LGPL tools / libraries it was thrown in that
| umbrella.
|
| The FAQ is worth a read every now and then, you get a feel
| for what is intended in plain English.
|
| https://www.gnu.org/licenses/gpl-faq.html
| dwaite wrote:
| I believe the GP is referring to the LGPL requirement that
| users be able to replace LGPL components with modified
| versions.
|
| Being able to replace subsystems of a signed application
| with arbitrary third party code adds complexity and is a
| security risk, but is a requirement of the LGPL.
| dcow wrote:
| I think modernity has complicated things. The proprietary
| vendor signing all the binary components to prevent
| tampering is different from the platform package manager
| and kernel requiring signed packages/pages. If you have
| the proprietary blob and a bunch of modified third party
| dynamically loaded components, you (or the platform) can
| re-generate your own signature over the modified
| composition to execute it in {context that requires
| signed code execution for security/integrity}. The LGPL
| is addressing the former. I don't see a spirited problem
| with the latter.
| ack_complete wrote:
| That Unity itself or Unity-based games use LGPL components
| doesn't matter. What matters here is what is allowed on the
| Unity Asset Store. There is nothing requiring Unity to allow
| everything on their Asset Store that could be linked into a
| Unity game, and apparently at the time, the Provider agreement
| simply said: you can't sell LGPL assets on the store.
|
| It isn't surprising or unreasonable that the Store might have
| additional requirements, and there are plenty of reasons to do
| so. One is Unity limiting their risks as a distributor of
| third-party content. Another is that the Unity Asset Store does
| not require assets sold to be used with Unity, and for some
| assets it can be allowed depending on the specific asset's
| license:
|
| https://support.unity.com/hc/en-us/articles/34387186019988-C...
|
| On the other hand, not enforcing the LGPL rule evenly against
| other assets also currently being distributed with LGPL
| components, on the other hand, is more problematic.
| thegrim33 wrote:
| Every thread about software licenses always devolves into a
| firehose of debate and conflicting beliefs. How, in 2025, are
| we still in a state where, on HN of all places, nobody has any
| idea what the specifics of LGPL really means or how it has to
| be implemented? How is it so convoluted, confusing, and up to
| interpretation?
|
| There's demonstrably room for innovation here - coming up with
| some new system that actually makes sense, that people can
| actually understand. I suppose there's licenses like MIT that
| fall in that bucket. Everyone is pretty clear about something
| like the MIT license. But the various GPL licenses and other,
| more custom/convoluted licenses ideally need to be replaced by
| something much better.
| kelnos wrote:
| > _But the various GPL licenses and other, more custom
| /convoluted licenses ideally need to be replaced by something
| much better._
|
| What, though? I expect that people with a greater
| understanding of copyright law and how to write legal
| documents, have tried and failed. The GPL, LGPL, the Affero
| variants have specific goals around keeping software open. I
| don't think writing a license to achieve those goals can be
| simple or straightforward.
| dcow wrote:
| It's because the genesis of these convoluted license terms is
| rooted deeply in the archaic copyright law in the US. Until
| that is fixed, these legal hacks will be necessary.
|
| If you're not pushing an agenda, you have the public domain
| or the unlicense as options completely simple understandable
| options.
| belorn wrote:
| That is legaleze for you, and it not at all surprising that
| we are still discussing how such a text should be
| interpreted. Its mostly impossible to create a legal text
| that has unchanged interpretation for several decades, or
| centuries for that matter. Just look how courts often
| discussion the interpretation and enforcement of specific
| laws, even laws that are older than the judges themselves.
| nightpool wrote:
| > Everyone is pretty clear about something like the MIT
| license
|
| I don't think this is really true. I think people are often
| upset or surprised when their MIT-licensed programs are used
| in ways they don't agree with, or they reuse MIT-licensed
| programs in ways that violate their license terms (e.g. it
| takes many companies many, many years to realize they have to
| actually include a way for users to view copyright notices).
|
| Open source software is built on many different fuzzy notions
| of community and collaboration, encoded into an imperfect-
| but-legally-robust set of protocols that try to establish
| common language for people to build on. These protocols have
| proven very, very successful in encouraging collaboration and
| minimizing exploitation, but there's still a
| regularization/compromise process that's necessary so that
| everybody has a common ground to work from.
|
| For another perspective, think about them like security
| software--I personally might not know why TLS uses DH key
| exchange, or how it works, but if I threw it out in hopes of
| making thing simpler, things would probably go pretty badly
| for me when someone else notices.
| ttoinou wrote:
| I've read a bit this post and the gitlab repo link but I still
| have no idea if it's about having a VLC desktop player playing
| Unity assets / games, or a plugin for Unity to have a little VLC
| player inside the games.. or something else ?
| bayindirh wrote:
| It's more like allowing VLC media player inside the games,
| maybe as a cutscene player, or playing media via a control
| which players can interact with inside the game.
|
| I believe the gem lies in this sentence: "allowing (you) to
| build your own media-player based on VLC technology in Unity-
| based games".
| Telemakhos wrote:
| > The integration essentially was a bridge between the Unity
| game engine and the VLC multimedia engine, allowing to build
| your own media-player based on VLC technology in Unity-based
| games.
| m3kw9 wrote:
| They removed someone's entire app and they say "sorry for the
| inconvenience"
| zigzag312 wrote:
| I find popularity of LGPL licenses a bit weird.
|
| Allows:
|
| - Commercial use of the software
|
| - Commercial use of the source code for projects that run on the
| company's servers or internally
|
| - Commercial use of the library is allowed if dynamically linked
|
| Blocks:
|
| - Commercial use of the source code for local apps that run on
| user's device
|
| - Commercial use of the library if statically linked for local
| apps that run on user's device
|
| I would expect a licence like MPL to be more popular than LGPL.
| vinceguidry wrote:
| The GPLs don't concern themselves with commercial use. You can
| use GPL-licensed software for any application you wish, that is
| what software freedom means. It's just that if you do use
| copylefted free software, you must provide, free of charge, the
| source code of the software using it and any modifications
| made.
| zigzag312 wrote:
| If you run things on the servers/cloud (excluding more recent
| AGPL) you don't need to provide any source code.
| lupusreal wrote:
| If this weren't the case, then every web server running
| linux would have to offer their users the source code to
| linux. Seems pretty silly, probably _most_ software shouldn
| 't be AGPL.
|
| AGPL is best used by projects that want to offer dual
| licensing for a fee, so they can get corporations to fund
| their development.
| tmtvl wrote:
| Most software probably _should_ be AGPL licensed and its
| use is best for projects who want to protect what ought
| to be basic human rights which unfortunately aren 't
| enshrined in law.
| lupusreal wrote:
| Oh give me a break. What basic human rights are being
| violated by Linux being licensed with the GPL? GPLv3
| would be a nice improvement, but _human rights
| violations_ for it not being AGPL??
| Dylan16807 wrote:
| I'm not a huge fan of AGPL but I think being "silly" is
| the least of my worries. A few redundant github links on
| the about page is a small cost for getting open source to
| stay actually open in the era of cloud services.
|
| I do agree that it's "best" used in that kind of dual
| licensing, but I wish companies were less allergic to it
| so it _could_ be used in general purpose ways. (It or a
| lawyer-friendly alternative.)
| freeone3000 wrote:
| The freedom it was intended to preserve was the ability to
| modify the library and replace it, having your changes
| reflected in the application. Static linking breaks that
| freedom.
| zigzag312 wrote:
| Maybe that's why web apps have become more prevalent?
| detaro wrote:
| no.
| jeroenhd wrote:
| LGPL is pretty much the license for "if you use my code, you
| must also provide your customers a source copy of the same
| license, but if you ship a binary just let people know so they
| can ask me for the source".
|
| Users get the benefit of not having to keep a source code
| archive for compiled libraries every release, but still apply
| GPL restrictions and rights if you decide to copy code from
| within the library.
|
| If your customer is internal, that's not a problem. But
| realistically, internal tooling may as well be based on pirated
| and stolen code. How would anyone even find out?
|
| I think it has its charms. You can use the library as-is and
| everyone who cares can find the source code elsewhere (it's
| probably on github somewhere anyway), but you can't take it as
| a basis and alter it to make your own project out of it without
| keeping the product open.
|
| In the modern "everything requires HTTP calls to the network"
| era of software, AGPL may be a better solution for making sure
| the source code remains open, but for old-fashioned on-device
| apps there's a nice balance between freedom and obligations.
| lolinder wrote:
| The FSF has a whole article on why you'd choose GPL or LGPL
| [0]. In general they agree with you that LGPL is overused, but
| they do identify a few reasons why you might choose LGPL.
|
| That said, if the other option is something like MPL then I can
| think of a number of reasons why LGPL is better. At least LGPL
| ensures that modifications to your library itself remain free,
| whereas a more permissive license allows changes to be locked
| up entirely in a proprietary fork.
|
| [0] https://www.gnu.org/licenses/why-not-lgpl.en.html
| zigzag312 wrote:
| Doesn't MPL require to release any modifications made to the
| library itself?
| lolinder wrote:
| Oh, yes, I missed that! You're correct.
|
| It's still more permissive than LGPL in that it isn't
| 'infectious' even when statically linked, the license only
| applies to the source file, not to any derived work. That
| makes the requirements more straightforward but does limit
| the freedom of the user to dynamically swap the library out
| for one that they'd prefer.
| kragen wrote:
| Not if you put them in a new source code file, no.
| jenadine wrote:
| You're confusing "commercial" and "proprietary". Also LGPL
| doesn't block static linking with proprietary software, it just
| want that you allow the end user to replace the library with a
| modified version, and there are several ways to allow it.
| stackedinserter wrote:
| "just"
| firtoz wrote:
| Unity's lawyers continue killing the company, not a big surprise
| there.
|
| I used to work there, proud of their technical accomplishments,
| ashamed of pretty much everything else.
| jasonlotito wrote:
| It is amazing to me the commentary confusing GPL and LGPL on this
| site. The misinformation being spread about the LGPL, or just
| assuming the LGPL is the same as the GPL is mind boggling. I
| can't be to surprised, I guess. GPL happens after the L, and of
| course, we know GPL "doesn't allow commercial applications"
| right? So that's all we need to discuss.
|
| Seriously, it's just four characters, and doesn't take long to
| look up without just assuming it's the same as the GPL.
|
| The argument "the lawyers saw GPL in LGPL and just made an
| assumption" is all the more plausible when you have people in the
| field who make the same mistake.
| kragen wrote:
| The GPL does allow commercial applications. That's how we got
| Linux, nearly every embedded board support package ever, etc.
| jasonlotito wrote:
| I should have been more explicit by making it clear that part
| was sarcasm based on the comments I'm seeing elsewhere on
| this post. Apologies.
| jillyboel wrote:
| Unity is actually _permanently banning_ accounts for uploading a
| package that they decree has now been _deprecated_? What are they
| smoking?
| mcv wrote:
| Yeah, it feels to me like there's some other reason they
| dislike VLC that they're not telling. Does it compete with
| their own media player or something? Did the creator of VLC
| date a Unity exec's ex?
| simoncion wrote:
| > ...for uploading a package that they decree has now been
| _deprecated_?
|
| Unity appears to be using the term "deprecated" to mean
| "removed" or "deleted". This is a fucking stupid trend that I
| wish we would collectively push through, but we're not quite
| there yet.
|
| My interpretation of the memo from Unity is that they have
| deleted the VLC library from the Unity Store and have
| permanently banned the VLC group's Unity Store account for
| violation of the terms of the contract with Unity.
|
| Corpo jargon can be difficult to understand. (This might be the
| primary purpose of corpo jargon.)
| mschuster91 wrote:
| > After months of slow back-and-forth over email trying to find a
| compromise, including offering to exclude LGPL code from the
| assets, Unity basically told us we were not welcome back to their
| Store, ever. Even if we were to remove all LGPL code from the
| Unity package.
|
| It's high time the EU clamps down on Unity as well and classifies
| them as a gatekeeper. This behavior is absolutely unhinged.
| tobyhinloopen wrote:
| Unity again showing their hostility. Perma-banning developers for
| this reason is crazy.
| TheRealPomax wrote:
| Not so much "again" as "before they doubled down and went full
| unity". This happened before the "per install" fees, in August
| of 2023.
| Xplan wrote:
| Not trying to play devils advocate, but it goes both ways. There
| are proprietary libraries in a lot of solutions too. The LGPL is
| under many distributed closed solutions that are sold for profit,
| so I think its WEEE bit of the kettle calling .. ya you get it. I
| don't want to turf war, but its more systemic than you probably
| think. In this case, its just the pry-bar used that the risk to
| blow up the entire community of developed software with open
| libraries.
|
| Tread lightly maybe.
| Dylan16807 wrote:
| What goes both ways? Everyone involved is fine with proprietary
| libraries being used.
|
| > The LGPL is under many distributed closed solutions that are
| sold for profit, so I think its WEEE bit of the kettle calling
| .. ya you get it.
|
| No, I don't get it. The LGPL allows that and they're happy with
| it. Where are you seeing hypocrisy?
| WesolyKubeczek wrote:
| I remember that VLC could not get into iOS App Store for the same
| reason, and the story about it was spun by everyone and their
| dog. Ffmpeg is there because it doesn't have this kind of PR, and
| that's it.
| Reason077 wrote:
| Different issue. The App Store controversy was because VLC was,
| back in 2011, licensed under the GPL. One of the VLC developers
| complained to Apple that the GPL license was incompatible with
| the App Store distribution model, so it was pulled.
|
| The engine parts of VLC were subsequently relicensed under
| LGPL-2.1, and the rest of the app under MPL.
|
| VLC has been back on the App Store since 2013.
| Dwedit wrote:
| I don't know if VLC itself is even legal in countries that
| enforce software patents.
| falcor84 wrote:
| Previous discussion (Jan 2024):
| https://news.ycombinator.com/item?id=38964972
| w4rh4wk5 wrote:
| 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?
| hedora wrote:
| 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.
| tzs wrote:
| > 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.
| kmeisthax wrote:
| > 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.
| globalnode wrote:
| did your app threaten their advertising network or revenue
| perhaps?
| minima wrote:
| Godot ftw.
|
| Unity is a bad business decision nowadays. If I had to pick
| something commercial I'd rather pick Epic Games who at least uses
| lawyers to fight Apple instead of f*ing with open source devs.
| actinium226 wrote:
| Can the link please be updated to note that this is from 2024?
| 99nala wrote:
| We moved away from Unity a few years ago when they introduced
| their updated licensing plan. I believe they backtracked on it
| almost immediately but we are still happy with our decision.
| bartvk wrote:
| If not home-grown, where did you move to?
| mystified5016 wrote:
| Sure would be a shame if someone went through the unity store and
| reported every single LGPL asset to Unity legal.
| NoahKAndrews wrote:
| Edit: nevermind, they are in fact affiliated, and most of the
| core VLC devs work at VideoLabs. I've kept the original comment
| below.
|
| This blog post links to the "VideoLab Store", hosted at
| https://videolabs.io, which prominently uses a logo extremely
| similar but not identical to the VLC (which stands for VideoLAN,
| not VideoLab) logo. Their homepage even goes as far as displaying
| "Hire the VLC team" as its headline.
|
| As far as I'm aware, VideoLab has nothing to do with the VideoLAN
| non-profit, and it very much seems like they are intentionally
| trying to mislead people into thinking that they are the
| developers of VLC.
| bionade24 wrote:
| Well, the author does have a link to the git forge of the
| VideoLAN project prominently displayed on the blog and also
| contributes to projects there:
| https://code.videolan.org/videolan/LibVLCSharp
|
| Additionally, Videolabs is listed at
| https://www.videolan.org/videolan/partners.html
|
| I guess the project is well-aware of the corporation.
| NoahKAndrews wrote:
| Just discovered some of that myself, I'm glad everything's on
| the up-and-up.
| paulbgd wrote:
| The CTO is the president of the VideoLAN non-profit, so it
| seems accurate. Supposedly from their about page they're the
| primary maintainers of vlc.
| jbk wrote:
| (President of VideoLAN here).
|
| So far, VideoLabs is hiring most of the VLC core developers and
| those people are the main force of development of VLC. It's
| setup this way so that if the Videolabs company does not live
| forever, VLC stays forever free, and the non-profit lives.
|
| This is quite classic of open source projects, and in the case
| of VideoLAN, there are 3 or 4 companies doing consulting.
| TheAmazingRace wrote:
| I love this model! Love what you guys do, and please keep up
| the good work.
| NoahKAndrews wrote:
| Very cool, that definitely makes sense! I've edited my
| comment, apologies for that. Hopefully bringing attention to
| the fact that you guys are easily available for hire ends up
| doing more good than harm.
| squigz wrote:
| What does this mean? What harm does it do?
| jdbernard wrote:
| The harm I imagine would be the reputation damage from
| people believing that "they are intentionally trying to
| mislead people into thinking that they are the developers
| of VLC." NoahKAndrews, having been informed that these
| really are the devs of VLC, is hoping his earlier,
| uninformed statement did not cause too many people to
| think poorly of VideoLabs.
| Ragnarork wrote:
| > As far as I'm aware, VideoLab has nothing to do with the
| VideoLAN non-profit
|
| VideoLabs is a company which has been founded by one of the
| creators of VLC/VideoLAN and president of the VideoLAN non-
| profit.
|
| It's basically a for-profit that hired/employs most of the VLC
| main contributors and pay them a salary to work on that
| ecosystem while providing consulting and other services to
| finance all that.
|
| They are significant contributors to the VLC codebase.
|
| After having worked with them in the context of a partnership,
| I can add that "for-profit" is mostly the legal form but not
| the mindset.
| spyder wrote:
| From their about page:
|
| _Videolabs was born from the VideoLAN community and started by
| maintaining the VLC ports on mobile. It is now the main
| contributor to VLC, hiring its historical developers, and
| building custom solutions around the VLC and FFmpeg
| ecosystems._
| doctorpangloss wrote:
| Unfortunately for these guys, even if they have come up with the
| right solution - their own store - it doesn't matter from the POV
| of commercial success. Right solutions are often NOT financially
| successful.
| giancarlostoro wrote:
| Every time I think about using Unity they remind me why I'm right
| in preferring something fully open source that isn't gate keeping
| my use of it.
| msie wrote:
| Ugh.
| Fokamul wrote:
| Only madman would develop anything with Unity after last fiasco.
___________________________________________________________________
(page generated 2025-05-07 23:00 UTC)