These things almost never are, and the purists risk a purist death spiral.
It reminds me of the closed source drivers debate.
Someone has a proprietary component they want to incorporate into an open source system.
The purists demand they open source that proprietary software if they want it integrated into the open source.
The developer wants a compromise, but the purists won't allow it, so the developer is left to pick up their ball and go home.
And it rarely ends with the developer open sourcing their proprietary system; they often just shrug and leave, which leaves the open source system behind on tech compared to closed source and then proprietary software truly eats the world.
> The purists demand they open source that proprietary software if they want it integrated into the open source.
...and as a result we got GPLv2, GPLv3, open Intel, AMD and Broadcom drivers. Lastly Paragon donated NTFS source code to kernel tree (...and probably many smaller examples I've forgot).
> The developer wants a compromise, but the purists won't allow it, so the developer is left to pick up their ball and go home.
Because purists don't care about the developer, they care about the user. MIT/permissive licenses are for developer freedom, but xGPL and other strong copyleft licenses are for users' freedom.
As a developer, I contribute to projects licensed permissively, but I license all my code with GPL, because I care about the user who's gonna use and explore it, and I don't want my handful of users to be locked out of developments.
> And it rarely ends with the developer open sourcing their proprietary system; they often just shrug and leave...
Again we have Intel, AMD/ATI, Broadcom, Logitech, Paragon software and others.
>MIT/permissive licenses are for developer freedom, but xGPL and other strong copyleft licenses are for users' freedom.
That's a bit to simple, being a user of FreeBSD i just want opensource, i would never use a FreeBSD-fork that is no open anymore, so i have even more freedom as a dev and a user.
>Again we have Intel, AMD/ATI,
The Intel driver is BSD and ATI is MIT, and i think it's absolutely logical for those two to take that license's, and not GPL.
But please don't get me wrong, GPL2 is a great license.
I think that the point here is that as a user, with MIT you may not have a choice. Of course, you would never choose a FreeBSD fork that isn't open. But if you buy a TV running a closed fork of FreeBSD you might never even find out. In that case, it was great for the developer: they were able to get a great OS for free. However, it was not great for the user: they get a closed OS that they can't patch, upgrade, downgrade, or change in any way that the developer doesn't approve of.
Ok look, i have that TV that run's Linux, they even send me a "CD" with all the source-code of linux/gnu of it, BUT there is that highly proprietary module loaded into the kernel, firmware and so on, so patching my TV is as easy as re-engineering a whole closed-source system.
In theory the idea is great, in reality it makes nearly no difference.
What do you wish was done differently in the open source drivers debate exactly? We have closed nvidia drivers, they're shitty but they work, people who don't want closed drivers can avoid them, people who don't mind them can use them. It seems to have successfully pushed AMD to open-source their drivers, and now even pushed nvidia to make the in-kernel component of their drivers open-source.
Would you have wished that the Linux project should just have incorporated closed-source kernel modules into mainline? Who would that have helped?
Outside the GPU space, tonnes of companies are publishing their drivers' source code under the GPL. I don't think they would have if they didn't have to. Isn't this a good thing? As someone who works on embedded Linux systems for a living, I'm certainly very thankful that I don't have to deal with closed out-of-tree kernel modules.
Seems like the strategy has been extremely successful at achieving what it was meant to achieve. Whether those goals overlap with your personal ideals or not is a different story.
I've dealt in high-compute situations where the next-gen networking equipment required linux kernel shims. Always thought it sounded like a backdoor personally.
Microsoft is not releasing a partly open-source program, they're replacing an open-source {Python, C#} extension with a proprietary one that won't run on VS Codium or Arch Linux packages.
At the time of writing, the upvote:downvote ratio on the announcement issue is almost 1:20, so I'm initially skeptical about your implication that this is some kind of fringe part of the developer community.
To me it seems more likely to be a culture clash - one team is used to developing closed source tools that have been highly prized by the company in the past, and another team has had great success writing open source tools that are widely adopted.
My guess is that the adapter code project is currently within the former team's remit, leading to this situation -- but that's all complete conjecture on my behalf.
It reminds me of the closed source drivers debate.
Someone has a proprietary component they want to incorporate into an open source system.
The purists demand they open source that proprietary software if they want it integrated into the open source.
The developer wants a compromise, but the purists won't allow it, so the developer is left to pick up their ball and go home.
And it rarely ends with the developer open sourcing their proprietary system; they often just shrug and leave, which leaves the open source system behind on tech compared to closed source and then proprietary software truly eats the world.