Unity's Open-Source Double Standard: The Ban of VLC(mfkl.github.io) |
Unity's Open-Source Double Standard: The Ban of VLC(mfkl.github.io) |
Also, I'm no Unity expert, but C# integrations generally use PInvoke right? It's the most dynamic of linking, there's really no inherent reason LGPL libs can't be used in Unity games. At worst, Unity should make sure you know your obligations, but I don't understand the necessity of a blanket ban. I'd be very surprised if VideoLAN, a well-respected organization that has been doing open source work for a very long time, had such a fundamental misunderstanding of the software licenses they use.
Either way, a request: please stop using "clickbait" to describe literally anything you don't like. The article is chiefly about their ban, even the announcement is. By all means, critique whatever you want, but that's simply not what clickbait is. Clickbait is more like "actually we didn't get banned, But..."
not only removed, but removed with no hope of reconciliation (if the author is to be believed). They offered to remove all LGPL code to comply and were refused. Their entire publisher account was banned over what I assume is one infraction. They made it pretty clear that Unity just didn't want VLC on their store.
Idea: What if there were some minimum, legal requirements for app stores? Example: If the app store owner enforces a rule, it must be enforced equally on all apps. (Obviously, that did not happen in this case.) If complaining / escalating due to unfair treatment is not remedied, there is a neutral gov't board that can make a ruling. This is not unlike labour union relations in countries with strong labour laws.
Unity doesn't want to have be the "cops" and "prosecutors" who have to go around to find, investigate, adjudicate and enforce violations in the store agreements. They want partners who, having agreed to the store terms, will make reasonable efforts to adhere to them.
E.g., Unity may have come to the conclusion that VLC violated the terms of the store agreement not by simple mistake or a reasonable different interpretation of the agreement, but on-purpose or through negligence. In that case, the reasonable thing to do is to simply stop doing business with VLC (if it's not too costly to do so), because of the relatively high likelihood it will happen again.
Don't forget that Unity could be sued for violating the terms of LGPL'd software. If they "have received a report" of an LGPL violation, they have to take it seriously. Any future lawsuit would likely be more successful if they had previously received a report of a violation and did not resolve it..
Preach on. This is one of the most annoying things, to me at least, here. If there is a post with more than 10 comments, there's a very good chance one of those comments contains "clickbait".
The word has lost all meaning to me at this point.
the internet runs on clickbait and HN's insistence on reflecting the title of the content itself means a lot of things that are posted are legitimately clickbait.
Just this morning I rolled my eyes when I saw an article titled "Airbus shatters record for jet orders as demand soars" (https://news.ycombinator.com/item?id=38967262).
I didn't even bother clicking on it.
people are getting oversensitive, but not without good reason.
You're better off directing this stuff to whatever negative reaction or word usage you're referring to otherwise you get a subthread of meta/ants. Or for even less effort required, just skip it. Almost all comments are greatly improved by meta-elision.
I think it's because they didn't stay in story mode. "So we decided to set up X..."
To me it reads as if the company has been around for a while and this story has been dug/made up purely to sell a product. And we should expect 15 more of these.
I suspect it's just bad/honest (?) Writing though.
Without some evidence your conclusion seems to be a hand wave.
Edit: Apparently some people can’t understand what I mean by “the very long ad”. It’s everything starting from “Introducing the Videolabs Store”, not the whole article.
Asking for money for support is entirely reasonable as well.
How VLC should have framed this post:
1. Our plug-in got banned from the Unity Store for what we believe are bad reasons. Other high-profile plug-ins with LGPL code are still there.
2. To ensure that our users can still get our plug-in, we set up our own store which sells the plug-in.
3. Also the store has all these other services you can buy.
But they omitted the second part. And the simple act of not explicitly connecting the store to the plug-in ban through enough PR speak seems to have been enough to make people here characterize this blog post as simply an ad for their store.
After months of slow back-and-forth over email trying to find a compromise, including offering to exclude LGPL code from the assets, Unity basically told us we were not welcome back to their Store, ever. Even if we were to remove all LGPL code from the Unity package.
Where it gets fun is that there are currently hundreds if not thousands of Unity assets that include LGPL dependencies (such as FFmpeg) in the Store right now. Enforcement is seemingly totally random, unless you get reported by someone, apparently.
Step 2: we have our own store now!
That’s not a weird pivot, that’s what you do when a company you depend on no longer wants to do business with you.
If we were already aware of all this then this wouldn't have come off in the same way. The problem is that due to the way it was written I think most people expected the plugin to be free on the store. Personally I think it just could have noted that the general interest section of the article was finished when they segued into the store announcement.
Anyway, assuming everything is as they say then it seems pretty clear that Unity have some other reason for banning it, most likely commercial.
I think they're more than entitled to try and advertise a little bit. It's not like they're doing anything evil asking for some money. You can still go download all the code yourself and build it manually for free if you want.
It's out of reach for many Davids
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?
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.
"doubles" is accurate but not as strong in the mind of the reader.
it's like seeing an entry in youtube titled "person x DESTROYS person y" and it turns out it's just your normal, everyday, point/counter-point discussion.
It's meant to increase the odds that you click, and that's literally what clickbait is.
Unity are absolutely to blaim here, this is indefensible.
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.
No.
The OP could have been in the wrong, yet they are willing and capable to make change. Unity has no such defense, merely a combination of laziness/ignorance. Neither of which are a starting place for anything approaching a reasonable defense.
"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.
But most of your comments seem to be conclusions looking for evidence rather than the other way around.
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.
Please be less enraged and try to understand the arguments of others in discussions.
Nothing to do with being "enraged"; in discussions it generally doesn't help to attribute motivation without evidence.
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.
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.
I hope you have a good day too!
Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms; since one of the points of using unity is its cross-platform support, that suggests you’d have to find another library unless you were only deploying on real OSes.
But is that Unity’s problem?
This might be the best opening line of a HN comment I've ever seen :-D
Don't feel obligated to respond, but how do you feel about the LGPL now? How do you feel about it's evolution given the way the world has changed? Would you do anything differently now?
That decade of Cygnus was a lot of hard yakka first to legitimize the idea of free software at all (in 1989 it was mostly both obscure and insane outside academia) and then popularize it. Obviously other people started working hard on this too later in the decade.
The thing that made probably the most significant difference was the process of forking gcc which was a lot of negotiation — at that time forking a code base was widely considered a tragedy, despite the whole structure of free software!). Making forking good rather than a tragedy, coming up with an independent steering committee, and in that case getting the FSF to stop complaining decide to try to run out in front of the parade* was really hard but in the long term it became an approach that most important open source projects have taken, providing stability and progress. That’s definitely been an opment!
And then within a few years…I was on to other, more important things. It felt like the free software / open source world was no longer an embryo so didn’t need me. Plenty of other people are doing great work, better than I would have the enthusiasm for these days.
* Yes yet another case where RMS was furious about something that in the long term was a big win for the FSF too.
I can distribute LGPL licensed code to people no problem even if they are then, additionally, forbidden to actually excercise their freedoms by laws, think for example about radio code. I might have to get a special permission to run the code if I make changes and compile it, but that's no concern of the person licensing their source code to me.
Same if, say, the code runs on a box in an inaccessible space, and in order to install their own binaries somebody would have to press a button that they can't reach. That's not a GPL violation.
If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store. Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons.
Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does explicitly forbid the above mentioned situations?
(And of course this is just my reading as an interested layperson, you're the expert obviously :-))
In the case of the App Store, Apple is the one doing distribution, so Apple must also comply with the terms of the license (in addition to the app developer). Apple has decided they will not do that (that is, people they distribute to will not have the ability to modify the LGPL code, relink the final executable, and run it on their devices), so Apple cannot legally distribute binaries that contain LGPL code.
It only makes sense, then, that Apple should preemptively reject apps that link in LGPL code, as they know that they will not abide by the licensing terms.
> If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store.
That's not permitted by the license. The (L)GPL prohibits a third party from adding extra conditions to exercising the rights granted in the license. "Pay Apple for a developer account and get their permission" is an extra condition. Even if there is a jailbreak-y method of getting around the extra conditions, I don't think that would fly.
> Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons.
Agreed, but I'm not convinced this is one of those cases.
AFAIK Apple just doesn’t allow apps which don’t that on the app store regardless of how the developer would chose to interpret the license
In other words, VLC owns the libraries, and I want to license them under the LGPL 2.1.
The LGPL 2.1 says:
6. As an exception to the Sections above, you may also combine or link a "work that
uses the Library" with the Library to produce a work containing portions of the
Library, and distribute that work under terms of your choice, provided that the
terms permit modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used
in it and that the Library and its use are covered by this License. You must supply
a copy of this License. If the work during execution displays copyright notices, you
must include the copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.
Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code
for the Library including whatever changes were used in the work (which must be
distributed under Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that uses the Library",
as object code and/or source code, so that the user can modify the Library and then
relink to produce a modified executable containing the modified Library. (It is
understood that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application to use the
modified definitions.)
I think that's doable with app stores? I can certainly distribute a zip file with the object files for MortPlayer so that the user can link them against their own version of VLC. The user wouldn't be able to then run the recompiled application, on their device, but that's not specified in the terms...
Honestly I'm a bit surprised, I fully expected to find that this section a) included wording which requires the user to be able to run the resulting linked application, which Apple forbids (asterisk), and then go through b) and conclude that iOS doesn't have a "suitable shared library mechanism" due to its restrictions etc. But I'm instead forced to conclude that you're probably right, at least by the letter of the license.
I read the corresponding parts of LGPL 3 as well, and I can't find anything which requires the re-linked application to be immediately executable on the user's machine there either.
I think my conclusion is that LGPL, both 2.1 and 3.0, is fully compatible with app stores so long as you distribute your application as object code which can be linked against the LGPL licensed libraries? I would be very interested to hear from someone with opposing views about why I may be wrong. I, as they say, ANAL.
That seems very forest-for-the-trees. It's true, but it mistakes a micro-statement of a problem (the app vendor isn't "at fault" for the LGPL violation) with the actual problem (copyleft code of any kind is effectively impossible on the most popular mobile platform in the industrial world).
The bottom line is that it's not possible to distribute a binary containing *GPL code on iOS in any way remotely in keeping with the letter of the license. People do it anyway because this code is important and useful. But Apple has effectively banned the license and that's always going to lead to friction like this.
Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work.
Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?
If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point.
MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
The separate pieces on disk are of course as you say.
Not that copyright propagates.
Obviously, a zip archive containing A and B is a derived work of B. Hence, license of B can say you can't distribute such works.
Does distributing A without B make any sense?
Well:
1. Unity itself is using plenty of LGPL libraries itself so the same concerns apply.
2. If this is not an issue on desktop platforms where you can comply with LGPL there is nothing wrong with allowing such packages on the Asset Store. Certainly not all developers ship their Unity games on most platforms so it should be up to them to figure whether the specific package they decide to include can be used for a given platform.
I'm not a lawyer but this might indeed have some valid issues associated with it depending on how this is done. So, I can see an argument for Unity simply not wanting to put their customers in a situation where they have to worry about these issues. It seems a bit drastic though given how useful it is.
Banning companies/accounts seems like it's simply unprofessional/rude and unnecessary. Sounds like they need to have a conversation with whomever thought that was a good idea about professional conduct.
Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"
Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity?
This was long before we hired Drepper.
When I saw the announcement on the Cygwin mailing list, I immediately set off to make a fork of the main Cygwin DLL which brings Windows-like behaviors.
I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind.
Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love.
For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own.
Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar.
I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software.
I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers.
Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar.
EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc.
[1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it.
[2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.
The freedom of the user to modify the library and use it was the most important part. It’s a fundamental “right to repair”.
FWIW the people involved were just me, plus John Gilmore who said “why not explicitly make dynamic linking automatically qualify?” which was obviously a good idea, and RMS who was bitterly opposed.
The definition of what is a derivative work is IMHO overreaching in GPL based licenses.
In this case, when a company like Unity bans this VLC project for using LGPL software, the guild would open individual lawsuits against them to remove each of the other projects using LGPL code, based on various legal precedents around discrimination. Which would make it untenable to single out projects like this.
This is a negative or low-vibration idea, I realize. Which is actually my point. If a policy causes one to go down these anger/fear/ego-based rabbit holes, then something is suspect with it. This is the litmus test I use.
Somewhere along the way, we lost the wisdom or will to understand the difference between the letter of the law and the spirit of the law. And we sold our souls when we allowed wealth and power to override our discernment of right and wrong.
If Unity wants to step into its power, it can start by abandoning knee-jerk policies designed to protect itself from liability against stupid laws. It can start saving a war chest to go to bat against patent/copyright/trademark trolls for the rest of us and protect the projects within its ecosystem instead of throwing its contributors under the bus. It can set an example for other large companies to follow so that we can eventually reform the system.
But whatever all this malarky is has got to stop.
I really want to like Unity for how it aligns with my goals as a shareware game developer in my formative years and a lot of other reasons, but they make it very hard to do so.
This is not deprecation. This is removal and banning.
Just a few remarks: VLC-Unity plugin is fully open source, and anyone skilled enough can build it themself.
We've tried for months to discuss with Unity and it was a nightmare. We've had discussions for years with Apple AppStore, Google Play store, and Windows Stores (including Windows Mobile + UWP). It's always challenging, but Unity was a headache an order of magnitude bigger: no answers, 3 different answers contradicting each other, and plain bad faith.
De facto, they use LGPL and open source to build their platform, but we're not allowed to have open source on the store? Not even LGPL with a layer of a different license? Why us? Why not the other people doing it?
Very frustrating.
So, yes, because some people need to buy support or licenses, even if everything is open source (don't want to build themselves, purchase department that needs a support contract, etc...), they need to have a small store. This is different from what we see usually, but there is a need, so this is a small store for that.
For most of HN users, you should just build it yourself. You should be skilled enough for that :)
- only so many hours in the day - it's nice to pay people for things they work on - stable release version
I'm thankfully not using Unity any more. Watched the recent installs cluster** from a bemused distance.
The only way to get a consistent response from Unity is paying support.
Their store review queue takes months, now with the layoffs it will only get worse.
They are hurting themselves by not having your plugin. Feels like they are building their own solution but I bet it will take years to release and will be broken.
Unless you are selling the plugin, you shouldn't care. You can host it anywhere and the community will find it.
It's not viral, but it does give users rights that aren't natural under the app store distribution model.
Edit: if you want to link against SteamWorks
There are a lot of games under GPL on Steam.
Once you have humans in the loop, you have bias. Not even humans can follow the set ambiguous guidelines and the appeals process is mostly broken.
AI can somewhat help but language models are just that - language models - they don't have any deep understanding.
Fundamentally I believe moderation will always be broken until we get algorithms capable of understanding the deeper meaning of things and apply them uniformly.
Remember this?
I wonder what’s going on in the Unity executive’s heads right now.
weird.
Why not include screenshots of these emails too?
Looks like yet another faux pas by a company bent on self-destruction.
https://fossa.com/blog/open-source-software-licenses-101-lgp...
The blog post also says all games made with Unity depend on LGPL code. How do they comply?
I'm so glad I generally don't have to think about this kind of stuff day to day.
This is brilliant.
What precedents are those? Can you link or name the cases? I've never heard of such legal theory.
The closest thing I found is the 2023 Students for Fair Admissions v. Harvard Supreme Court decision which effectively ended affirmative action in the US, since Harvard is a private college "doing business with" its students (customers):
https://en.wikipedia.org/wiki/Students_for_Fair_Admissions_v...
https://www.scotusblog.com/2023/06/supreme-court-strikes-dow...
SCOTUS said that race/ethnicity and gender identity are protected classes, so discriminating by them is illegal, meaning that affirmative action can't legally be imposed on universities anymore.
Now, there are extenuating circumstances with that due to the US's civil rights battles and entrenched practices in other areas like policing and access to capital which impose additional struggle on individuals, depending on which protected classes apply to them. So throwing out affirmative action may give individuals unaffected by those practices an additional advantage (privilage). Meaning that the court's decision may have an effect opposite to the one intended, as stated by the dissenting justices. I'm providing this for context, because it's an example of how the letter of the law can be in conflict with the spirit of the law.
As a private entity, Unity must still follow federal antidiscrimination laws. It's not allowed to remove an app from its store based on the race/ethnicity/gender of its author(s) for example.
But prominance/budget and potential liabilities from lawsuits by intellectual property trolls are not protected classes. Currently Unity appears to be free to de-list any app for any reason outside protected classes.
But that discriminitory freedom is also being challenged for antitrust reasons. If a store is dominant to the point that competitors are not widely known by the mainstream, then any type of discrimination could potentially become collusion. For example if Apple delisted an app that competed with its own in order to noncompetitively boost its own sales, then that can be challenged in court. And two or more companies collaborating to remove competing apps in each other's stores can also be challenged in court.
The realities of software development are daunting. It often takes many years of work by countless individuals and budgets in the multiple thousands or even millions of dollars to ship an app. The libraries which the app relies upon are also unique in that an alternative may not be available, either for budgetary reasons around refactoring or for compliance with controversial laws like the DMCA. So an app's dependencies and licenses could be thought of as an ethnic identity for software because they can't be changed in practice. It's what they are.
Main takeaways:
1. A unilateral ban of an app by a company can represent a power imbalance resulting in injustice because the guidelines the app must follow to regain entry are not tenable. In other words dependencies, licences and other nonfungible aspects of software may need to become protected classes.
2. Is the law being applied unequaly between VLC and other apps with LGPL dependencies, or with preferential treatment?
3. What recourse do developers have other than to sue? Will their case have merit? Are there financial barriers and opportunity costs to such actions? The realities of such recourse can impose such hardship on injured parties that their involuntary surrender represents a kind of injustice that favors moneyed parties.
Keywords and avenues to pursue:
unequal application
preferential treatment
protected class
Would lawsuits against other companies along these lines reduce productivity in the tech sector by making it more difficult to do business, highlighting a need to reform legislation around this issue?
They are just being obtuse - which looks fishy when coupled with VLC's claims that they wouldn't allow them back in even if all LGPL code was removed. They probably don't want competition for some component.
But I guess that's another thing they don't want to test in court and it's easier to say they don't want it.
It's easier for them to refuse to be a party to that contract by not allowing any software under that license on their property to begin with.
For example, if you build an app for iOS or visionOS, you have to distribute it via Apple’s stores, and there are technical barriers (code signing, DRM) that get in the way of an end user being able to exercise their right to replace LGPL components with modified versions. I mention this example because there was a big tie up for Unity and visionOS announced with the Apple Vision Pro last summer, but presumably the same applies to Unity games on consoles etc as well.
I can see why from Unity’s perspective it is cleaner to just forbid LGPL entirely, that way it is harder for their customers to mistakenly violate licenses.
I wonder if that is an issue for LGPLv2. Pretty sure that for LGPLv3, the distributor would have to give instructions explaining how to do it (which they could not do), but LGPLv2 does not require that, right?
As in, wouldn't code signing and DRM count as some kind of tivoization?
> 5.10.4 Provider represents and warrants that its Assets shall not contain (a) any software licensed under the GNU General Public License or GNU Library or Lesser General Public License, or any other license with terms that include a requirement to extend such license to any modification or combined work and provide for the distribution of the combined or modified product’s source code upon demand so that Customer content becomes subject to the terms of such license; or (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.
LGPL doesn't impose combined redistribution requirements, does it? They're just tilting against that whole ecosystem specially. And if you apply the same standard as LGPL, MIT/BSD are basically the same right? Probably CDDL falls in too? that's absolutely a crazy thing but it's pretty straightforward in the licensing agreement.
No, no, they got it all wrong:
"not, invented here!"
GPL is a viral license.
The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls. If LGPL had been a viral license too, all programs would have been affected.
> LGPL doesn't impose combined redistribution requirements, does it?
It does, in that if you modify the source-code of an LGPL-licensed library and distribute the binary, you are required to also distribute the source (i.e. the source of your modified version). Your modified source must also use the LGPL licence.
If you distribute an unmodified binary for an LGPL-licensed library, you must also provide access to the unmodified source. (This isn't to say you need to bundle it into the same archive file.)
It differs from the vanilla GPL in that an LGPL-licensed library permits you to dynamically link to it from application code that doesn't need to use any particular licence.
(This is at least the gist of the matter as it applies to application code. This isn't legal advice, I'm not a lawyer, etc.)
See the final point on this page from the FSF (authors of the GPL and LGPL) - https://www.fsf.org/bulletin/2014/fall/common-gpl-misconcept...
Having a simple licensing story for assets on the store lets users have trust in whatever they see they can use in their game worry free.
Edit: Removed bit about LGPL applying to the original code because of static linkage because it was incorrect and distracting from my point
Only linking with a GPL library makes GPL applicable to the whole program.
This is the difference between LGPL and GPL. LGPL is a normal license that applies only to the library.
Since glibc uses LGPL, if your theory had been true than almost all programs run on a Linux system, regardless of their origin, would have been covered by LGPL.
> so now your game code is also under the LGPL and you have to publish your game code.
AFAIK, that's only true of the GPL, not the LGPL.
I'm curious, does the LGPL state explicitly that the licensor guarantees that the licensee can excercise their granted rights in practice? There can always be external circumstances restricting what I can do.
Or is it more like: The licensee (the unity package developer) can only use the code (VLC) if they guarantee that the sub-licensee (the package user or the end user) can excercise all their rights with no external conditions?
Edit: I think LGPL 3 actually does demand this, in the context of preventing "tivoisation". However, libvlc is licensed under LGPL 2.1 as far as I can see.
It feels like such a requirement would mean you would have to test each potential user for technical skills to determine if they are capable of doing the things that you are giving them the right to do.
If I write up a license that says anyone distributing my software must give the recipient the right to drive a tank on their property, I can distribute it, because I am the copyright holder and can do whatever I want. But in practice that software cannot be redistributed, because those license terms probably cannot be fulfilled by any redistributors.
If VLC wants to put something on the Unity Store that includes LGPL code, then their responsibility (and the Unity Store's responsibility, as they are now distributors as well) is that people downloading that Unity VLC bundle in order to use it in their game must be able to replace the LGPL code in it with modified versions. And that part may actually be possible, so this may be ok.
But then the game developer that uses the Unity VLC bundle must also pass along the ability to their end users (that is, the people that buy and play their game, for example) to replace the LGPL code with modified versions. I think that's just not possible with the Unity Store model[0], so the terms of the LGPL cannot be fulfilled.
If this is the case, it's not unreasonable for Unity to ban LGPL code in bundles, because they know that their customers (game developers) will not be able to abide by the terms of the license.
[0] Similarly to how an end-user wouldn't be able to replace LGPL code in an iOS app with a modified version and then run that on their iPhone, at least not without paying Apple for the privilege, which is an added restriction that violates the terms of the LGPL.
The law is not as prescriptive on the exact text as many programmers think. What typically matters in court is what people mutually understand/understood terms to mean, and clear attempts to mislead are typically judged against the one doing the misleading.
So, yes, if it went to a court that was otherwise supportive of (L)GPL, providing (L)GPL code on a platform on which users certainly cannot exercise their rights would likely be a failure to provide and hence abide by the licence.
You can use LGPL software on a multitenant mainframe system, where you don't have access to modify installed software. This was a well known use case in the 80s and 90s, so this doesn't seem appreciably different. The LGPL doesn't seem to require you as a software developer to ensure that the user can run the modified software on the same system on which the App Store version is run, mainly it's to make the source code available so they can, in principle, create a modified version that they can run somewhere.
What you're describing sounds more like the AGPL to me.
Also, your appraisal seems to be assuming that the only goal of the GPL/LGPL is to release software through Unity, which is not correct.
Yea but the article is claiming that Unity is including LGPL libraries in apps built with Unity, not just the editor itself.
The “.. on to other, more important things” left me wondering! Would it be possible to shed some light on that?
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’.
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.
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.
> Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version.
And from GPLv2:
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
In this case, I guess the installation information would have to be "use an emulator and do XYZ".
But that's not the case at all. Apple is accepting apps that include LGPL code.
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?
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.
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?
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.
honestly you are over-reading and projecting here
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.
I suppose I don't know whether TFA is being unfair, but I have no reason to doubt what they say, and calling this a hit piece is a bit of a leap for me.
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.
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.
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.
This isn't possible with IL2CPP.
That's analysis is exactly backwards, and I cited the specific text in the license that calls it out. You can't distributed copyrighted works without permission, period.
Apple can't ship my code, whether it be directly or in a Play Store app, unless I let them. The LGPL specifies the terms of that permission. They're clearly in violation, since I can't download a Play Store app and modify it.
Again, we all agree to ignore this. But it's true nonetheless.
There is no text in the license that discusses the issue of app stores. You have every right to jump to the conclusion without any analysis of how the text of the license applies to these facts. However, you'll of course understand that—by doing so—you aren't likely to convince anyone who doesn't already agree with you.
Do you, heh, have any case law to that effect? No, that's silly. "You're shipping my code and have to stop" is an open and shut case. That no one has bothered to prosecute such a case against an iOS app is notable, but not proof of anything but inertia.
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.
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.
> 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).
Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?
[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...
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?
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).
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.
"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.
This is why, in Unity, LGPL is the black plague.
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.
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).
I find this interesting, and maybe I am just a bit confused. But here is what I am wondering now.
If it is not about the use of an API but about the use of the implementation, then that would mean that the end-user that is running the application which dynamically links to a proprietary library on the end-users pc the one violating the license terms, not the developer that distributed their code without distributing the proprietary library itself.
And if the developer has the rights to distribute the library, because it is under GPL, then they could do so, and would not violate the license terms, because they are not doing the dynamic linking and using of the implementation, that would happen only when the end-user starts the application.
I never heard about any case against end-users, that for instance used the proprietary Nvidia kernel module, compiled and linked on each end-user's PC.
I don't think that works that way, there has to be more to that than just the usage of the implementation that triggers the license violation.
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?
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.
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
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;
}
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.
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.
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.
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.
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.
> 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.
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.
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.
What term defines the scope to which copyleft applies to?
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).
> Absolutely. And I wrote it specifically to do that!
Welp, looks like I was wrong about that one.
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.
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.
The intent of the (author of the) LGPL and the letter of the LGPL (+ applicable law) may well be different. That is, just because the LGPL itself was designed to help with right to repair, doesn't mean it is successful at that job. It's also not necessarily the intention of others who use the LGPL - just like Linus Torvalds' intentions for using the GPLv2 are different from RMS's intentions in writing the GPL (hence why Linux is not migrating to GPLv3).
My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.
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.
> 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.
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.
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.
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.
> (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.
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
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.
> (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.
Moreover, the rule has no rational reason, because unlike with GPL, compliance with LGPL is very easy to achieve, even for proprietary programs.
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.
yes
> And if the developer has the rights to distribute the library, because it is under GPL, then they could do so, and would not violate the license terms, because they are not doing the dynamic linking and using of the implementation, that would happen only when the end-user starts the application.
If they distribute it together though then it becomes an aggregate work
Try to meet other people in the middle?
In this case, after several days of back and forth, nobody has offered any argument for why the terms of the LGPL are incompatible with iOS apps. At this point it's pretty obvious that all of you are just trolling.
What a way to twist things around. Apple (or the app developer, who chooses Apple to distribute their software) doesn't have the right to distribute the code without abiding by the terms of the license. Copyright applies by default unless those terms are met.
TiVo's code wasn't subject to the GPL, so obviously they can have it do whatever they want, it's not remotely analogous to distributing copyrighted works outside the terms of the license that is the only thing allowing you to distribute them at all.
Cryptographic controls might be an end-run around this (as they are being abused for many other anti-consumer purposes today). The license tries to account for this, but it looks like it only applies if the code is included with the device. Unfortunately. The law really needs to catch up with this, it's clearly a hack and not respecting the intent of this or other areas of law such as first-sale doctrine.
(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.
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.
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.
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
The GPL is amazing and wonderful, but the various "attachments" of the GPL are more weaponized (and to the detriment of users!) than the GPL ever was.
I'm glad the kernel stuck with GPLv2, and I wish other things had, too. A GPLv3 Linux Kernel would likely have helped a BSD tremendously, though but I think having everyone work on the same kernel without reservations has been an unmitigated good.
LGPL is a relaxation of the GPL, by the way.
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.
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.
Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.
Sounds like people should use MIT licenses (or similar non-viral licenses) instead of LGPL licenses.
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
And indeed I do not speak for the FSF and never have.
You should try arguing in court for FSF legal theories on linking!
Some things shouldn't change just because entitled people are inconvenienced by them.
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.
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.
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"?
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).
My point wasn't about copying into memory being a license violation, rather the fact that you're combining two works together into a single program that violates the license of one of the works. Who is liable for the violation in that case? The user who combined the works together or the developer who created a program that instructs the user to combine those works together?
Perhaps you're selling a book that's derivative of Stephen King's novels, but instead of actually including text from his novels you insert pages that just say "insert chapter 5 from the Shawshank Redemption here". Even though it contains instructions to create a derivative work, it is not in itself a derivative work.
However if the reader follows those instructions and creates a completed work by inserting those chapters as instructed. That completed work definitely is a derivative work of Stephen King's novels.
I don't think it ever will be.
> program B designed to require library A
How do you design program B to require A, without inspiration from A?
I believe you can't. For a silly example, take a puzzle peice. To integrate support for your puzzle in my work, I'm gonna have to copy some of your edges.
Then I'm the only user of your software, and never request the code, even though ten billion users use it via my proxy.
Like, imagine this hypothetical.
Set up a server. For each unique client that exists, it proxies to one of two backends. One is wrapping an LGPL library. The other is wrapping a cleanroom non-CL implementation.
A given user will always get one or the other. Think of it as being assigned off the high bit of a user hash or something.
Which users have rights under the LGPL? Remember that half of them have never used the (wrapped) LGPL implementation, and NONE of them can tell which group they are in.
I don't actually see the difference as being that distinct from the long accepted fact that a program compiled by a copyleft compiler or running in a copyleft interpreter is not itself inherently copyleft.
The only other thing I could think of to prevent this would be a DMCA 1201 claim - i.e. that the view source link is a DRM system, and that a proxy that removes those links is illegal. Except all v3 licenses explicitly foreclose the ability to make DMCA 1201 claims relating to features of the software.
My guess is, Mastodon used AGPLv3 primarily because the Affero clause scares off big tech companies, notably Google. I don't have access to any IRC logs or issue tracker comments to prove this is the case, though.
Let's assume you modify the AGPL program, so the remote interaction clause kicks in. If you have the software provide links to the source, but you yourself also strip those out before any of those remote-interacting users can ever see or use them, I don't think a court would have a problem saying that you're not actually "offering an opportunity" for the users to download the source and are therefore in violation.
"To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."
"You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:"
I think you would have a very, very hard time arguing that you had conveyed the source under this definition.
This is like paying a parking ticket on a credit card, charging it back, and then arguing that it's paid because you sent the money.
This might have something to do with the way they sign shipped versions and use TPM security to verify what's run, even though you can manually disable some of this if you want.
So all GPL the software shipped on MacOS devices is stuck at the last version which used GPLv2, and they rewrote Samba which they had previously shipped, whose last GPLv2 version is too out of date to keep using.
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");
}
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".
#!/bin/sh
say Alexa what time is it
Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.
But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?
Is that correct? I am also not a lawyer, but this seems wrong to me.
If I make something that is a derived work of some other copyrighted work, my understanding is that I still own the copyright on the parts of the final work that I made (assuming what I made meets the thresholds for being copyrightable). But I am not permitted to distribute that work unless I receive a license to do so from the owner of the work I've derived from.
My understanding seems to dovetail with how the GPL works. If I write a program that links to a GPL library, and that does indeed cause my program to become a derived work of the GPL library, I still own the copyright to my program. In order to distribute my program, I have to abide by the terms of the GPL. But even if I were to violate the terms of the GPL (thus terminating my rights under the GPL), I still would not lose my copyright interest in the program I wrote, only my right to distribute it.
For the "normal" cases, you're right: you can have copyright on the original parts of a derived work. You are fully right though that the original work's author does not in any circumstance get the copyright for the derived work. That was a confusion on my part.
> But even if I were to violate the terms of the GPL (thus terminating my rights under the GPL), I still would not lose my copyright interest in the program I wrote, only my right to distribute it.
As far as I understand though, this is not true. If you were not authorized to use the original work, then even the original parts of your work are in fact not protected by copyright at all. So, if, say, I take a Spiderman comic and add an extra page of fanart at the end, without any authorization from Marvel/Disney, then my extra page of fanart is not protected by copyright at all, and anyone is free to copy it (unless it also infringes on Marvel/Disney's copyright of course) [0]:
> Only the owner of copyright in a work has the right to prepare, or to authorize someone else to create, an adaptation of that work. The owner of a copyright is generally the author or someone who has obtained the exclusive rights from the author. In any case where a copyrighted work is used without the permission of the copyright owner, copyright protection will not extend to any part of the work in which such material has been used unlawfully. The unauthorized adaptation of a work may constitute copyright infringement.
And license itself can then limit the scope of copyleft, so that it applies it to only a specific part of a work.
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.
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.
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.
That one.
> But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?
No, I'm not asserting that that a.out would be a derivative work of Y.
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.
The GPL is a distribution license, not a use license. Once they've received that source and/or binary, they can do whatever they want with it as long as they aren't distributing it. (Copying it to another machine under their control may or may not be distribution, depending on the circumstances.)
Yes, once they want to distribute their copy to others, they need to comply with the terms of the GPL. But not before then.
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.
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.
No it's not. The GPL specifically says that mere aggregation of a GPL-licensed work with another work licensed under another license does not create any sort of GPL obligation on the other work:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
> This License explicitly affirms your unlimited permission to run the unmodified Program
> You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force
So the GPL restrictions apply only on redistribution to others. You can do whatever you want on your systems.
> (a) Making of Additional Copy or Adaptation by Owner of Copy.—Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
> (1)that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or
> (2)that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.
That should cover most likely scenarios of someone combining programs and/or libraries from various sources on their own computer as long as they own the particular copies of those programs and/or libraries that they are combining.
This gets murkier if you're using it in a commercial setting, though.
> You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
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?
> 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?
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.