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.

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?

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

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.

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!

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.

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

It sacrifices the user's freedoms for this. Which is exactly the concern corporate lawyers have with this. Fine if that's what you want but the net result tends to be the vast majority of big companies pretending your project does not exist. Can't look, can't touch, can't use, etc. If a blanket ban on your project across most commercial users is what you are after, AGPL does the job.

> vast majority of big companies pretending your project does not exist.

Good.

Even so that point is wrong as GPL software is widely used in the industry (Linux, gcc, gnu make, etc).

To me, frankly, that would be the goal. For some of the things I work on, I would much rather a company be allergic to it, than believe they can do whatever they want with it.

But for other things, I don't really care.

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.

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.

Unless the GPl'd work provides a novel API that the GPL code implements; that has been tested in court. The API is protected, by copyright, and linking to that API requires the use of the API. That's why you can't just link to GPL'd code will-he–nill-he, without the possibility of serious repercussions.

That phrase you're looking for is willy nilly. You did a bone apple tea.

Shakespeare had it as will he nill he in Hamlet:

> “If the man go to this water and drown himself, it is, will he nill he, he goes - mark you that.” (Hamlet.V.1)

Though I admit I didn't know this until I actually looked it up just now :)

“Will he nill he…” huh, I wonder if that’s the etymology of the modern expression. “Willy-nilly” just seems like a nonsense phrase. “Will he nill he” could be read as “will he or will he not,” right? It seems like only a couple short conceptual hops to go from “whether or not he decides to do something” to “look at all the random things he could do.”

I largely agree with you, but I can imagine a scenario where there is some connection to "Will he? Won't he?" semantically.

> Will he nill he…” huh, I wonder if that’s the etymology of the modern expression.

Well, that's at least what the internet told me, last time I checked.

I suppose I should have looked it up! For some reason I just looked up the definition of nill and tried to work out a plausible folk etymology from there.

Bone apple tea, with an em dash to boot

will (hypen-minus) he (en-dash) nill (hyphen-minus) he

API protected by copyright? Sounds like a judge somewhere dun goofed, that just makes no sense on the face of it. The specific IMPLEMENTATION of an API maybe, but not the API itself.

Yea, that seemed like a massive mistake even at the time. The interface binding code together doesn't strike me as work worthy of protection.

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.

Except the "whole program" bit is in question here. A lot of legal scholars doubt that using the GPL in the way the FSF wants it to be used when it comes to linking would actually confer the terms of that license to the final product (because the FSF wants it to be considered a derivative work of the GPL code). In the EU, it's to the point where the EU themselves have written guidance that they doubt this interpretation applies[0]. This would effectively limit the scope of the GPL to always function like the LGPL/MPL (or any other copyright license that limits the copyleft element to the parts of the program actually licensed as such, as opposed to spreading it across the whole work.)

The problem is that the GPL isn't the law; it's something (a license or a contract, the interpretation of which is a toss-up; the FSF wants it to be a license since it allows shrinkwrapping the terms, all legal enforcement has it treated as a contract) that relies on existing law to function. Which fails to work if it tries to do something that legal framework doesn't allow you to do. You can't enforce copyright over derivatives if it's not considered a derivative to begin with.

If the FSF conceded that the GPL was actually a contract and were to write more explicit terms stating that this is a requirement to using GPL'ed source code, they'd probably not run into this problem, but because they insist on forcing it through the framework of copyright the virality of the license only goes as far as the definition of derivative works go.

[0]: https://joinup.ec.europa.eu/collection/eupl/licence-compatib...

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

What case was that?

> Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract.

I don't really think that's a problem, per se.

Regarding your second example, that's totally fair: effectively the theme maker (who is presumably also the sole copyright holder) did not actually give the theme to the other party licensed under the GPL: they licensed it differently in that sale, which is 100% their right to do.

The Red Hat example is a little more complex, I think. The GPL says you cannot add extra conditions to redistribution. If Red Hat owned the copyright for everything they distribute, that would be fine: they couldn't say RHEL was GPL-licensed, but they'd be in the clear.

I'm actually surprised they've gotten away with this: as far as "ambiguity in GPL enforcement" goes, I feel like it's not all that ambiguous that RH is committing a GPL violation by adding that condition. All it would take would be for rightsholders of a major component of RHEL (like perhaps the Linux kernel) to complain about this. (Then again, there may be no publicly-stated contract or policy here; RH may just cut off customers who share, and cite vague "we reserve the right to cut you off for any reason" policies.)

(Also I might be getting details wrong here; I'm just going by your description and haven't done my own research into these cases.)

This is not adding any conditions to the GPL: "If you redistribute this GPL software, then we will refuse to license later versions to you."

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

I disagree. The GPL is fundamentally an ideological document with an ideological purpose in a way that the BSD and MIT licenses are not.

All software and copyright licenses are ideological documents. You don't see the ideology in BSD and MIT because it is your preferred ideology.

> All software and copyright licenses are ideological documents. You don't see the ideology in BSD and MIT because it is your preferred ideology.

Please read what I wrote more carefully. The phrase "in a way that the BSD and MIT licenses are not" is doing important work, namely implying that there is a way in which MIT/BSD are ideological.

Perhaps ideological came off as an aspersion? I certainly didn't mean it as one. It's just an observation, and frankly a pretty obvious one. I'm quite sympathetic to the Free Software movement and, at least in the first order, would be happy to live in a world where all software is copyleft.

BSD/MIT is essentially reverting to the natural conditions that would obtain without statutory copyright. GPL on the other hand is actively attempting to motivate sharing and respect for user freedom in a way that is far beyond the natural state of affairs. Thus it's fairly described as ideological in a way that the former licenses are not.

> Please read what I wrote more carefully.

I think GP's reading of what you wrote is an entirely reasonable reading. Their interpretation was the same as mine before reading your follow-up. It did seem like you were saying that the GPL has ideology but BSD and MIT do not.

It would have been much clearer if you had simply said something like, "The ideology behind the GPL is very different from that of the BSD or MIT licenses".

> Please read what I wrote more carefully.

I read what you wrote and I came to the same conclusion as GP. What's wrong with simply saying "BSD/MIT has a different ideology to the GPL"?

Is that what you mean to say? If it is, why say this (which means something else):

> BSD/MIT is essentially reverting to the natural conditions that would obtain without statutory copyright. GPL on the other hand is actively attempting to motivate sharing and respect for user freedom in a way that is far beyond the natural state of affairs. Thus it's fairly described as ideological in a way that the former licenses are not.

I think you're still trying to portray one more positively than the other; you're writing a lot of words to claim "I'm not really saying that" while actually saying that.

I agree that the GPL's ideology is different, but I don't think you need to agree with the GPL's ideology to use it, just as you don't need to agree with the BSD or MIT licenses' ideologies to use them.

You can simply make a practical choice, based on what your goals are for a specific project. If you're looking to build a community around your project where both hobbyists and corporate users/contributors end up in your commit history, you might choose (A)GPL. That's not to say there are no public corporate contributions to BSD- or MIT-licensed projects, but I expect using the (A)GPL could increase the likelihood. Well, aside from the effect of companies that simply refuse to touch GPL'd software.

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.

I wasn't discussing any part at all, I was explaining why the goal of the project determines the license and not the preference of the authors.

If the goal is to allow others to close off the product, then one license is suitable. If the goal is to prevent others from turning it into a closed source product, then you choose the other license.

When the goal is "popularity amongst closed off companies", then one license makes sense. If the goal is "popularity for the community" then the other license makes sense.

There was a no value in arguing over which is easier for companies unless the goal is popularity for companies and o close off.

After all, any company that simply wants to use the software without redistribution doesn't really care.

> 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

Show me where quality of software is in this discussion.

That’s a different criteria.

The software now has to compliant. Its not always higher quality

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

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.

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

> And why would you open source your software if not to take advantage of the contribution of others (in code or otherwise)?

Because some people do things for different reasons than you might?

I'm not the person you're replying to, and usually use GPL for things that I care about, and BSD 3-clause for things where I don't care so much. But I can see the appeal of a non-commercial license, about only allowing something for personal (or, say, non-profit) use, and refusing to allow anyone to profit monetarily off your work.

It's fine if you don't want to use something like that, but I think it's unfair to cast aspersions on the concept.