5 ms·

It's a good thing to point out that judges are notoriously indifferent about "he said that she said" type arguments. In the presence of anything that looks like

It's a good thing to point out that judges are notoriously indifferent about "he said that she said" type arguments. In the presence of anything that looks like a license text or contract that's usually what they take as the starting point for a decision. In so far that is enforcable of course. Most longer licenses usually have some language stating what happens when certain things aren't enforcable. With GPL, the version matters. I'm not aware of any GPL v1 licensed stuff, it probably was a bit short lived. But there's quite a few things licensed under GPLv2 and GPLv3. v3 tried to close a few loopholes v2 had that some companies working with e.g. Linux or Java see as a feature rather than a bug. Many corporate lawyers don't like GPL style licenses and particularly AGPL because these licenses have a lot of things to say about things like intellectual property, patents, servers, and uses that are/aren't allowed that probably isn't OK with most corporate lawyers worth their money. With GPLv2, this stuff has been through the courts a few times so the industry seems comfortable with it at this point. Whether those lawyers are right or not is not something engineers should be overruling based on vague notions of fairness, gut feelings, loose interpretations, etc. The whole "it's fine because we're all nice people" doesn't have much value in a court room. Licenses are for when people stop being nice to each other. I prefer the MIT license for my own projects. It's simple and clear and completely uncontroversial with corporate lawyers. It has decades of use, is well understood, and has very little ambiguity. Lots of OSS is licensed with it. It's fair for developers and users. Users being able to do what they want with the software is fully intentional on my part. That's a freedom I give them with that license and not something I actively want to restrict. Fully understood and intentional.

gnuser 3y ago
Of course the corporate lawyers and enterprise settings are going to take this position, but I find your flippant dismissal of GPLs core uses and purposes seem to belie you are just in a group that prefers the non-user friendly licensing. That’s ok, but you can’t hand wave away that GPL, especially v3+, is about protecting and defending the user (like tron), while MIT/BSD is not, by calling it “vague notions of fairness” as if GPL hasn’t already seen wins in the courts… on this point I think some research might be due for me though. I’m just so very tired of the “hey me and my banker/lawyer/insurance friends all hate this - that means it’s useless and dangerous for everybody” I say the GPL and copyleft and the four freedoms for the user are the tools we use to fight these types of corporations in the first place, and I truly believe not only is GPL not dead but that it will play a vital role in our near and long term future. Choose your weapons wisely.
- crest 3y ago
  Imo the question is do you want to protect passive users access to the code or developers freedom to use the code how they want it even if that does mean they take existing code, modify it slightly, put it in an embedded device, and enable temper protections on the MCU preventing anyone but them from signing new firmware images? If that embedded device is something harmless like a video player or gaming console most open source developers would probably like to use the license as a crowbar to force the device open, but what if it's a medical device, or a payment terminal the user is explicitly not trusted to modify?
  - the8472 3y ago
    If anything medical devices, especially implants, should be modifiable. Otherwise you're stuck with an unmaintainable device (possibly in your body) once the manufacturer goes out of business or the support window ends or whatever. Right to repair and all that. And this is a very real concern. https://spectrum.ieee.org/bionic-eye-obsolete https://spectrum.ieee.org/bionic-eye-obsolete For external devices breaking some big, visible "last inspected on XX/XX" seal to do so would be acceptable. For payment terminals you could do the secure boot thing where replacing the manufacturer keys and flashing custom firmware wipes the TPM storage.
  - Nullabillity 3y ago
    For payment terminals the core problem is that the trust model is ass-backwards. The user is the one at risk from a faulty authn device, so they should be the side "controlling" the authn flow. Merchants would be fine just carrying dumb plastic cards with an ID number. Though these days there's little reason not to just make both sides smart… it could even run on the phones they already have!
  - kelnos 3y ago
    To me it's not solely about modification. It's also about transparency. While I most likely would shy away from trying to modify the software of a medical device, I think it should be illegal to lock down those devices so that people can't at least see the code that's running it. If you're going to build something that's going to directly affect my health, I would much appreciate it if it were easy for researchers to find bugs and security issues with the software that controls it. But ultimately I don't care about the whole "legally locked down" thing, and think that concept is a net negative for society. If I can buy a medical device to use at home, then it should be on me if I decide to modify it and it injures or kills me. I expect the law hasn't really kept up with that notion; I wouldn't be surprised that in many cases the manufacturer might still be liable. But that's a legal problem (that should be fixed!), not an ideological one. > ... or a payment terminal the user is explicitly not trusted to modify This is the worst thing, IMO. I wholeheartedly reject the concept of software that I am given to use, but am not "trusted" to modify. Screw that. Unfortunately I do have to use software like that. But I think the entire concept is garbage.
eru 3y ago
One problem I see with the GPL (all versions) is that they make a big deal out of 'linking' your program. And in a world were C was the only language that mattered, that might have been fine. But more modern languages might have more diverse notions of what linking is and ain't, and there might be gray areas, too.
- noirscape 3y ago
  Dynamic linking (also what most more modern languages do instead of traditional static linking) always has been an utter mess when it comes to GPL "virality". It's completely untested in court and a lot of legal scholars doubt the reasoning and interpretations given by the FSF (namely that dynamically linking with a GPLed work transfers the same GPL license to that work) would be allowed by current copyright law. More or less amounts to the question of "do you need to use parts of the original work to make a derivative work". Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract. We know this is legally possible because of what Red Hat does (cut you off as a customer if you redistribute the source code of RHEL) as well as a far more direct legal case in Germany where a WordPress theme maker was able to prevent distribution of a theme they made by arguing that the contract made when the theme was sold overrode the terms of the GPL and prevented the buyer from sharing the theme because of agreed to terms in the contract.
  - megous 3y ago
    It's pretty clear what it means, based on the goals of the license: To allow the user to easily replace/modify the (L)GPL licensed (part) of a program. For GPL, that means you can only include GPLed code if you make the whole program available for user to modify and redistribute. For LGPL, you can include LGPLed code if you make just the LGPLed part of the app available for easy replacement. (so normally this means some form of dynamic linking, and very commonly used in practice with eg. glibc) So if some company statically links (L)GPLed code to their app or makes it in other ways hard to modify/replace, it's a violation.
    - noirscape 3y ago
lelanthran 3y ago
> I prefer the MIT license for my own projects. Yes, but it's a different license! It's not really comparable with regards to preference because the goal of MIT or BSD is different to GPL. If $PROJECT-1 can be modified and then redistributed as closed-source by $COMPANY, then MIT is a good fit. If $PROJECT-2 must only ever be redistributed if $COMPANY redistributes their modifications and derivatives as open-source, then GPL is a good fit. It depends on the specific project, which is why I cannot say "I prefer MIT" or "I prefer GPL", because for some projects I don't want it repackaged and released as proprietary software, while with others I do want others to repackage and redistribute as proprietary software. Proclaiming a preference for one type of license over another is akin to saying "I prefer bicycles", because you aren't going to prefer bicycles when needing transport to move house.
- SV_BubbleTime 3y ago
  You aren’t discussing the controversial part at all. You have laid out the part that everyone agrees with. GPLv2 means you pass your modifications back - easy. GPLv2 might mean that by calling a libraries static functions from your code, that is a “modification”, and now must include code that is not logically a modification at all. This is even more grey area if you dynamically link them - hard. “What is a derivative” has feed millions of lawyer’s family’s, imo this type of broad interpretation does not belong in OSS. Give it to me or don’t, I promise to pass my modifications back, but don’t pretend that integrating it into my code is modification that allows you to see what I do with it. LGPL makes more sense. But GPLv2/3 has a business model and that is why it is popular and complex.
  - ClumsyPilot 3y ago
    > What is a derivative” has feed millions of lawyer’s family’s, imo this type of broad interpretation does not belong in OSS I am sorry but your view is dying out because it’s unrealistic. Most things in life have grey areas, most things in life have legal concerns and liability attached. Even the simplest possible things, like If you sell bicycles and someone breaks their neck, they could sue and there will be grey areas as to the bicycles’s quality. If you sell food and someone gets food poisoning, same thing. The fact that software developers could make millions and never worry about law, is a giant privilege and it’s disappearing because software is no longer just for kittens and porn, it is now everywhere and it’s responsible for life and limb
palata 3y ago
> It's fair for developers and users. Users being able to do what they want with the software is fully intentional on my part. That's a freedom I give them with that license and not something I actively want to restrict. Fully understood and intentional. Sure, but GPL is fair as well. Just differently. I like MPLv2, because it seems like it is exactly equivalent to MIT for projects that don't modify my code, and if they do, it forces them to distribute the changes they made to my code. In practice, I strongly believe that it gives developers leverage against their management: as a developer, I can say "I must upstream my changes because it's MPLv2" (which is not exactly right but managers don't really understand it anyway). MIT doesn't give me that leverage: managers know too well that they can just pretend it's theirs (often even forgetting attribution).
bdw5204 3y ago
The main downside with GPL licenses, from the perspective of corporations, is the requirement to share your changes if you distribute the code. GPL v3 and AGPL were both designed to close loopholes that were useful for certain corporations that didn't want to open source their own code. I believe the main ones were "Tivoization" (devices where you can't run modified code due to DRM) and cloud SaaS services where modified GPL code is run without sharing the changes because technically the cloud is not "distribution". GPL v3 was designed to stop the former and AGPL to stop the latter. FAANG companies generally hate AGPL and ban the use of code licensed under it which is a backdoor way of admitting that their cloud platforms include modified GPL code whose changes are not publicly available. The permissive licenses like MIT and BSD allow corporations to take your code and modify it without paying you or even sharing the changes with you. All they have to do is give you credit. That's not something any sane corporate lawyer is going to care about. Both of these types of licenses permit commercial use without paying the people who wrote the code and the entire FOSS community rejects non-commercial licenses as "not open source" at all. Corporations only object to GPL because it prevents them from taking other people's work, modifying it, distributing it and profiting from it without sharing their changes. That can reduce corporate profits by allowing competitors to build derivative works off of the same code. Personally, I'd prefer if there was a major non-commercial license for code because that would ensure nobody is profiteering off of my work without paying me. People who aren't in this line of work find it strange when you explain to them that somebody could write a portion of a highly successful product and never see a cent in royalties from it.
- GuB-42 3y ago
  > I'd prefer if there was a major non-commercial license for code Non-commercial licenses are considered non-free. If you intend to be share your code with the world and don't want others to profit on your work without giving anything in return, go with something like (A)GPL. Sure, people will be able to profit on your work, but in return, you get all their bug fixes, testing, support, and improvements. You have to realize that most contributions to GPL software is made by people who work for money, something that a non-commercial license would not let them do. So by releasing your software with such a license, you prevent the best people from eventually contributing. And why would you open source your software if not to take advantage of the contribution of others (in code or otherwise)? Another reason why you would want to publish your software under GPL (or compatible) is to make use of other GPL (or compatible) software and libraries, you can't do that if you publish under a non-commercial license. So, lots of drawbacks, few advantages. If you really insist on using a non-commercial license, there are a few listed here: https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses https://www.gnu.org/licenses/license-list.html#NonFreeSoftwa...

gnuser 3y ago

Of course the corporate lawyers and enterprise settings are going to take this position, but I find your flippant dismissal of GPLs core uses and purposes seem to belie you are just in a group that prefers the non-user friendly licensing. That’s ok, but you can’t hand wave away that GPL, especially v3+, is about protecting and defending the user (like tron), while MIT/BSD is not, by calling it “vague notions of fairness” as if GPL hasn’t already seen wins in the courts… on this point I think some research might be due for me though. I’m just so very tired of the “hey me and my banker/lawyer/insurance friends all hate this - that means it’s useless and dangerous for everybody” I say the GPL and copyleft and the four freedoms for the user are the tools we use to fight these types of corporations in the first place, and I truly believe not only is GPL not dead but that it will play a vital role in our near and long term future. Choose your weapons wisely.

crest 3y ago
Imo the question is do you want to protect passive users access to the code or developers freedom to use the code how they want it even if that does mean they take existing code, modify it slightly, put it in an embedded device, and enable temper protections on the MCU preventing anyone but them from signing new firmware images? If that embedded device is something harmless like a video player or gaming console most open source developers would probably like to use the license as a crowbar to force the device open, but what if it's a medical device, or a payment terminal the user is explicitly not trusted to modify?
- the8472 3y ago
  If anything medical devices, especially implants, should be modifiable. Otherwise you're stuck with an unmaintainable device (possibly in your body) once the manufacturer goes out of business or the support window ends or whatever. Right to repair and all that. And this is a very real concern. https://spectrum.ieee.org/bionic-eye-obsolete https://spectrum.ieee.org/bionic-eye-obsolete For external devices breaking some big, visible "last inspected on XX/XX" seal to do so would be acceptable. For payment terminals you could do the secure boot thing where replacing the manufacturer keys and flashing custom firmware wipes the TPM storage.
- Nullabillity 3y ago
  For payment terminals the core problem is that the trust model is ass-backwards. The user is the one at risk from a faulty authn device, so they should be the side "controlling" the authn flow. Merchants would be fine just carrying dumb plastic cards with an ID number. Though these days there's little reason not to just make both sides smart… it could even run on the phones they already have!
- kelnos 3y ago
  To me it's not solely about modification. It's also about transparency. While I most likely would shy away from trying to modify the software of a medical device, I think it should be illegal to lock down those devices so that people can't at least see the code that's running it. If you're going to build something that's going to directly affect my health, I would much appreciate it if it were easy for researchers to find bugs and security issues with the software that controls it. But ultimately I don't care about the whole "legally locked down" thing, and think that concept is a net negative for society. If I can buy a medical device to use at home, then it should be on me if I decide to modify it and it injures or kills me. I expect the law hasn't really kept up with that notion; I wouldn't be surprised that in many cases the manufacturer might still be liable. But that's a legal problem (that should be fixed!), not an ideological one. > ... or a payment terminal the user is explicitly not trusted to modify This is the worst thing, IMO. I wholeheartedly reject the concept of software that I am given to use, but am not "trusted" to modify. Screw that. Unfortunately I do have to use software like that. But I think the entire concept is garbage.

eru 3y ago

One problem I see with the GPL (all versions) is that they make a big deal out of 'linking' your program. And in a world were C was the only language that mattered, that might have been fine. But more modern languages might have more diverse notions of what linking is and ain't, and there might be gray areas, too.

noirscape 3y ago
Dynamic linking (also what most more modern languages do instead of traditional static linking) always has been an utter mess when it comes to GPL "virality". It's completely untested in court and a lot of legal scholars doubt the reasoning and interpretations given by the FSF (namely that dynamically linking with a GPLed work transfers the same GPL license to that work) would be allowed by current copyright law. More or less amounts to the question of "do you need to use parts of the original work to make a derivative work". Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract. We know this is legally possible because of what Red Hat does (cut you off as a customer if you redistribute the source code of RHEL) as well as a far more direct legal case in Germany where a WordPress theme maker was able to prevent distribution of a theme they made by arguing that the contract made when the theme was sold overrode the terms of the GPL and prevented the buyer from sharing the theme because of agreed to terms in the contract.
- megous 3y ago
  It's pretty clear what it means, based on the goals of the license: To allow the user to easily replace/modify the (L)GPL licensed (part) of a program. For GPL, that means you can only include GPLed code if you make the whole program available for user to modify and redistribute. For LGPL, you can include LGPLed code if you make just the LGPLed part of the app available for easy replacement. (so normally this means some form of dynamic linking, and very commonly used in practice with eg. glibc) So if some company statically links (L)GPLed code to their app or makes it in other ways hard to modify/replace, it's a violation.
  - noirscape 3y ago

lelanthran 3y ago

> I prefer the MIT license for my own projects. Yes, but it's a different license! It's not really comparable with regards to preference because the goal of MIT or BSD is different to GPL. If $PROJECT-1 can be modified and then redistributed as closed-source by $COMPANY, then MIT is a good fit. If $PROJECT-2 must only ever be redistributed if $COMPANY redistributes their modifications and derivatives as open-source, then GPL is a good fit. It depends on the specific project, which is why I cannot say "I prefer MIT" or "I prefer GPL", because for some projects I don't want it repackaged and released as proprietary software, while with others I do want others to repackage and redistribute as proprietary software. Proclaiming a preference for one type of license over another is akin to saying "I prefer bicycles", because you aren't going to prefer bicycles when needing transport to move house.

SV_BubbleTime 3y ago
You aren’t discussing the controversial part at all. You have laid out the part that everyone agrees with. GPLv2 means you pass your modifications back - easy. GPLv2 might mean that by calling a libraries static functions from your code, that is a “modification”, and now must include code that is not logically a modification at all. This is even more grey area if you dynamically link them - hard. “What is a derivative” has feed millions of lawyer’s family’s, imo this type of broad interpretation does not belong in OSS. Give it to me or don’t, I promise to pass my modifications back, but don’t pretend that integrating it into my code is modification that allows you to see what I do with it. LGPL makes more sense. But GPLv2/3 has a business model and that is why it is popular and complex.
- ClumsyPilot 3y ago
  > What is a derivative” has feed millions of lawyer’s family’s, imo this type of broad interpretation does not belong in OSS I am sorry but your view is dying out because it’s unrealistic. Most things in life have grey areas, most things in life have legal concerns and liability attached. Even the simplest possible things, like If you sell bicycles and someone breaks their neck, they could sue and there will be grey areas as to the bicycles’s quality. If you sell food and someone gets food poisoning, same thing. The fact that software developers could make millions and never worry about law, is a giant privilege and it’s disappearing because software is no longer just for kittens and porn, it is now everywhere and it’s responsible for life and limb

palata 3y ago

> It's fair for developers and users. Users being able to do what they want with the software is fully intentional on my part. That's a freedom I give them with that license and not something I actively want to restrict. Fully understood and intentional. Sure, but GPL is fair as well. Just differently. I like MPLv2, because it seems like it is exactly equivalent to MIT for projects that don't modify my code, and if they do, it forces them to distribute the changes they made to my code. In practice, I strongly believe that it gives developers leverage against their management: as a developer, I can say "I must upstream my changes because it's MPLv2" (which is not exactly right but managers don't really understand it anyway). MIT doesn't give me that leverage: managers know too well that they can just pretend it's theirs (often even forgetting attribution).

bdw5204 3y ago

The main downside with GPL licenses, from the perspective of corporations, is the requirement to share your changes if you distribute the code. GPL v3 and AGPL were both designed to close loopholes that were useful for certain corporations that didn't want to open source their own code. I believe the main ones were "Tivoization" (devices where you can't run modified code due to DRM) and cloud SaaS services where modified GPL code is run without sharing the changes because technically the cloud is not "distribution". GPL v3 was designed to stop the former and AGPL to stop the latter. FAANG companies generally hate AGPL and ban the use of code licensed under it which is a backdoor way of admitting that their cloud platforms include modified GPL code whose changes are not publicly available. The permissive licenses like MIT and BSD allow corporations to take your code and modify it without paying you or even sharing the changes with you. All they have to do is give you credit. That's not something any sane corporate lawyer is going to care about. Both of these types of licenses permit commercial use without paying the people who wrote the code and the entire FOSS community rejects non-commercial licenses as "not open source" at all. Corporations only object to GPL because it prevents them from taking other people's work, modifying it, distributing it and profiting from it without sharing their changes. That can reduce corporate profits by allowing competitors to build derivative works off of the same code. Personally, I'd prefer if there was a major non-commercial license for code because that would ensure nobody is profiteering off of my work without paying me. People who aren't in this line of work find it strange when you explain to them that somebody could write a portion of a highly successful product and never see a cent in royalties from it.

GuB-42 3y ago
> I'd prefer if there was a major non-commercial license for code Non-commercial licenses are considered non-free. If you intend to be share your code with the world and don't want others to profit on your work without giving anything in return, go with something like (A)GPL. Sure, people will be able to profit on your work, but in return, you get all their bug fixes, testing, support, and improvements. You have to realize that most contributions to GPL software is made by people who work for money, something that a non-commercial license would not let them do. So by releasing your software with such a license, you prevent the best people from eventually contributing. And why would you open source your software if not to take advantage of the contribution of others (in code or otherwise)? Another reason why you would want to publish your software under GPL (or compatible) is to make use of other GPL (or compatible) software and libraries, you can't do that if you publish under a non-commercial license. So, lots of drawbacks, few advantages. If you really insist on using a non-commercial license, there are a few listed here: https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses https://www.gnu.org/licenses/license-list.html#NonFreeSoftwa...