Hence the word "broadly". MIT etc allow for Open Source code to be used in proprietary software, true.
Whether this is good or bad, depends on your point of view, and is very newanced.
For example I can use OPENSSL (MIT licensed) in a proprietary system, but I would argue that is better for end users than not. Having a few solid libraries in play is arguably better than a multitude of home-grown closed commercial libraries.
OSI is clearly not FSF. FSF persues a future with no proprietary software. That's a necessary stance for someone to have in the world, it sets a goal post. OSI seeks to make code that has maximal utility by being useful in open and closed environments.
MIT does not prevent companies contributing code, it does not hold back a project in any way, it just makes the code more widely spread and more "utilitarian".
Edit: so it does not eliminate "all" the benefits of Open source, it may remove some of them. Alternatively it may be a net gain if the software is actually used more.
Technically, yes, a company can fork OPENSSL, add features to it, and ship it closed. But why would they? Certainly if the did they remove no utility from openssl for everyone else.
Equally SQLite has a public domain license and that does not seem to have hurt it in any way. There are plenty of contributers etc.
> I can use OPENSSL (MIT licensed) in a proprietary system
You can use LGPL libraries in proprietary software.
> MIT ... makes the code more widely spread and more "utilitarian"
Not for the end users and for developers that want to modify existing software. The "utility" is lost.
> a company can fork OPENSSL, add features to it, and ship it closed. But why would they?
It happens every day. Weak licenses allow freeloading.
> Equally SQLite has a public domain license and that does not seem to have hurt it in any way.
That's not the right metric. The people who are being hurt are developers and users who cannot buy a truly open phone/smartwatch/router/tv/car even if such devices are built on OSS.
yeah, a dev worked for no financial incentive other than the feel good of "open source" while doing MIT code and someone comes in, takes that code, slaps their proprietary tag on it and suddenly the same dev cannot get the benefits of "open source" even when he was doing the work for the greater good.
on the same vein, the same dev works on GPL code and he/she knows the virality of GPL makes it that no one can slap proprietary license on any fork of his work and he/she, if they became the customers of any forks, they CAN expect and demand source, completing the feedback loop.
That same dev _chose_ the license they wanted to use.
Some choose GPL because they value freedom over utility. Others choose say MIT because they value something else.
Naturally all open licenses (free and open source) allow anyone to take that code, compile it, and sell it. This is not a bug, this is a feature.
If the one selling the code makes changes to it, or augments it in some way, and assuming they follow the terms of the license, this is all good. The original author is getting exactly what they hoped for since that's why they chose that license in the first place.
In exactly the same way users make a choice about what software to use. They can choose something proprietary like iOS or something more open like Android. They can choose to use Android coupled to Google services, or not.
I get the goal that the FSF has of making users care enough to only use Free software. That is a noble goal, and we need a organisation that sets that goal.
Equally with hardware they can, and should, champion the cause of completely open hardware.
They are successful not just when all hardware is open, they are successful by making it part of the conversation. It took software 40 odd years or so for Open to become mainstream. It'll take some time for the hardware case to reach some form of critical mass.
All correct except the word "virality". There is no such thing. People can use [A][L]GPL software according to the license or not use it.
Software licenses, and any other work under copyright law, cannot "infect" other works. It's not Covid.
If I draw Mickey Mouse on my hand I might be in breach of Disney's copyright and I might be required to wash it away. It does not mean that my hand magically becomes Disney's property.
Whether this is good or bad, depends on your point of view, and is very newanced.
For example I can use OPENSSL (MIT licensed) in a proprietary system, but I would argue that is better for end users than not. Having a few solid libraries in play is arguably better than a multitude of home-grown closed commercial libraries.
OSI is clearly not FSF. FSF persues a future with no proprietary software. That's a necessary stance for someone to have in the world, it sets a goal post. OSI seeks to make code that has maximal utility by being useful in open and closed environments.
MIT does not prevent companies contributing code, it does not hold back a project in any way, it just makes the code more widely spread and more "utilitarian".
Edit: so it does not eliminate "all" the benefits of Open source, it may remove some of them. Alternatively it may be a net gain if the software is actually used more.
Technically, yes, a company can fork OPENSSL, add features to it, and ship it closed. But why would they? Certainly if the did they remove no utility from openssl for everyone else.
Equally SQLite has a public domain license and that does not seem to have hurt it in any way. There are plenty of contributers etc.