Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms; since one of the points of using unity is its cross-platform support, that suggests you’d have to find another library unless you were only deploying on real OSes.
But is that Unity’s problem?
This might be the best opening line of a HN comment I've ever seen :-D
Don't feel obligated to respond, but how do you feel about the LGPL now? How do you feel about it's evolution given the way the world has changed? Would you do anything differently now?
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.
I can distribute LGPL licensed code to people no problem even if they are then, additionally, forbidden to actually excercise their freedoms by laws, think for example about radio code. I might have to get a special permission to run the code if I make changes and compile it, but that's no concern of the person licensing their source code to me.
Same if, say, the code runs on a box in an inaccessible space, and in order to install their own binaries somebody would have to press a button that they can't reach. That's not a GPL violation.
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. 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.
Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does explicitly forbid the above mentioned situations?
(And of course this is just my reading as an interested layperson, you're the expert obviously :-))
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.
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
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.
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.
Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work.
Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?
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.
The separate pieces on disk are of course as you say.
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?
Well:
1. Unity itself is using plenty of LGPL libraries itself so the same concerns apply.
2. If this is not an issue on desktop platforms where you can comply with LGPL there is nothing wrong with allowing such packages on the Asset Store. Certainly not all developers ship their Unity games on most platforms so it should be up to them to figure whether the specific package they decide to include can be used for a given platform.
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.
Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"
Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity?
This was long before we hired Drepper.
When I saw the announcement on the Cygwin mailing list, I immediately set off to make a fork of the main Cygwin DLL which brings Windows-like behaviors.
I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind.
Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love.
For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own.
Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar.
I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software.
I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers.
Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar.
EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc.
[1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it.
[2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.
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.
The definition of what is a derivative work is IMHO overreaching in GPL based licenses.
In this case, when a company like Unity bans this VLC project for using LGPL software, the guild would open individual lawsuits against them to remove each of the other projects using LGPL code, based on various legal precedents around discrimination. Which would make it untenable to single out projects like this.
This is a negative or low-vibration idea, I realize. Which is actually my point. If a policy causes one to go down these anger/fear/ego-based rabbit holes, then something is suspect with it. This is the litmus test I use.
Somewhere along the way, we lost the wisdom or will to understand the difference between the letter of the law and the spirit of the law. And we sold our souls when we allowed wealth and power to override our discernment of right and wrong.
If Unity wants to step into its power, it can start by abandoning knee-jerk policies designed to protect itself from liability against stupid laws. It can start saving a war chest to go to bat against patent/copyright/trademark trolls for the rest of us and protect the projects within its ecosystem instead of throwing its contributors under the bus. It can set an example for other large companies to follow so that we can eventually reform the system.
But whatever all this malarky is has got to stop.
I really want to like Unity for how it aligns with my goals as a shareware game developer in my formative years and a lot of other reasons, but they make it very hard to do so.
This is brilliant.
What precedents are those? Can you link or name the cases? I've never heard of such legal theory.
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?
This is not deprecation. This is removal and banning.
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.
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.
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.
For example, if you build an app for iOS or visionOS, you have to distribute it via Apple’s stores, and 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 mention this example because there was a big tie up for Unity and visionOS announced with the Apple Vision Pro last summer, but presumably the same applies to Unity games on consoles etc as well.
I can see why from Unity’s perspective it is cleaner to just forbid LGPL entirely, that way it is harder for their customers to mistakenly violate licenses.
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?
> 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.
LGPL doesn't impose combined redistribution requirements, does it? They're just tilting against that whole ecosystem specially. And if you apply the same standard as LGPL, MIT/BSD are basically the same right? Probably CDDL falls in too? that's absolutely a crazy thing but it's pretty straightforward in the licensing agreement.
No, no, they got it all wrong:
"not, invented here!"
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.
> 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...
Having a simple licensing story for assets on the store lets users have trust in whatever they see they can use in their game worry free.
Edit: Removed bit about LGPL applying to the original code because of static linkage because it was incorrect and distracting from my point
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.
> 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.
Just a few remarks: VLC-Unity plugin is fully open source, and anyone skilled enough can build it themself.
We've tried for months to discuss with Unity and it was a nightmare. We've had discussions for years with Apple AppStore, Google Play store, and Windows Stores (including Windows Mobile + UWP). It's always challenging, but Unity was a headache an order of magnitude bigger: no answers, 3 different answers contradicting each other, and plain bad faith.
De facto, they use LGPL and open source to build their platform, but we're not allowed to have open source on the store? Not even LGPL with a layer of a different license? Why us? Why not the other people doing it?
Very frustrating.
So, yes, because some people need to buy support or licenses, even if everything is open source (don't want to build themselves, purchase department that needs a support contract, etc...), they need to have a small store. This is different from what we see usually, but there is a need, so this is a small store for that.
For most of HN users, you should just build it yourself. You should be skilled enough for that :)
- only so many hours in the day - it's nice to pay people for things they work on - stable release version
I'm thankfully not using Unity any more. Watched the recent installs cluster** from a bemused distance.
The only way to get a consistent response from Unity is paying support.
Their store review queue takes months, now with the layoffs it will only get worse.
They are hurting themselves by not having your plugin. Feels like they are building their own solution but I bet it will take years to release and will be broken.
Unless you are selling the plugin, you shouldn't care. You can host it anywhere and the community will find it.
It's not viral, but it does give users rights that aren't natural under the app store distribution model.
I'm curious, does the LGPL state explicitly that the licensor guarantees that the licensee can excercise their granted rights in practice? There can always be external circumstances restricting what I can do.
Or is it more like: The licensee (the unity package developer) can only use the code (VLC) if they guarantee that the sub-licensee (the package user or the end user) can excercise all their rights with no external conditions?
Edit: I think LGPL 3 actually does demand this, in the context of preventing "tivoisation". However, libvlc is licensed under LGPL 2.1 as far as I can see.
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.
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.
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 can use LGPL software on a multitenant mainframe system, where you don't have access to modify installed software. This was a well known use case in the 80s and 90s, so this doesn't seem appreciably different. The LGPL doesn't seem to require you as a software developer to ensure that the user can run the modified software on the same system on which the App Store version is run, mainly it's to make the source code available so they can, in principle, create a modified version that they can run somewhere.
What you're describing sounds more like the AGPL to me.
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.
Edit: if you want to link against SteamWorks
There are a lot of games under GPL on Steam.
Once you have humans in the loop, you have bias. Not even humans can follow the set ambiguous guidelines and the appeals process is mostly broken.
AI can somewhat help but language models are just that - language models - they don't have any deep understanding.
Fundamentally I believe moderation will always be broken until we get algorithms capable of understanding the deeper meaning of things and apply them uniformly.
Remember this?
I wonder what’s going on in the Unity executive’s heads right now.
weird.
Why not include screenshots of these emails too?
Looks like yet another faux pas by a company bent on self-destruction.
https://fossa.com/blog/open-source-software-licenses-101-lgp...
The blog post also says all games made with Unity depend on LGPL code. How do they comply?
I'm so glad I generally don't have to think about this kind of stuff day to day.
Also, I'm no Unity expert, but C# integrations generally use PInvoke right? It's the most dynamic of linking, there's really no inherent reason LGPL libs can't be used in Unity games. At worst, Unity should make sure you know your obligations, but I don't understand the necessity of a blanket ban. I'd be very surprised if VideoLAN, a well-respected organization that has been doing open source work for a very long time, had such a fundamental misunderstanding of the software licenses they use.
Either way, a request: please stop using "clickbait" to describe literally anything you don't like. The article is chiefly about their ban, even the announcement is. By all means, critique whatever you want, but that's simply not what clickbait is. Clickbait is more like "actually we didn't get banned, But..."
not only removed, but removed with no hope of reconciliation (if the author is to be believed). They offered to remove all LGPL code to comply and were refused. Their entire publisher account was banned over what I assume is one infraction. They made it pretty clear that Unity just didn't want VLC on their store.
Idea: What if there were some minimum, legal requirements for app stores? Example: If the app store owner enforces a rule, it must be enforced equally on all apps. (Obviously, that did not happen in this case.) If complaining / escalating due to unfair treatment is not remedied, there is a neutral gov't board that can make a ruling. This is not unlike labour union relations in countries with strong labour laws.
Unity doesn't want to have be the "cops" and "prosecutors" who have to go around to find, investigate, adjudicate and enforce violations in the store agreements. They want partners who, having agreed to the store terms, will make reasonable efforts to adhere to them.
E.g., Unity may have come to the conclusion that VLC violated the terms of the store agreement not by simple mistake or a reasonable different interpretation of the agreement, but on-purpose or through negligence. In that case, the reasonable thing to do is to simply stop doing business with VLC (if it's not too costly to do so), because of the relatively high likelihood it will happen again.
Don't forget that Unity could be sued for violating the terms of LGPL'd software. If they "have received a report" of an LGPL violation, they have to take it seriously. Any future lawsuit would likely be more successful if they had previously received a report of a violation and did not resolve it..
Preach on. This is one of the most annoying things, to me at least, here. If there is a post with more than 10 comments, there's a very good chance one of those comments contains "clickbait".
The word has lost all meaning to me at this point.
the internet runs on clickbait and HN's insistence on reflecting the title of the content itself means a lot of things that are posted are legitimately clickbait.
Just this morning I rolled my eyes when I saw an article titled "Airbus shatters record for jet orders as demand soars" (https://news.ycombinator.com/item?id=38967262).
I didn't even bother clicking on it.
people are getting oversensitive, but not without good reason.
You're better off directing this stuff to whatever negative reaction or word usage you're referring to otherwise you get a subthread of meta/ants. Or for even less effort required, just skip it. Almost all comments are greatly improved by meta-elision.
I think it's because they didn't stay in story mode. "So we decided to set up X..."
To me it reads as if the company has been around for a while and this story has been dug/made up purely to sell a product. And we should expect 15 more of these.
I suspect it's just bad/honest (?) Writing though.
Without some evidence your conclusion seems to be a hand wave.
Edit: Apparently some people can’t understand what I mean by “the very long ad”. It’s everything starting from “Introducing the Videolabs Store”, not the whole article.
Asking for money for support is entirely reasonable as well.
How VLC should have framed this post:
1. Our plug-in got banned from the Unity Store for what we believe are bad reasons. Other high-profile plug-ins with LGPL code are still there.
2. To ensure that our users can still get our plug-in, we set up our own store which sells the plug-in.
3. Also the store has all these other services you can buy.
But they omitted the second part. And the simple act of not explicitly connecting the store to the plug-in ban through enough PR speak seems to have been enough to make people here characterize this blog post as simply an ad for their store.
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.
Where it gets fun is that there are currently hundreds if not thousands of Unity assets that include LGPL dependencies (such as FFmpeg) in the Store right now. Enforcement is seemingly totally random, unless you get reported by someone, apparently.
Step 2: we have our own store now!
That’s not a weird pivot, that’s what you do when a company you depend on no longer wants to do business with you.
If we were already aware of all this then this wouldn't have come off in the same way. The problem is that due to the way it was written I think most people expected the plugin to be free on the store. Personally I think it just could have noted that the general interest section of the article was finished when they segued into the store announcement.
Anyway, assuming everything is as they say then it seems pretty clear that Unity have some other reason for banning it, most likely commercial.
I think they're more than entitled to try and advertise a little bit. It's not like they're doing anything evil asking for some money. You can still go download all the code yourself and build it manually for free if you want.