> One of two conditions must then hold: either a) dlopen has legal significance, or b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work. Which is it?
Afaik the FSF agrees with your dichotomy and expresses the latter opinion. Take for instance their faq "You cannot incorporate GPL-covered software in a proprietary system. ... However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."
In another question, they address the notion of what might be considered a single combined porogram. "It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
"If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."
So I don't think that the FSF intends that you can use a technical means to escape linking. You cannot take a GPL library and write a pair of libraries which expose its functions via a socket because the result would almost certainly involve "function calls to each other and share[d] data structures".
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.
> If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble.
As far as I know, the FSF takes the view that linking is a logical concept not a technical one, and so communicating via IPC is just as much of a problem as loading a program into your own addressable memory.
> This conclusion is absurd: therefore, our premises are wrong.
I don't think you've demonstrated that it's absurd. For instance, it could be that MySQL does not believe it is a problem, and does not intend for it to be a problem, and will never sue for it - but that MySQL is wrong as a matter of law, and one day the FSF will sue someone in court and win and the Oracle lawyers will realise they have new opportunities for financial gain. Personally, I think that reality is more like this - the FSF and Oracle have different ideas about what it means to release code under the GPL and so the freedoms you get from the FSF are different from the freedoms you get from Oracle, and it's unclear to me what will hold up in a court of law. I certainly don't think there's anything absurd about the notion that different agents have different intents and conflicting understandings. (Note that I take the notion of freedom to include the confidence that I won't be sued by a rational agent for doing something, regardless of whether I could plausibly win the case or not.)
> I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.
I don't think it makes a difference whether the case law is there. The difference is made by whether you're willing to go to court over it. If there is a chance that you will win a case, and there is a chance that you will loose a case, and that if you lose the case you will have to spend the next six months on full time development just to get back where you were before hand, then you might say "even though my lawyers say there is an 80% chance that we will win, I would rather use this BSD alternative, because the risk of that 20% are existential".
So, fundamentally, this is a case of put your money where your mouth is. If you think the GPL does something different than what "industry" thinks it does, then make your business, make your millions, and dare someone to sue you. No one else has an obligation to do that just because you haven't seen the case law.
> I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so
Btw, here you have a false premises. You don't have permission to copy libmysql.so except by the terms of the licence. I think you've made a mistake. Let's go back. You said "I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that." But now you're claiming that the GPL's grant of permission is so absolute that you don't need the permission that it grants. In fact, the terms of the licence are limited, and the question is only to what extent they are limited.
In any case, there is one important consideration. And that is the intent of the FSF. If the terms of the GPL fail to have the legal consequence they intend, and they can modify the GPL to have the legal consequence they intended, then you can be sure they will. And if Oracle has a different intent, and likes the legal consequences that the GPL has, then they might continue to use the unchanged licence. But arguing about whether the GPL does to the FSF's code what the FSF wants the GPL to do is more about arguing about whether it is buggy, then arguing about the feature set. You are well advised to listen to the FSF's interpretation if you want to rely, indefinitely into the future, on an up-to-date version of the FSF's code. But the FSF's interpretation might not really be as important when it comes to Linux or MySQL or any of the other GPLed code bases out there.
It's not that bad. For a long time ads could only be targeted based on correlations rather than personal information. Ads weren't completely random. You would read a travel magazine targeted at men and there would be advertisements in there about flights to some location or recreational activities or male-coded razor blades, whereas a travel magazine targeted at women would have advertisements in it about flights to the same location, different recreational activities and female-coded razor blades. You would take a train to work and there would be advertisements about local restaurants and banks offering home loans in your area. You would exist and you'd get advertisements about an American soft drink.
In the early days of the internet, few enough companies wanted to advertise on the internet - advertisers viewed it already as targeted at a certain segment of society - so advertisements were generally very low value i.e. crap. Tracking technology let advertisers know that they could actually find the people didn't realise were using the internet. But nowadays we all know everyone is on the internet, and we tend to use the same sites regularly, so you could get adequately targeted ads (as a set of eyeballs - not necessarily as an advertiser) just by using the internet.
If you and your friends declare that you are independent of the country you're actually in and stop paying your taxes, then at some point it's reasonably likely that that country would send an agent to your property and talk to you about your tax bill. So you say "You have breached the Foreign Acts Act 2024 of the Principality of Shrx" and arrest them and you confine them pending a trial (the Foreign Acts Act provides for three years' jail, but doesn't allow the death penalty). The agent's boss realises they never returned and identifies their last known position as your property and you say "this is my country and he has been arrested pending trial for breach of our law". They contact the police and attempt to use violent force to free their agent. You shoot back. Your best friend is shot beside you, and you shoot one of their police. They retreat and wait for more firepower and eventually defeat you. You declare that the police officer who killed your friend is guilty of murder under the Crimes Against the Person Act 2024, whereas they declare that you are guilty of murder and treason under the National Criminal Code. Your body is physically confined to a certain place, decided on by a government, for 23 years until finally you die of cancer, whereas the police officer who killed your friend suffers no unreasonable limitations on his freedom; like the other police officers who did that job, he receives a medal for bravery, and he keeps working as a police officer for another two years until his wife convinces him it's too dangerous now they have a kid, so he joins his dad's lumber business. He does suffer from stress as a consequence of the murder, but the police force pay for twenty-four hours of psychological counselling a year (over and above the 12 hours he gets from the national health insurance system) which helps even if it doesn't completely match the costs during the worst times.
It's clear that the abolition of the death penalty isn't actually all that relevant to this scenario. We can still judge whether or not shrx was the sovereign of his territory or not.
Isn't that just the same question? The answer is "by the sovereign". If there was a conflict over the right to confine an agent of an Australian government, then whoever wins it is, to some degree or another, the sovereign of that land.
Not just the existing nation states who want to reclaim the land, but also anyone else. Maybe Russia will recognise you for free, but no one else will. They will want something out of it. And they will have to believe it is cheaper to get it by recognising you than by defeating you.
For instance, going back to the "about the size of Singapore" example, OP might try to find a nice perch next to some critical strait, and sink any vessel that passes through which is registered in a country that doesn't recognise them. But if OP gets too good at this, then the US Navy will be upset and start shooting their weaponry at OP. If OP manages to sink a few of USN's vessels, it's possible USN will say "well we will stop shooting you if you let through our vessels", but I wouldn't hold my breath.
It's probably just cheaper and easier to marry into a royal family from some small country that whose royals still have a political power, like Brunei or Liechtenstein, then secretly start a secret murdering spree until your newborn is the only royal left and they offer to make you regent, then launch a self-coup against your own six month old.
One difference I have noticed is that it used to be when I said "five minute timer" it would maybe ten percent of the time hear "five minutes timer" and decide it should search youtube for matching videos. Nowadays, it seems to treat "five minutes timer" and "five minute timer" as equal, but I get more silent misses where it ignores everything I said.
On the other hand, I gave up some kinds of requests. For instance, I used to try "start directions home" when I was driving and it would say "here's a route I found, do you want to start (or some such)" and there would be no way to actually start the directions home without breaking the very expensive law against touching your phone while driving. Does that work today? I don't know, because I've mostly been driving with Android Auto in the last few years and my wife's been in the car on the rare occasion I haven't. But it seems like the Assistant team could straightforwardly improve it.
> On the other hand, I gave up some kinds of requests.
Those kinds of things seem to work absolutely flawlessly for me lately. I had similarly given up on those requests. Heck I had given up on setting timers since that just plain stopped working. A month ago or so I tried changing navigation by voice while driving and to my surprise it worked fine. Since then I've been picking up my use of the assistant more and have yet to have a miss. My main gripe is the trigger word being kinda iffy at times, but I suspect that's due to me still rocking the original pixel. As I understand it the trigger word stuff runs locally so is dependent on your hardware being good.
I used to use a lot of Gtk+ apps, where the menu item was disabled, but all this meant was that it was shown greyed out. In fact, as far as the toolkit was concerned it was still active and still sent a message to the app, and the app was supposed to respond to the message and inform the user about why the action was presently unavailable. I think that was a good choice at the time, because a menu was a stateful bit of UI (clicking the menu item closes the menu), so a fore-warning that the activity is unavailable might help me remember "oh, I forgot to ..." before I see the message, but I can still try anyway and find out what I didn't know.
Nowadays, I think menu options in user interfaces are much rarer, and complex stateful applications are usually HTML web programs where the disabled flag is a hint to the web browser to reject the interaction. Some of these web programs color submit buttons in a washed-out version of the normal color until the form is fully validated, but they will report the reason (to a greater or lesser utility) when clicked - such a widget is not formally disabled to the computer engineer, it's just presented to look like one. I find this subtle distinction frustrating, because it represents an ambiguity of thought that makes precise conversation difficult. Why should a widget ever reject interaction? A widgetset/toolkit is just a medium for dialog between a user and the developer, and they should always be allowed to communicate. A software developer should be able to say "hi widget set, please let the user know this button doesn't make sense at the moment" but they should not be allowed to say "hi widget set, if the user wants to tell me something - i don't want to know it, just throw it away. we're not on speaking terms" (They could, of course, completely ignore the user, but it's intuitively obvious that they shouldn't completely ignore the user. Most developers intuitively want to communicate the reason for the error if they know it's possible for a button to be clicked when they can't handle it, but they often get frustrated because the UI designer didn't clearly indicate to them how they should communicate errors - but perhaps they them what they shouldn't do and now they are stuck).
I liked the option 5 mockup in the link, although I'm not so sure it works for actions (like shooting) so much as state toggles (like activating the weapon). I do strongly disagree with the reasoning at the end of the page "it's okay to break the rules for a piece of software that people often use", because it's 100% a case of "rules for thee but not for me". Aside from the fact that I might have been using Outlook until I changed jobs to a new one (and there's a lot of people who only use Gmail unwillingly/primitively and attempt to use the phone and Teams and Slack and meatspace for their communication needs), it's exactly the most commonly used programs that set the norms for users and software developers. We know how to communicate because we imitate previous dialogues. If the most commonly used programs get to break the rules because some of the people who use them use them dozens of times a day whereas others only want to use the features once a week or two and only manage to use them once a month or so, then the members of both parties will come to the view that cryptic software is fine - one because they use it all the time and have no problem, and the other because they see that hard-to-understand software is highly regarded. And so the designer of a widget designing tool will say "no, it's fine for the widget to show only when it's available, because the people who use this widget-designing software will almost always be using it daily, and they'll only have to learn it once at the beginning of their career". Are they correct? Who knows. At this point it's just a position in the design space by the user interface designer.
To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.
There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that).
But the one option that is rarely used but yields the (IMHO) best results is: design the conceptual model, then build/change the implementation model to be equal to it.
One example for this strategy that is forever stuck in my head is macOS application folders. The conceptual model is that an application can be moved around like a file, and applications be organized in folders like files. But you also want to run an application by double-clicking it. Instead of what Windows (and then Linux) did with links, menus, installing applications and centrally registering them etc., the implementation was changed to be like the conceptual model. A whole class of errors from inconsistencies just vanished.
I'd argue the implementation detail is still hidden. You don't know if Applications use FUSE or are WASM containers or docker images or what not.
Interface is a translator between what user understands ("I press button, channel changes") and implementation detail ("rubber dome changing resistivity, ...causing IR signal to be sent", ...).
Joel Spolsky described these as "leaky abstractions". If the implementation does not quite match the conceptual models, then the implementation "leaks out" to the user. The user is confused because the UI does not match the conceptual model in their head.
Usually, the designed conceptual model imposes constraints on the implementation. Sometimes, the implementation affects the conceptual model (a leaky abstraction). But they are logically orthogonal.
And you can't "abstract away" the conceptual model as if it were an implementation detail. The conceptual model IS the abstraction!
We can keep going. I keep my state in postgres when I'm using Haskell, and I keep my state in mysql when I'm using PHP. It really is a very strange argument.
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.