return to table of content

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

gumby
93 replies
8h10m

When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code.

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?

quotemstr
35 replies
7h29m

The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived work" copyright status. Are we really supposed to believe that if non-copyleft code A is tightly coupled with copyleft code B, then the copyleft does propagate to A if we summon the ld-linux.so.2 demon for dynamic linking and doesn't propagate if A uses B via system(2) and a pipe? Ridiculous. Whether A is a derivative work of B has to do with the extent to which A is coupled to B in particular, not the mechanism of this coupling.

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?

gumby
29 replies
6h56m

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.

quotemstr
20 replies
6h41m

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.

Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former.

IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?

gumby
14 replies
6h28m

“Where is the data?” Have you never used third party code that you didn’t compile yourself?

Hell, Unity itself (the topic of this article) is an example. Labview. Some code for talking to a spectrometer we bought for our lab last month. It’s extremely common. People used to sell libraries to do various computations and charge royalties for their use. Probably they still do but I don’t work in that kind of world any more.

You may call it absurd if you like but that’s how the system works. The GPL and LGPL deliberately do not break new ground in that regard. What was/is novel about them is not using an exchange of money, but rather other value instead. No more, no less.

quotemstr
9 replies
6h5m

Have you never used third party code that you didn’t compile yourself?

Free software is different.

Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law?

Yeah, I know that's the FSF's interpretation. I don't buy it, and here's why: this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal. See, the FSF theory is that libproprietary.so becomes a derivative work of libmysql.so because it calls APIs provided by libmysql.so. Maybe the FSF is right. Maybe they're wrong. If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble. This conclusion is absurd: therefore, our premises are wrong.

You might say, "well, MySQL's socket API is obviously for general purpose use". So is libreadline's. So what? Either calling a public API propagates copyleft or it doesn't. Differentiating between calling APIs via dlopen() and via socket() makes no sense. I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.

The reason I can't just download LabVIEW and run it isn't that it's a library: it's proprietary software! I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so

fluoridation
5 replies
4h1m

Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law?

Mmh... The GPL and copyright are about information distribution. You, as someone who owns their copy of libmysql.so and libproprietary.so, can do whatever you want with them. They're on your hardware and no one can tell you what you can order your hardware to do with the information that's on it. The question is, if you write a program that uses them both and you share that program with the world, how are you supposed to license that program? I.e. What rights are you supposed to give the users of that program?

So the question of whether you've broken copyright law depends on how you've licensed the program that links to both libmysql.so and libproprietary.so. If the program is closed source, then yes, you've broken copyright law. If the program is GPL'd then, I don't know. Maybe you have, but I don't know who could sue you for making a GPL'd program that depends on a closed source library that you don't have the source for.

quotemstr
4 replies
3h57m

If the program is closed source, then yes, you've broken copyright law.

My point is that although many believe that linking proprietary code and GPL code into the same process breaks copyright law, it's not clear that the law actually forbids it. https://tech.popdata.org/the-gpl-license-and-linking-still-u... is one analysis by someone else skeptical of the FSF's position.

fluoridation
3 replies
3h44m

I would argue that the act that makes a piece of software "derivative" of another is not loading them both onto the same address space (since that's a symmetric relation anyway), but whether making one depend on the other having a specific behavior. If A.so provides foo(int) with some contract C and B.so depends on an implementation of foo(int) that matches the contract C, then arguably B.so is derivative of A.so, and the more facilities A.so provides and B.so assumes are available, the stronger that argument becomes. Whether the way A.so and B.so communicate is through a calling convention, a pipe, or a network connection, is largely an implementation detail.

quotemstr
2 replies
3h37m

I have two points:

1) it's not clear your interpretation of what makes software "derivative" is correct. One interesting analysis is https://studylib.net/doc/18120956/triggering-infection--dist......

2) if you are correct, then isn't it a violation of copyright law to use a socket or a pipe to talk to a GPL program? For example, if I execute popen("parallel ..."), I'm using a pipe to talk to a GPLed program (assuming "parallel" is GNU parallel). I expect this program to adhere to a specific command line interface. My program won't work with anything else. Is my program violating the GPL by running GNU parallel as a subprocess? Most people would say "no". This position seems incoherent to me.

One of two conditions must then hold: either a) dlopen has legal significance, or b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work. Which is it?

nirimda
0 replies
2h55m

One of two conditions must then hold: either a) dlopen has legal significance, or b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work. Which is it?

Afaik the FSF agrees with your dichotomy and expresses the latter opinion. Take for instance their faq "You cannot incorporate GPL-covered software in a proprietary system. ... However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."

In another question, they address the notion of what might be considered a single combined porogram. "It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

"If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

"Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."

So I don't think that the FSF intends that you can use a technical means to escape linking. You cannot take a GPL library and write a pair of libraries which expose its functions via a socket because the result would almost certainly involve "function calls to each other and share[d] data structures".

https://www.gnu.org/licenses/gpl-faq.html

As to whether this puts into jeopardy anyone in particular who uses Linux or libmysql in proprietary systems without additional licences, well, that is a different matter. The FSF's interpretation of the GPL tells you something about when the FSF might sue you and about what revisions might be made to the GPL in the future. But it doesn't tell you about when the copyright holders of Linux or libmysql might sue you, or what they will do if there's a GPL v5.2 released tomorrow.

fluoridation
0 replies
1h11m

I would argue that yes, you're not working around the GPL by going through a pipe. Your program still doesn't work if the remote process gets killed, so it's dependent on it.

b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work.

What do you have in mind in particular?

toyg
1 replies
3h17m

> I don't need permission to have libmysql.so

Er, dude, you do. A Free license doesn't mean there is no license. If you obtain libmysql.so and use it in any way, you have to respect the license or you're in breach of copyright law.

The fact that free (re)distribution is allowed by the license does not mean that the use of it in any way is not restricted.

> this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal

That might well be. Free licenses are abused every day, as people don't really know what this or that license requires. They even routinely strip copyright statements on MIT/BSD code, which is literally the only thing one is not supposed to do. But just because people get away with speeding over the limit on most days, it doesn't mean that the speed limit is not legally enforceable.

quotemstr
0 replies
3h5m

If you obtain libmysql.so and use it in any way, you have to respect the license or you're in breach of copyright law.

We're talking about following the GPL to the letter with respect to libmysql.so. The GPL says nothing about what I can do with a program on my system not covered by the GPL.

nirimda
0 replies
3h16m

If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble.

As far as I know, the FSF takes the view that linking is a logical concept not a technical one, and so communicating via IPC is just as much of a problem as loading a program into your own addressable memory.

This conclusion is absurd: therefore, our premises are wrong.

I don't think you've demonstrated that it's absurd. For instance, it could be that MySQL does not believe it is a problem, and does not intend for it to be a problem, and will never sue for it - but that MySQL is wrong as a matter of law, and one day the FSF will sue someone in court and win and the Oracle lawyers will realise they have new opportunities for financial gain. Personally, I think that reality is more like this - the FSF and Oracle have different ideas about what it means to release code under the GPL and so the freedoms you get from the FSF are different from the freedoms you get from Oracle, and it's unclear to me what will hold up in a court of law. I certainly don't think there's anything absurd about the notion that different agents have different intents and conflicting understandings. (Note that I take the notion of freedom to include the confidence that I won't be sued by a rational agent for doing something, regardless of whether I could plausibly win the case or not.)

I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.

I don't think it makes a difference whether the case law is there. The difference is made by whether you're willing to go to court over it. If there is a chance that you will win a case, and there is a chance that you will loose a case, and that if you lose the case you will have to spend the next six months on full time development just to get back where you were before hand, then you might say "even though my lawyers say there is an 80% chance that we will win, I would rather use this BSD alternative, because the risk of that 20% are existential".

So, fundamentally, this is a case of put your money where your mouth is. If you think the GPL does something different than what "industry" thinks it does, then make your business, make your millions, and dare someone to sue you. No one else has an obligation to do that just because you haven't seen the case law.

I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so

Btw, here you have a false premises. You don't have permission to copy libmysql.so except by the terms of the licence. I think you've made a mistake. Let's go back. You said "I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that." But now you're claiming that the GPL's grant of permission is so absolute that you don't need the permission that it grants. In fact, the terms of the licence are limited, and the question is only to what extent they are limited.

In any case, there is one important consideration. And that is the intent of the FSF. If the terms of the GPL fail to have the legal consequence they intend, and they can modify the GPL to have the legal consequence they intended, then you can be sure they will. And if Oracle has a different intent, and likes the legal consequences that the GPL has, then they might continue to use the unchanged licence. But arguing about whether the GPL does to the FSF's code what the FSF wants the GPL to do is more about arguing about whether it is buggy, then arguing about the feature set. You are well advised to listen to the FSF's interpretation if you want to rely, indefinitely into the future, on an up-to-date version of the FSF's code. But the FSF's interpretation might not really be as important when it comes to Linux or MySQL or any of the other GPLed code bases out there.

tzs
1 replies
3h56m

I'm having a hard time figuring out what either of you are actually talking about.

He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom.

You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law.

A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work".

In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works.

To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this:

  #include "y_speech_lib.h"

  int main()
  {
      speak("Hello, World!");
      return 0;
  }
greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.

I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later.

If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y.

If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner.

It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer.

Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code.

Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing.

[1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.

simiones
0 replies
7m

greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c.

I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this:

  #include <stdlib.h>
  
  int main() {
    create_complex_c_code_using_gcc_specific_extensions("./intermediate.c");
    system("gcc -o intermediate ./intermediate.c");
    system("./intermediate");
  }
Is quite possibly a derived work of GCC, since it depends critically on communicating with GCC using a very complex and specific data interchange format (the GCC-specific C source code). Note that this is not including any portion of GCC itself, even after compilation.

Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".

poizan42
1 replies
5h41m

What is the point you are trying to make here? You can't use a proprietary library without a license because you can't distribute it. Whether you can have code linking to the proprietary library without distributing the proprietary library has been largely irrelevant to the makers of those libraries since you wouldn't be allowed to use that functionality without either the distributor or the user paying for a license anyways.

belorn
0 replies
3h5m

Distribution is not required for copyright infringement. The creation of a derivative work is a separate right in copyright.

Copyright law has however implemented exceptions in the form of interoperability. The distinction between creating a derivative work, or having two works communicating with each other, is a relative fuzzy one.

LeifCarrotson
3 replies
6h17m

This is a question of law, not math - the property doesn't have to be commutative or even consistent.

Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. In order to run the code, you have to accept the terms of the contract. Those terms can require almost anything the author wants. In this case, the terms specify propagation over dlopen and not over a socket or pipe. They could just as easily specify the opposite! It would be less sensible, but perfectly possible.

quotemstr
2 replies
6h1m

Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code.

The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: > a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

Where does this license talk about linking? Why should the GPL apply to my program that calls libreadline when I'm distributing the two separately and combining them at runtime? And more importantly, why does a combination involving dlopen() summon the copyright demons but socket() not? The distinction makes no sense.

I'd like to see actual case law showing that if I dlopen() libreadline from a proprietary program, dlsym() a function, and call it, then I've violated copyright law. Show me one example of the legal system adopting this interpretation.

smw
1 replies
5h13m

Because if you don't agree to the GPL's interpretation of it, then you haven't agreed to the license for the library and you don't have permission to distribute it?

(edited)

I think this is the magic legal judo of the (L)GPL that makes it work. Regardless of your feelings about the license, it's extraordinarily clever!

Note that if the license said you had to, for instance, share x% of your revenue with the licensor, that's not part of copyright law either, but it's still probably a legal license.

simiones
0 replies
4h3m

Neither the GPLv2 nor the GPLv3 define what constitutes a derivative work or make any claims about linking in the normative parts of the license.

Let's assume that tomorrow some courts were to find that two separate works can link to each other without being considered derived works of one another, and without the whole being considered a derived work of either part. Nothing in the text of the GPLv2/3 would then prevent you from writing a program which links to GCC, and distributing it under a fully proprietary license (as long as you distribute the sources of the version of GCC you're using, of course).

There is one tiny reference to linking in the non-normative parts of the GPL, the "How To Apply These Terms To Your New Programs" section after the explicit "END OF TERMS AND CONDITIONS":

If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library [emp. mine]. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

This may suggest that the writers of the GPL believe this would not be allowed under copyright law, but being outside the normative area of the license, seems unlikely to be an impediment in court.

juped
0 replies
1h56m

it doesn't, full stop, but the FSF has been pushing its maximalist theories which would not survive a second in court for decades now.

what may be more relevant is that the use of the GPL is evidence that the author (possibly) believes in maximalist FSF theories. and therefore might not be someone whose libraries you want anywhere near your work, for avoidance of potential disputes.

poizan42
7 replies
5h54m

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.

Not it's definitely not. For B to be a derivative work of A it needs to include copyrightable elements of A. But if B merely dynamically links to A then it only contains knowledge of the API surface of A. And SCOTUS refused to rule on the copyrightability of APIs in Google LLC v. Oracle America, Inc. In the EU APIs seems to be explicitly called out as non-copyrightable by Directive 2009/24/EC Article 1(2):

2. Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.
anthk
3 replies
3h42m

No, you are wrong. Libraries have an usage license on linking. Don't comply it, then reimplement your own readline and ship that instead of GNU readline. Period. Motif and Lesstif was an infamous case back in the day. Heck, or using Wine DLL's under Windows instead of the ones bundled from Microsoft.

poizan42
2 replies
3h22m

A third party library can claim whatever it wants in its license, that doesn't make it enforceable. There needs to be some mechanism that causes the terms of the license to apply to you. If you don't distribute any copyrightable parts of a third party library then you (may?) not be under any obligation to adhere to its license.

armada651
1 replies
1h45m

Even if you don't personally violate the license, the license may still be enforceable against the users of your program. When the user executes your program and it loads other libraries into its memory space, then it definitely has become a derivative work and the terms of the libraries will apply to the program as a whole.

simiones
0 replies
28m

At least in the USA, the copying of a program you legally received into working memory doesn't require a license of any kind, it is a type of fair use. I believe the EU has an explicit exception to copyright for the same reason. So I don't think any problem would arise when running the programs.

The only pertinent question is whether a program B designed to require library A is a derived work of library A or not - and this is a question for the copyright courts, the license of library A has nothing to say about this.

Now, I think even if it were established that program B is not a derived work of library A, it could be possible for library A to have a license that says "you're not allowed to distribute this library to others unless both you and they agree to never link program B or works derived from it with library A". The GPL could be modified to say something like this, and it may still match its original goals - though it may be more difficult to litigate this type of license term (in many countries, license or contract terms can be declared too onerous and be ignored).

gumby
2 replies
3h47m

An utterly irrelevant side point since the whole question is the use of the implementation not the API.

If you call write() in Microsoft’s libc you must follow Microsoft’s license terms or you don’t have the right to use it. If you call glibc’s write() the same applies. And if you don’t like glibc’s terms you are free to, say, install bsd’s libc or write your own write() implementation (which probably just does a system call anyway).

juped
1 replies
1h44m

I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from".

freedomben
0 replies
15m

I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from".

unless you make sure that gumby is speaking for the FSF, then that comment does not provide evidence that the FSF believe that. It's merely evidence that gumby does.

I don't understand why people are so quick to take somebody's personal opinion and ascribe it to whatever organization(s) they happen to belong to. This sort of fallacy is why we constantly have to suffer through the "I speak only for myself, not my organization" disclaimers

jopsen
4 replies
6h54m

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?

im3w1l
1 replies
6h14m

I have seen stuff like this. Audio programs asking you to specify the location of lame_enc.dll. Emulators asking you to specify location of some bios.

anthk
0 replies
3h36m

The BIOS it's a different case. That's left to the user. Also, the usage of the BIOS happens under emulation, not the main machine. For instance, FUSE with the Sinclair ZX ROM's instead of OpenSE. or Vice with the Commodore BIOSes instead of shipping C64 OpenBIOSes.

quotemstr
0 replies
5h54m

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

Nope. The GPL explicitly says

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
jameshart
0 replies
4h26m

Obviously, a zip archive containing A and B is a derived work of B.

It’s not obvious that any copyright attaches to a zip archive at all, any more than hanging two paintings on a wall makes a derived work copyrightable wall.

To be a derived work something still has to be a ‘work’.

A distribution license can restrict how you are allowed to distribute a work because it can directly restrict your behavior not because it propagates and applies to the container you distribute it in.

That is it can just say ‘you can’t distribute this bundled up with other things’, in much the same way as it can say ‘you can’t distribute this without the copyright notice’, or ‘you can’t distribute this on Wednesdays’.

captainmuon
24 replies
7h31m

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

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

mort96
14 replies
6h15m

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.
Okay, so I must distribute MortPlayer under terms which permit modification and reverse engineering. I can do that. Maybe Apple's terms conflict, but let's assume that's not an issue, let's read on.

    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.
Okay, no problem.

    Also, you must do one of these things:
Oh boy.

    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.)
Okay. I can accompany the work (MortPlayer) with the source code for VLC's libraries, no problem. MortPlayer is executed and linked with VLC's libraries, so I need to 'accompany the work 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".

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.

hedora
10 replies
3h29m

Are these new changes with LGPL 2.1? I don’t remember it containing the modification and relinking restrictions in the past. It kind of defeats the purpose of the LGPL IMO.

As an aside, it really bugs me that the GPL morphed into this thing that gives developers the freedom to run privacy violating and user-abusing cloud services, but doesn’t allow manufacturers to ship the same stuff on physical (and perhaps offline) hardware the end users have physical control over.

When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time.

Anyway, I guess the above restriction means I won’t be using LGPL for stuff I write at work, even though most of what we do gets open sourced anyway.

mort96
7 replies
3h20m

Huh? The whole point of the LGPL is to say, "you can use the LGPL'd code in your closed-source product, but the user must be able to replace the LGPL part of your product with their own version". The way to achieve that is to either use some kind of dynamic linking where the user can provide their own .so/.dll/.dylib of the LGPL'd library, or to provide the object files so that the user can statically re-link the application with their own version of the LGPL'd library.

This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version.

What purpose of the LGPL is defeated?

hedora
3 replies
3h8m

I thought the purpose of the LGPL was that it could be used for libraries without tainting the stuff the library is linked against with viral GPL restrictions.

Concretely, using gcc with default settings will bring in glibc and compiler intrinsic code snippets which were both LGPL last time I checked. If I use GCC to compile and statically link closed source code that I have a redistribution without modification license for, then I can’t redistribute my binary without violating my license for the closed source code.

Ouch! MUSL + clang it is, I guess. (I value my users’ right to own and operate computers even higher than their right to recompile code, so I’d rather not restrict my lgpl tainted binaries so they can only run in the cloud).

mort96
1 replies
1h13m

glibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library.

However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time.

The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL.

I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.

hedora
0 replies
47m

If you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build.

All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.

rescbr
0 replies
1h20m

IIRC, GCC specifically uses GPL + runtime license exception to avoid this scenario

gorkish
2 replies
2h3m

What purpose of the LGPL is defeated?

The purpose of /which/ LGPL? And that's the thing. After GPL demonstrated that it had teeth and got some case law underneath it, the "family" of derivatives exploded, each one of them identifying as "open source" but each with their own additions, removals, modifications or other opinions on what "freedoms" they convey (mostly removals).

There are those of us out here who believe that the core purpose of all of these licenses were defeated a long time ago when all of this legal swizzling first began. I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.

mort96
0 replies
1h9m

The purpose of /which/ LGPL

Either 2.1 or 3.0 I guess, the difference between the versions isn't that relevant to hedora's question.

The GPL exists to protect users against companies which develop proprietary software. If you prioritize the freedom of companies to restrict users over the freedom of those users, it makes sense that you'd dislike the GPL style licenses.

freedomben
0 replies
37m

I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.

Why do you hate them so much? Is it strictly as a developer, or as a user?

As a developer I've certainly felt constrained and annoyed by them at times, and I'm very glad there are alternative open source licenses available, but as a user I can't imagine a scenario where you would hate them. After all, the freedom they guarantee is to the user, not the developer.

Even as a developer though, the family has it's place. I don't think Linux would be a thing had it had a more "permissive" license. That GPL is what forces the big corps to contribute their improvements back. If not for the GPL, I think it would be in a position similar to that of BSD, and the majority of users would have no choice but to use a proprietary OS

kmeisthax
1 replies
2h21m

When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time.

They tried that, everyone balked. You know how Linus Torvalds rejected GPLv3 for Linux specifically because anti-TiVo[0] would be "changing the deal"? Imagine that times a thousand.

Furthermore, AGPL is only an anti-Google license specifically because Google is as internally afraid of it as Microsoft is of GPL. You can defeat the Affero clause by putting the software behind a proxy, for example. Furthermore, the Affero clause is only appropriate for web applications - ideally ones in dynamic languages that execute from source that remains on disk. Slapping it on all GPL software would be really, really dangerous. I've heard of people using AGPL on Ethernet PHYs - how the fuck do you offer source code to every packet that crosses an Ethernet switch?

If you really want a license clause that would absolutely decimate any corporate freeloading behavior, you want OpenWatcom's anti-private-forks clause[1]. It does everything AGPL tries to do, with fewer legal loopholes. But good luck getting that past RMS. The problem with supra-GPL copylefts is that anything that is legally watertight to a corporation is also going to impinge on a lot of freedoms we enjoy. Remember: the whole point of the GPL is to reject copyright, and that specifically means lots of corporate freeloading, because the whole point of copyright is to stop corporate freeloading.

[0] From what I've heard, the anti-TiVo clause in GPLv3 is actually less strict than the FSF advertised, at least relative to how TiVo used Linux. I can't find the original article I heard this in, though!

[1] Specifically, the OpenWatcom license requires distribution of source code whenever you use a modified version of the software.

freedomben
0 replies
40m

I mostly agree with you, with one exception:

Remember: the whole point of the GPL is to reject copyright, and that specifically means lots of corporate freeloading, because the whole point of copyright is to stop corporate freeloading

I don't think this is true. My understanding (which could be flawed) is that the whole point of the GPL is to weaponize copyright in order to guarantee freedoms, not to reject it (a subtle but important distinction).

Also the whole point of copyright doesn't seem to be to stop corporate freeloading, though that is of course part of it. It's point is to ensure that the original creator has rights to benefit from the work, whether that means getting stolen from by a huge corporation or stolen from by teenagers passing memes over the internet, or adapted by an individual/sole proprietor as part of some larger work, etc. My guess is we probably agree on this part and the debate is probably over semantics (i.e. you might have meant "business in general" by "corporate" rather than specific corporations).

naasking
1 replies
4h18m

It should be compatible with app stores. How would the inability to swap out the VLC library be any different from a program that you can't change because it's on a system managed by a sysadmin? Of course you, as a user, can run LGPL programs on mainframes or other third-party managed systems, this was a well known use case when the LGPL was written.

actionfromafar
0 replies
1h46m

It's all about the distribution of copyrighted material. The "user" then is the admin which received the program. The other used without admin, is just using some remote service. (With telnet/ssh. No distribution of copyrighted material is going on there, just input/output from a remote service, like a web site running LGPL code.)

actionfromafar
0 replies
1h39m

This is where things start being human and not only technocratic. If I, the user, have (only) an iOS device - how can I do this re-linking? I can't. I must get permission from (Apple Developer Account), buy a Mac, and re-sign binary blobs.

"The user wouldn't be able to then run the recompiled application, on their device" - I think that's where we get into the spirit of the license. It's pretty clear the license was not written to mean "here's some bytes, we write a lot about the freedom of the user" all for it to end with "can't run it though".

I can't understand someone carefully reading the LGPL license and then thinking, "great fit for a locked down app store distribution!"

I rather think that because LGPL historically saw a lot of use for platforms where this is not a problem, like Windows, where all this relinking is pretty doable, people just assume its fine on iOS.

ffgjgf1
4 replies
6h15m

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

wahnfrieden
3 replies
1h23m

that's outdated info

BizarroLand
2 replies
1h15m

Your face is on backwards if you think it's acceptable to tell someone that their information is outdated without also providing the new and up to date information.

wahnfrieden
0 replies
37m

the updated info is: it is now permitted

beeboobaa
0 replies
1h1m

It's Apple's App Store. Being vague and non committal is how they roll.

ajross
3 replies
3h32m

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.

torstenvl
2 replies
48m

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.

That is quite audacious to claim.

Do you have a citation to any case law supporting your position?

If not, what would be your argument?

ajross
1 replies
17m

It's in the text of the license? See section 6. a)

https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html

Also of course section 9: "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License."

You can't legally put copyleft stuff on the App store, because the recipient can't modify the results. That we've all as a society decided to look the other way doesn't change the requirements of the license.

torstenvl
0 replies
15m

So no case law.

You've pointed me to two sections of the license, but neither directly says what you're claiming. Why don't you help us understand what your argument would be? I.e., explain how you would apply the rules in the license to the facts of iOS distribution to reach the conclusion that distribution on iOS is a per se violation?

OmarAssadi
14 replies
7h40m

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?

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.

zigzag312
9 replies
6h52m

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.

simiones
4 replies
4h27m

The GPL can't really overwrite the legal definition of derivative work, even if it wanted to. Of course, there is little case law actually going into the weeds, so it's hard to say for sure. However, the GPL's definition seems pretty reasonable to me as to what would constitute a derived work (anything linking with the GPL work OR anything passing very very complex structures between itself and the GPL work).

In fact, I suspect that a legal definition of exactly what constitutes a derived work of a program may be more broad than the GPL's definition. For example, it's plausible to me that a program which calls `sh` as a fundamental part of its functioning could be found to represent a derivative work of `sh` per copyright laws.

zigzag312
3 replies
3h53m

Hmm, maybe didn't use the correct term when I said "derivative work".

What term defines the scope to which copyleft applies to?

simiones
2 replies
3h35m

I think derived work or derivative work are the right terms. However, "copyleft" is not a legal term, and it is copyright law (and associated jurisprudence) that defines what constitutes a derived work of some original. Licenses then control what the copyright holder allows you to do with their works or derivatives.

So, only copyright law itself can say whether, for example, this comment I'm making is a derived work of your own comment, or if it is an original work of my own. If it is a derived work of your comment, then you are the copyright holder for this comment I'm making and you can choose to write a license that allows me to distribute it or nor or whatever else. If it is not a derived work, then I am the copyright holder, and I don't require any license from you to distribute this comment.

So, if copyright law were to say "a computer program A is a derived work of program B if and only if it is produced from the same source code of A or textual modifications of the code of A" (very implausible, but just for the sake of argument), then there would be no difference between the GPL and the LGPL, and you could freely link to a GPL program and distribute the result under a proprietary license (you'd still have to distribute the source code of the original GPL program, of course).

zigzag312
1 replies
3h16m

So, derivative work term in copyright law defines the scope only as binary all or nothing? It's always a whole product that is considered derived, never just part of a product.

And license itself can then limit the scope of copyleft, so that it applies it to only a specific part of a work.

simiones
0 replies
55m

Note that I am not by any means a lawyer, so please don't take my understanding as authoritative.

My understanding is that "a work" and "a product" are different things. If I sell you a bundle of three books, the bundle is a product, but each book is an individual work and caries its own copyright. Even a single book may contain 5 short stories, each with a different copyright holder and license.

Similarly, I can sell you one CD that contains three different works with different licenses. Now, it is true that the GPL license does seem to say that you can't distribute a modified GPL work on the same CD as a non-GPL work, which would not fall under copyright law, it would just be an arbitrary requirement of the license that you have to accept if you want to be able to distribute the GPL work at all (by default, you're not allowed to distribute copyrighted work at all - it's only the terms of the license that allow you to).

However, the derived work problem comes more into question when you write a program that only works if it is linked with, say, glibc. The question becomes: is your program a separate work from glibc, or is it a derived work of glibc? If it is a derived work, then the GNU project is the copyright holder of the program you wrote, and you're not allowed to distribute it at all unless you get some license from them. If it is NOT a derived work, then you are at least free to distribute your program however you want, and tell your customers "just download glibc from gnu.org, put it at this path, then start my program", and the glibc license could do nothing to stop you since it doesn't apply in any way.

An analogy with books would be you writing a book that's meant as a sequel to Harry Potter. It is quite well established that even if your book is fully original, if it uses characters from Harry Potter by name, or locations or other key concepts, then your book is a derived work of the Harry Potter franchise and you're not allowed to sell it even if you're not directly using any piece of the originals.

Either way though, if you're creating a derived work, the license of the original can allow you to distribute your derived work under any terms they want. A license could say "you can distribute derived works for free on Wednesdays, but you have to pay a royalty if it's any other day of the week". Or, more interestingly, the license could say "you can distribute derived works without any conditions if they only access our original work through DLOPEN, but if they are accessing it through static linking, you must release the code and build instructions for your derived work" - this is what the LGPL does.

gumby
2 replies
6h44m

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

GPL doesn’t use the word “derive” and specifies modified work in a way that is consistent with the customary legal definition.

People twist things around because they want to use GPLed code without “paying” for it, but really at the end of the day it’s just an ordinary license agreement but instead of paying cash to use it you agree to give users the freedom to modify and/or redistribute the code.

Just like any other licensed code you can agree to the terms and use the code or disagree with the terms and use something else.

zigzag312
1 replies
6h10m

It doesn't really matter where exactly it is defined. There's effective definition of derivative works in place for GPL, even though it's definition is inherited.

People twist things around because they want to use GPLed code without “paying” for it, but really at the end of the day it’s just an ordinary license agreement but instead of paying cash to use it you agree to give users the freedom to modify and/or redistribute the code.

You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange.

Source of confusion probably comes from overuse of the word "free" by people promoting GPL, which is like you said, just an ordinary license agreement.

aleph_minus_one
0 replies
4h58m

You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange.

It's not that simple. If it was just about "my" code, this would indeed your claimed barter exchange. But often, say in industry, the code that you develop is combined with a lot of third party code and libraries for which you simply do not have the permission to put them under GPL.

teddyh
0 replies
6h43m

IIUC, GPL based licensed do not define what what derivative work it, but leaves it to the law.

gumby
3 replies
6h40m

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.

NohatCoder
1 replies
2h41m

I wonder how many times that has happened? Specifically someone intentionally modifying the behaviour of a closed source program by changing an LGPL library that it depends on.

freedomben
0 replies
25m

I personally know of that happening twice. In both cases it was used to patch a bug in the super old Qt version that was being shipped.

I'm sure it doesn't happen often, but IMHO that doesn't really matter. It's preserving the freedom to do it that is important. I rarely use my right to free speech (that is, saying something that somebody in power would find offensive and want to jail me for), but it's a right I would fight to the bitter end to preserve.

toyg
0 replies
3h29m

I mean, it's like telling the pope that Jesus is the son of god only on Mondays and Tuesdays, eh...

Y_Y
8 replies
6h24m

For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1.

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?

[0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

simiones
6 replies
4h34m

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.

dagmx
5 replies
2h3m

Or they’ve dual licensed the libraries in question.

simiones
4 replies
1h11m

You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?

doctorpangloss
3 replies
51m

I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case.

With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses.

I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor.

My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.

simiones
2 replies
44m

The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. You're right of course that I have not done any independent research on it, and so they may be lying or wrong for all I know.

However, even if Unity is not using those libraries in the iOS runtime but does use them somewhere else, that still seems that they were arbitrary in their enforcement of the rules, since the VLC packages mentioned here were not being distributed for iOS at all. So they were certainly not using LGPL on iOS either.

I'd also mention that I'm not claiming that Unity is breaking the LGPL. I'm rather more of the opinion that distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL, and that Unity thinks so as well.

doctorpangloss
0 replies
19m

The authors of the article claim that the Unity runtime uses (some of) those libraries...

Ultimately I sympathize with the author, and this is not meant to pass a subjectively negative judgement, I know the author didn't unpack a Unity iOS IPA and carefully check if any of the libraries are definitively LGPL and if they were definitively not cross licensed, that would be a waste of his time.

distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL

I don't want to make the author of the LGPL, who is commenting in this thread, regret commenting. There's a phrase he uses that makes it clear to me what its intent is, "right to repair." It comes down to whether or not you think it's impracticable to replace a library in an iOS app. For the average user it obviously is.

Is it practicable for sophisticated users? You can probably get the app bundle, replace a .dylib in an embedded Framework, resign it, and use the app bundle on your development enrolled device. But then you will lose a lot of functionality, like push notifications and IAP. And ad serving will also probably stop working. So my opinion is: no. You can't distribute LGPL libraries in iOS apps.

debugnik
0 replies
28m

The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well.

The article doesn't mention iOS or Apple even once, they in fact mention they only had assets for Windows, UWP and Android as three different packages, so everyone here thinking Unity is blocking the packages because of iOS has completely missed the context.

gumby
0 replies
1h53m

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.

qwertox
4 replies
8h1m

But is that Unity’s problem?

Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"

tonmoy
3 replies
5h14m

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

Vinnl
1 replies
5h8m

That sounds like the "and the runtime (which means your shipped game)" part?

doctorpangloss
0 replies
1h20m

Nobody in this thread has firmly pointed to LGPL code being linked or used in the iOS runtime in a Unity 2021 or later built game. Having not looked at this myself, I can't say either way, but it is almost certainly wrong to say that the runtime contains otherwise LGPL code that was not expressly licensed or permitted for the purpose by its authors.

voxic11
0 replies
5h0m

The resulting binaries depend on the unity runtime which itself depends on these LGPL components.

ffgjgf1
1 replies
6h16m

But is that Unity’s problem?

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.

jillesvangurp
0 replies
3h4m

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.

freedomben
0 replies
57m

When I originally wrote the LGPL

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?

chii
37 replies
10h57m

What's the rational for not allowing LGPL code on the unity store? It makes no sense for the ban imho (tho i m not very familiar with unity store's model so i might just be missing something).

paulmd
21 replies
10h44m

intredasting, they rather explicitly appear to be tilting against viral licensing:

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!"

adrian_b
16 replies
10h23m

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.

ghusbands
8 replies
10h6m

Doesn't the LGPL give users the right to replace the LGPL part with a modified library of their choice? It seems doubtful that users can modify downloaded Unity apps at their leisure, so that would mean that LGPL cannot be supported on Unity, wouldn't it?

Though then it would seem that LGPL libraries on almost any app store are being used against their license terms, so I must be wrong.

swiftcoder
4 replies
9h48m

Though then it would seem that LGPL libraries on almost any app store are being used against their license terms, so I must be wrong.

You are not wrong. LGPL does require that you provide users the ability to link against a modified version of the LGPL library. It is a requirement that has been rather honoured in the breach in this age of appstores

palata
3 replies
9h10m

LGPL does require that you provide users the ability to link against a modified version of the LGPL library.

That's correct for LGPLv3, but I believe LGPLv2 is more nuanced.

With LGPLv2, I don't think it requires that you provide the ability. It has to be possible if you get access to the executable (which may require that you jailbreak your device, for instance). For instance, it is my opinion (not legal advice) that it is fine to use an LGPLv2 Java library in a proprietary Android app, because you can technically go replace the class files corresponding to the LGPLv2 library in your apk. It's not easy to do (unlike swapping a dynamic library), but it is possible.

rerdavies
2 replies
7h27m

can technically go replace the class files corresponding to the LGPLv2 library in your apk

APKs in the Android app store MUST be cryptographically signed. So, it is impossible.

The only practical solution that an LGPL license provides for Android apps is to fall back to the viral GPL license.

palata
0 replies
2h29m

They must be signed to be on the store, but I don't think it's impossible to run unsigned apks on the device (maybe you need the developer mode, though).

But even then, wouldn't that count like tivoization? LGPLv3 says you need to provide instructions to replace the lib, but LGPLv2 does not. Couldn't I say "I honor the LGPLv2, because it would be technically possible to update the library, but unfortunately for you it is behind some tivoization that you would need to break first"?

maple3142
0 replies
3h3m

But you don't have to publish that modified apk to Play Store. You can just sign it with your own key and install the apk manually, no root needed.

I know there are some apps that do its own cryptographic signature verification on their own, but most apps don't do that, so replacing a LGPL library in an APK is actually feasible in most cases. It is not hard to do so either.

adrian_b
1 replies
9h50m

The obvious way to comply with LGPL is to link dynamically the LGPL libraries, even if everything else is linked statically.

I am pretty sure that the Unity executables link dynamically glibc anyway.

The alternative is to do the static linking in 2 steps. First link everything else into a big ELF object file, then do the final linking of the LGPL libraries.

For compliance with the LGPL, it is enough to provide access to the big binary object file, so that a user may relink the possibly modified LGPL libraries, if desired.

A dynamically-linked executable and an object file that needs a final static linking step with additional libraries have almost identical content and they provide equivalent information.

pzo
0 replies
8h29m

Sometimes even dynamic linking might be not enough - on iOS you can build dynamic frameworks that are dynamically linked but they are signed with developer provisioning key when distributed via App Store. AFAIK there is not other way for end user to swap such dynamic framework/library unless developer will provide source code or object files or compiled code (e.g. in other dynamic framework that links dynamically to such LGPL code). Not sure about jailbroken iPhones.

Also for more complicated iOS projects (that require iOS capabilities e.g. in-app-purchase, push notifications, app pay, icloud etc.) end user would need to have a paid apple developer account to create and sign build.

paulmd
0 replies
9h40m

That is irrelevant, look at the way the clauses are structured:

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

it's not a question of terms similarity in that clause, it literally forbids any usage of GPL or LGPL by name. These licenses are "name banned", not just by "features". You can't have GPL or LGPL, nor can you require clients to sublicense you to GPL/LGPL for your program to operate, or any other license that has similar propagating terms to sub-licensed entities.

Obviously you can turn the world on "terms similar", h265 user/device licensing or whatever isn't terms similar here. But just by the plain text it's very obviously a direct swipe at GPL and viral licensing, they're banned by name, at minimum they probably want to see BSD/MIT I guess.

Article isn't wrong that's a crazy-ass term.

paulmd
3 replies
10h4m

This isn't a linguistic disagreement, LGPL and similar licenses are literally forbidden by the direct plain text of the agreement.

(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.
adrian_b
2 replies
9h44m

The complaint was not that it is not true that they have not complied with the agreement, but that this rule is only selectively enforced and that nobody truly complies with it.

Moreover, the rule has no rational reason, because unlike with GPL, compliance with LGPL is very easy to achieve, even for proprietary programs.

rerdavies
1 replies
7h21m

The rule is completely rational. It is impossible to use LGPL-licensed components on the Android app store or Apple app store without becoming infected with the full GPL. (As extensively discussed throughout this thread).

cozzyd
0 replies
22m

Sounds like Apple and Google should fix their broken app stores then.

davexunit
1 replies
3h30m

Calling a license "viral" is a gross pejorative intended to discourage copyleft.

paulmd
0 replies
1h43m

okay

lmm
0 replies
9h21m

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

GPL is a viral license.

The LGPL's level of "virality" is small, but nonzero - it imposes requirements on a larger program of which you use LGPL code as a part. Those requirements are much smaller than the requirements imposed by GPL code in the same circumstances, but they are real, and much more substantial than e.g. including a copyright notice.

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.

glibc has an explicit linking exception for programs using its public interface.

MaxBarraclough
3 replies
8h31m

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

rerdavies
2 replies
7h20m

At the risk of seeming pedantic, who are you to decide whether viral licensing or copyleft is the proper term?

MaxBarraclough
1 replies
4h23m

It's not just my preference, anyone familiar with this area of copyright law recognises copyleft as its standard name. Viral licensing is, as I said, a snarky pejorative. [0][1]

It's also less precise. Proprietary licenses can be 'viral' too. DRM libraries, for instance, may require that application source code not be made publicly available.

At the risk of seeming pedantic

Parroting others in this way comes across as juvenile and antagonistic.

[0] https://en.wikipedia.org/wiki/Copyleft#Viral_licensing

[1] https://en.wikipedia.org/wiki/Viral_license

paulmd
0 replies
1h41m

juvenile and antagonistic.

honestly you are over-reading and projecting here

charcircuit
6 replies
10h41m

The rational is that you should be able to just install any asset from the store in your game and be good to go. With an LGPL asset now you have to let customers be able to edit that addon and rebuild your game with it which would be a pain, and most developers do not want to give out the unity project files.

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

adrian_b
3 replies
10h27m

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.

charcircuit
2 replies
10h6m

The LGPL code gets statically linked with the rest of your code which means that you have to provide the project files in order to be able to change the LGPL code.

adrian_b
1 replies
9h36m

No, you do not have to provide any project files, even when everything is linked statically.

Static linking can be split into two linking steps, first everything except the LGPL libraries can be linked into a big ELF object file, which no longer contains any information about the internal structure and the internal symbols, exactly like an executable file. The only difference between such an object file and an executable is that it contains unresolved external references, like a dynamically-linked executable.

Then in the second and final linking step, the big binary object file is linked with the LGPL libraries.

For compliance with LGPL it is enough to offer access to the big binary object file for the users who would want to replace the LGPL libraries.

charcircuit
0 replies
9h23m

Please do not forget that we are talking about Unity. Unity doesn't let you split up linking like that. All the game and asset codes gets mixed together in a single step. Needing to split out and rig together some hacky solution is the reason why they don't want it in the assert store. As I said in my original comment Unity wants assets to be low friction to add to your project.

shakow
1 replies
10h14m

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.

palata
0 replies
8h49m

As a side note, I believe that LGLv3 says that you have to provide instructions about how to do it, but with LGPLv2 is just has to be technically possible if you have access to the binary.

larschdk
4 replies
9h40m

My guess; Unity doesn't want LGPL code in component they re-distribute, because the responsibility to comply with the license requirements falls on them, since they are the ones redistributing. It's not that they can't, but they wont take that responsibility, which is understandable. They would basically need to audit every component to ensure that the end user can build and replace LGPL parts with their own.

captainmuon
1 replies
7h17m

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.

larschdk
0 replies
3h52m

The LGPL license doesn't work that way. The rights that it establishes follows every time you transfer the work between legal entities. If I transfer the work to you, I need to extend the rights granted in the license to you. I can't expect others to do it for me.

toyg
0 replies
9h1m

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.

maratc
0 replies
1h50m

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.

agsnu
1 replies
9h13m

My guess is that they want packages on the Unity store to be usable on all platforms they support.

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.

palata
0 replies
8h46m

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?

mihaaly
0 replies
8h35m

Would it worth a try reporting other LGPL violations to Unity - as drawing attention to violations of their own 5.10.4 of Provider agreement - in a documented manner? Just to see how they proceed.

CodeCompost
25 replies
10h50m

Weird pivot in the middle of the article where all of a sudden they're promoting a product. Is this an ad disguised as a clickbait article?

loup-vaillant
20 replies
9h48m

Step 1: we’re banned from the store!

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.

PUSH_AX
18 replies
9h24m

"depends on" is a bit strong.

tankenmate
15 replies
8h58m

Have you seen VideoLAN's revenue? What percentage of their revenue came via the Unity Store?

PUSH_AX
14 replies
8h55m

They're a non profit organisation. They existed before the Unity store and they are existing after the Unity store. They did not _depend_ on Unity.

tankenmate
12 replies
8h51m

Non profit doesn't mean all the employees work for free. Your statement is the equivalent of saying "The Red Cross don't need money, they're a non profit!"

master-lincoln
4 replies
8h7m

How so? Their statement was that not that VideoLAN does not need money, the statement was they do not depend on the Unity store to get enough money. Nobody claimed non profit means working for free or even went into that direction. The statement "They did not _depend_ on Unity." is not equivalent of saying "The Red Cross don't need money, they're a non profit!". Or which statement did you refer to?

Please be less enraged and try to understand the arguments of others in discussions.

tankenmate
3 replies
8h0m

I'm not enraged, my point was simple; without knowing what VideoLAN's revenue looks like you can't say for certain that VideoLAN don't actually depend on it. Say for example VideoLAN got 75% of their revenue from the Unity Store and then they got banned; I would say that is a case of dependence. Without such knowledge it is very difficult to say with certainty whether VideoLAN is dependent on their products being available on the Unity Store.

Nothing to do with being "enraged"; in discussions it generally doesn't help to attribute motivation without evidence.

Supermancho
1 replies
3h8m

without knowing what VideoLAN's revenue looks like you can't say for certain that VideoLAN don't actually depend on it.

This is a matter of how someone might interpret "depends".

If you meant "effectively will cease to exist", that is incorrect.

If you meant that VideoLAN depends on Unity the same way I depend on the 5 dollars in my pocket to be fungible...VideoLAN still exists without Unity, same as I exist without the 5 dollars in my pocket.

There's nothing more to it, afaik.

glenstein
0 replies
2h23m

Right, I think this is a nothingburger - they 'depend' in the sense of leaving it up to Unity to honor a defined set of responsibilities on their side of a relationship. I think there was no need to get into whether this posed any sort of existential threat to VLC.

master-lincoln
0 replies
6h57m

Sorry for attributing motivation without evidence, I regret that and think you are right on this point.

Now I got your point concerning the dependence. That was not clear to me before you elaborated and I don't see how I could have inferred that.

It is highly unlikely though that this integration into a game engine made any significant revenue in its 3 years of existence if you ask me. The integration is also still available, just not distributed via Unity store.

As VideoLan is a non-profit I tried to find info on their income to get a bigger picture, but failed to find that.

PUSH_AX
4 replies
8h8m

Not sure how that relates to them "depending on Unity"? is really clear that they never have, nor do they now.

tankenmate
3 replies
7h58m

"is really clear that they never have (depended on Unity)"; I'd be happy to come to the same conclusion, IF there is evidence.

But most of your comments seem to be conclusions looking for evidence rather than the other way around.

PUSH_AX
1 replies
7h52m

Equally one possible line of reply you could have offered is some evidence that they were dependent. When neither side can produce evidence it seems fair to me to fall back on some clear deductions, which I won't repeat.

Honestly this debate seems like a waste of time for both of us. I'll leave it here, and I hope you have a good day.

tankenmate
0 replies
7h40m

You claimed they weren't dependent, not me. My comment, paraphrased, was "How can you be sure without evidence?"; I don't know if they are dependent, not enough information.

I hope you have a good day too!

uxp8u61q
0 replies
3h43m

The evidence is that VideoLAN still exists months after getting banned by Unity. If they "depended" on Unity they'd be bust by now.

alexdns
1 replies
8h8m

I dont think the VLC team has been caught in multiple scams like the red cross tho ?

tankenmate
0 replies
7h56m

Your statement is completely non sequitur.

DirkH
0 replies
8h34m

Nonprofits die all the time because they run out of money

red_trumpet
0 replies
8h41m

Just as strong as "dependency" is usually used in software engineering, not? They swapped out a dependency, so now they don't depend on the unity store any longer.

mort96
0 replies
7h54m

"Rely on" then? Regardless, I think their point was clear.

fwn
0 replies
9h37m

It's not even competition, as Unity seems to have decided to "deprecate" the Unity Store for VLC. /s

blauditore
2 replies
10h22m

I wonder if the license was the actual reason for the ban, or some shenanigans like this article, trying to sneak in ads somewhwere.

mort96
0 replies
7h53m

Are you suggesting that VLC is lying about the communication from Unity, including faking the screenshot (or lying by omitting other e-mail)? Or are you suggesting that Unity is lying to VLC about the reason for the ban?

boomboomsubban
0 replies
9h14m

It's vlc, I doubt it.

nebulous1
0 replies
4h36m

I agree that it came off as a bait and switch. Having looked a bit deeper, the plugin is open source and you can download, compile and distribute it for free. They charge for the precompiled binaries that you can get in the Unity Store (now videolabs store).

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.

jchw
23 replies
9h37m

I find the negative reception here confusing. Seems to me they got removed from a marketplace, so they launched their own. They put the announcement into an article about the thing that motivated what's being announced. That is generally what you do, because otherwise the article would leave you with the impression that you have no option going forward, and a follow-up would reach fewer people. Just doesn't make sense.

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

johnnyanmac
7 replies
4h15m

Seems to me they got removed from a marketplace, so they launched their own.

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.

jmull
3 replies
3h45m

We're hearing one side of the story here, so who knows, but looking at it from Unity's perspective...

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

smaudet
1 replies
2h52m

Except that's not what happened at all, at least per the article they use LGPL and have LGPL code all over their store, and refuse to work with the OP at all over the issue.

Unity are absolutely to blaim here, this is indefensible.

jmull
0 replies
39m

Except that's not what happened at all

You're not disputing anything I wrote though.

If a license violation is reported and Unity ignores it their legal risk is higher than for violations no one has reported. The report forces their hand, to a degree.

From the post: "Enforcement is seemingly totally random, unless you get reported by someone, apparently." ... which is another way of acknowledging enforcement isn't random. The report matters. That's what moves the responsibility for adhering to the license from the asset provider (VLC in this case) to Unity.

BTW, "other people are doing it too" isn't a great excuse for violating license terms. If that was OK, then licenses would be generally be almost meaningless.

Regarding Unity's direct usage of LGPL code, that's on them. They need to make sure to honor the LGPL license. Nobody made the claim they weren't, so I'm not sure it's relevant.

Here's another bit from the post that I thought was telling: "After months of slow back-and-forth over email trying to find a compromise..." What compromise? If you find out you're violating an open source license you stop as promptly as you reasonably can. It's not a matter of negotiating with Unity -- that's a separate agreement. It sounds like they eventually came to the right conclusion re the LGPL components, but why was honoring the LGPL license even in doubt? It makes me think they aren't really sincere about open source licenses (and maybe other licenses or any kind of agreement). Note, this point is entirely independent of Unity and whether or not they are screwing VLC. When distributing binaries built with LGPL code, they have a responsibility to honor the license, but only seemed willing to do so reluctantly and belatedly, after pressure from a business partner.

dangus
0 replies
3h32m

...if they had previously received a report of a violation and did not resolve it..

"Resolve it" would include working with the offender to remove the LGPL violation. They could easily document the process and demonstrate a good-faith effort to comply.

Sure, Unity is well within their rights to kick Videolan off their store. It's the cheapest way to comply: no need to collaborate with store vendors and put any hours into that sort of thing.

But that's all it is, a cheap way to comply. It's the laziest form of compliance at the expense of their own customer experience.

throwaway2037
1 replies
2h54m

This whole system of arbitrary enforcement on an "app store" seems weird to me. Real question: Would our economies be better off with stronger regulation around app stores? In the last one year, I am leaning more towards yes. My thinking: Many small companies are completely beholden to a single app store. If any small thing goes wrong, the business get the middle finder and suffers greatly. It seems like a David and Goliath situation, but Goliath drives a Leopard 2 tank and David still has a sling shot.

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.

djbusby
0 replies
2h39m

Like disputing with Amazon. Step one: pay $2000 for arbitration.

It's out of reach for many Davids

torginus
0 replies
2h48m

To be fair, since the LGPL part of VLC is FFMpeg there's zero chance that they can produce a working product without LGPL code.

ziddoap
2 replies
3h22m

Either way, a request: please stop using "clickbait" to describe literally anything you don't like.

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.

PH95VuimJjqBqy
1 replies
2h29m

I disagree in general (although I agree this article isn't clickbait).

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.

ziddoap
0 replies
1h51m

In your opinion, what makes your example article title clickbait? Is it using the word "shatters" as opposed to "more than doubles"?

Maybe I'm just stuck on an old definition or something, but in my mind, clickbait refers to a headline that is purposfully dishonest about the content of the article. Having an eye-catching title doesn't mean it's clickbait if the article delivers on what the title says.

I guess I would also classify any title that doesn't give any representation of the article content as clickbait as well. "Airbus shatters records", as an example, wouldn't give any indication of what records were shattered, thus baiting clicks.

But, maybe the word has evolved to refer to any non-boring title and I just haven't caught up to the times.

theseagin
2 replies
7h44m

Not all hero's wear capes. You sir are definitely one.

master-lincoln
1 replies
4h43m

For expressing their opinion and providing reasoning? Seems a bit inflationary to me to use the word hero here

froh
0 replies
4h22m

no, for changing the mind of the original author of the posted article.

benj111
2 replies
9h16m

The sudden disjoint between story, and selling you a thing does seem very click baity.

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.

tankenmate
1 replies
9h1m

The article said they got banned from the Unity store several months ago and tried for months to reconcile the issue, and now they have come up with a solution for their customers in the wake of the banning. They even included the correspondence from Unity in their article, so barring Unity coming forward with evidence of double dealing on the part of VideoLAN I struggle to see how "this story has been dug/made up purely to sell a product".

Without some evidence your conclusion seems to be a hand wave.

benj111
0 replies
3h58m

"this story has been dug/made up purely to sell a product"

No I said that's how it reads, Its why i suspect that people are saying it's click bait.

My actual conclusion comes in the following paragraph.

This is actually interesting from a marketing perspective.

We all understand that marketing is there to sell us stuff. This is making us aware of a product, so it is in that sense at least, marketing. But then people don't like being 'sold to', at least they don't like noticing. This takes the form of 'marketing' that we don't recognise as such, but the disjoint puts it into an uncanny valley where it annoys people more than it objectively should.

Is that un hand wavey enough?

oefrha
1 replies
9h10m

If you actually read the very long ad, you’ll realize they’re promoting all the unrelated stuff, mainly their consulting packages. The only thing not mentioned is VLC for Unity, you wouldn’t even know it’s in the Store without clicking though. Nobody gets roasted for saying “by the way, you can get this banned product from <place> now”, this is some next level shit that makes people question your integrity and your one-sided story.

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.

smaudet
0 replies
2h44m

To be completely fair, their plug-in is still freely available. After being kicked off by unfair and unreasonable (uncompetitive?) practices, it's not unreasonable to say "hey they suck so we are doing our own thing over here". If someone robs you it's not unethical to set up shop elsewhere.

Asking for money for support is entirely reasonable as well.

agsnu
1 replies
9h11m

In Unity games on platforms like Windows, Linux, macOS sure - but one of the advantages of their toolkit is supporting porting to many platforms, like PlayStation, iOS, etc where the platform vendor store model’s DRM & code-signing gets in the way of end users swapping out dynamic link libraries.

coldacid
0 replies
5h14m

Yeah but there's nothing saying that you have to support _every_ platform Unity runs on if you offer some package extending the engine.

pvg
0 replies
1h42m

I find the negative reception here confusing. [...] Either way, a request: please stop using "clickbait"

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.

martz
0 replies
8h5m

post author here. Yes, basically all of what you said. I've edited the post.

ghusbands
15 replies
10h1m

The LGPL gives end users the right to replace the LGPLed part with a modified version, and users presumably cannot alter parts of a downloaded Unity app. So it does seem that software using an LGPL library cannot be distributed on Unity or most any modern app store and still be in compliance with the LGPL.

It's not viral, but it does give users rights that aren't natural under the app store distribution model.

tedajax
5 replies
4h39m

Seems like another good argument for why the GPL and LGPL are actually kinda shit.

m463
1 replies
3h39m

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

tedajax
0 replies
40m

Yeah because MIT, BSD, etc don't exist or anything

freedomben
0 replies
5m

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.

anthk
0 replies
3h35m

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

Snow_Falls
0 replies
3h21m

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.

larschdk
2 replies
9h44m

It's not impossible to comply with LGPL under the app store model, but the responsibility falls on the distributor, which is Unity in this case. I can understand that that is something they are not able or willing to do. This doesn't mean that they can't comply with LGPL for components included in Unity itself. I don't see any double standard here.

tankenmate
1 replies
8h56m

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.

larschdk
0 replies
8h51m

Very different. They can do that, because they are in control of the components and build process. That's much harder for someone else's deliverables.

captainmuon
2 replies
7h22m

I can give you a right, but that doesn't mean you're neccessary able to excercise that right. I can allow you to drive a tank on my property, but you probably can't afford one, and it would be banned by laws.

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.

troupe
0 replies
4h43m

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.

ghusbands
0 replies
6h39m

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.

naasking
1 replies
4h13m

The LGPL gives end users the right to replace the LGPLed part with a modified version, and users presumably cannot alter parts of a downloaded Unity app.

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.

Steltek
0 replies
3h46m

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.

chippiewill
0 replies
5h19m

I don't have experience with tinkering with typical Unity apps. But we have one at work and on Linux it literally has the `.so` files for native libraries in a standalone directory (including one LGPL library that we use) which you can easily replace with a differently compiled version if you so desired.

toyg
14 replies
10h53m

Can anyone explain what looks like complete idiocy here? Why would the LGPL be so "radioactive" from Unity's perspective?

Looks like yet another faux pas by a company bent on self-destruction.

reactordev
11 replies
10h52m

Anything derivative or including LGPL code assumes the license. It prohibits commercial use unless you also adopt LGPL.

https://fossa.com/blog/open-source-software-licenses-101-lgp...

Qwertious
5 replies
10h47m

LGPL is specific to the library. A proprietary application can ship with an LGPL library, as long as the library hasn't shipped with proprietary modifications.

reactordev
4 replies
10h45m

But Unity can’t do that because it transpiles code on build… simply linking using LD wouldn’t make you have to adopt. Any modifications would, and would have to be published in source code form.

This is why, in Unity, LGPL is the black plague.

thecatspaw
2 replies
9h33m

unity only does transpiling for C# to native code if you enable it in your project. it cannot transpile the (presumably) linked native library so this shouldnt be an issue here

reactordev
1 replies
31m

Consoles operate a bit differently. Sometimes it’s necessary to binary patch. Breaking LGPL.

debugnik
0 replies
21m

These VLC packages only had assets for Windows, UWP and Android.

justinclift
0 replies
10h40m

Why would transpiling mean anything special?

boxed
4 replies
10h46m

You are confusing GPL with LGPL.

reactordev
3 replies
10h41m

“Generally, dynamic linking of LGPL code is considered best practice, as static linking makes meeting the license requirements more complicated. While it is possible to comply with LGPL code that is integrated into proprietary code as a statically linked library, it requires more effort. There is a kind of safe harbor for using LGPL code as a dynamically linked library; for statically linked libraries, a distributor must offer access to not only the library’s source code, but other information or materials necessary to rebuild the program.”

This makes IL2CPP kinda hairy in Unity-land. Since it’s being modified to static-link, it must be released as source. So no, I don’t think I’m confused at all.

adrian_b
1 replies
10h12m

LGPL has nothing to do with IL2CPP, even when the library is statically linked.

Regardless how Unity might transpile their applications, they must be combined with a LGPL library only after everything has been converted into binary object files, by the linker.

In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.

No other information about the proprietary source files or about how they are compiled needs to be provided.

If it is desired that no function names should be leaked from the proprietary code, everything except the LGPL libraries can be pre-linked into a big binary object file without information about the internal symbols, which can be linked with the LGPL libraries only as a final step for generating the statically-linked executable.

In this way, there is absolutely no difference in the information provided when static linking is used and when dynamic linking is used.

The claim that dynamic linking is necessary with LGPL libraries is completely wrong, because linking them statically, but only after linking the other libraries, is completely equivalent.

charcircuit
0 replies
9h57m

In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.

This isn't possible with IL2CPP.

Karliss
0 replies
10h9m

IL2CPP should affect only .NET libraries, it won't do anything to included native code .dll,.so libraries. I would expect that in 80% of cases the LGPL librararies you might want to use are actually written in C or C++ so they would still be dynamically linked even with IL2CPP.

lupusreal
0 replies
7h37m

It is as you suspect; Unity is run by idiot suits who don't understand their own business.

justinclift
0 replies
10h51m

Probably overly cautious legal advice from lawyers who don't know how much LGPL stuff is already in the store and used by Unity itself.

rendall
5 replies
10h54m

Why would Unity do this?

Diti
1 replies
10h35m

https://www.theguardian.com/games/2023/sep/12/unity-engine-f...

Remember this?

I wonder what’s going on in the Unity executive’s heads right now.

firtoz
0 replies
9h8m

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

usea
0 replies
10h15m

Incompetence is the most likely explanation.

hiccuphippo
0 replies
5h0m

If you see them release their own video add-on in the next few months then there's the reason.

firtoz
0 replies
10h46m

Most of the good people have left Unity or have been laid off. Whoever remain are likely ill equipped to deal with anything. So I see these kinds of decisions as the death throes of the company.

winrid
4 replies
9h46m

Steam also does not allow GPL licensed code: https://partner.steamgames.com/doc/sdk/uploading/distributin...

Edit: if you want to link against SteamWorks

jchw
1 replies
9h33m

Note that 1. this is mostly regarding the Steamworks SDK that you link to; sufficient care may be taken to try to make this linkage to Steamworks "compliant" as noted in the article, and 2. this is about GPL, not LGPL. Distributing LGPL code via Steam may introduce some potential murkiness, but it should be mostly kosher since I think Steam doesn't, in and of itself, impede on the user's ability to exercise the rights granted by LGPL.

winrid
0 replies
9h14m

Right, sorry, forgot that. Edited!

seba_dos1
0 replies
9h34m

Games and applications distributed on Steam don't have to integrate with Steamworks SDK at all, and when they don't this licensing issue doesn't apply.

SXX
0 replies
9h26m

You dont have to use Steamworks to be on Steam.

There are a lot of games under GPL on Steam.

moss2
2 replies
9h8m

Wouldn't be surprised if Unity is developing their own multimedia engine they want to sell. Shitty practices like this is what makes me want to get into politics.

yard2010
0 replies
4h13m

Ikr if you can't beat them join them and hf

UberFly
0 replies
53m

This was my first thought. They can then sell some poorly-executed knockoff, ignoring that a partnership with actual experts would have been the best for their customers.

mort96
2 replies
7h44m

This comment section is so interesting. It's a great example of the value of PR; that it's not what you do that's important, but how you frame it.

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.

polski-g
0 replies
5h7m

Their plugin wasn't banned, their entire account was banned.

martz
0 replies
7h40m

You are correct, I should have framed it this way. I've edited the post. Thanks.

jbk
2 replies
8h20m

(Disclaimer: President of VideoLAN here)

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

vertis
1 replies
6h9m

Ah, when I was using Unity I would often buy items I could have built myself even though they were open source, for several reasons:

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

yard2010
0 replies
4h9m

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

jasonjmcghee
2 replies
10h42m

Look, I'm frustrated with Unity as a company too, but a hit piece as a product announcement?

jovial_cavalier
1 replies
6h51m

It's not a hit piece if the allegations are true.

spywaregorilla
0 replies
2h42m

Not true. Folks love to print stories that are true but not noteworthy. And then they post a note about the things that were noteworthy but old news.

zackmorris
1 replies
2h25m

It might be time for a mutually-assured destruction lobby/guild.

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.

flkenosad
0 replies
1h38m

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.

This is brilliant.

yard2010
1 replies
4h17m

Fuck unity. Every time people have fun some aspiring jerk with an MBA comes to ruin the party for everyone involved.

stackedinserter
0 replies
2h51m

It's not an MBA jerk, it's just party grows in size and becomes visible to the judicial system, therefore susceptible to adult problems such as lawsuits from FSF.

numpad0
1 replies
10h2m

Didn't Unity have its own included media stack?

martz
0 replies
8h3m

they do but it's fairly limited.

DeathArrow
1 replies
11h5m

They still can publish their assets outside of the Unity store. Users can download them and install them in Unity. But I agree it's not a nice move from behalf of Unity.

nacs
0 replies
1h27m

And in the linked article, VLC mentions they have now done that -- they have their own site to download the plugins.

sylware
0 replies
3h23m

There is no issue with the LGPL. The lesser GPL does not propagate to the whole.

weird.

sushi_dragon
0 replies
5h40m

ff

nojvek
0 replies
2h49m

App stores (or generally moderation) is a complex thing to get right.

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.

nightowl_games
0 replies
4h24m

How does unity itself comply with the LGPL if it uses LGPL code?

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.

mayli
0 replies
10h32m

The ban of "VLC for Unity integration".

loa_in_
0 replies
10h54m

That makes the name Unity very ironic right now.

larodi
0 replies
4h24m

Software business ha never been too polite to competition.

jamesholden
0 replies
10h52m

From the article:

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.

eterevsky
0 replies
4h45m

It sounds like this article tells only part of the story. Why would Unity ban VLC? I wonder if they have given any official comments about this.

cupofjoakim
0 replies
5h24m

Not a video game developer - but I wonder if it'd be a good call for videolan to make a vlc plugin for godot? It's still gaining momentum and (afaik, could be wrong) have the same thing as unity with a inbuilt media stack but it's fairly limited.

chrismorgan
0 replies
2h31m

The packages "VLC for Unity (Android)", "VLC for Unity (UWP)", "VLC for Unity (Windows)" have been deprecated.

This is not deprecation. This is removal and banning.

KomoD
0 replies
3h34m

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.

Why not include screenshots of these emails too?