4 ms·

I'm still trying to figure out what the issue is. It sounds like MS is making a better cpptools/C++ extension mouse trap and it's impossible to build a fully O

I'm still trying to figure out what the issue is. It sounds like MS is making a better cpptools/C++ extension mouse trap and it's impossible to build a fully OSS version because many of the MS components are closed? And when a user discovers he/she can't use their native extensions from any web interface, this is a problem for the web interface guys? I have to ask -- if people want to use this freeware instead of OSS software, it might be disappointing, but is that really a problem? If there is an answer, it would seem to be more information about who is to blame. Perhaps open source vendors should be more clear that their offerings are also open source and open ecosystem? Perhaps that would tip off devs that not every extension is, that is -- the MS alternative extension is not. One could even be more forceful: "Certain alternatives, like vscode-cpptools, are NOT licensed under an OSI approved license. vscode-cpptools contains many unexamined binary blob components. Developers of blah blah blah C++ extension strongly believe in an open ecosystem for VSCode extensions, but MS has also refused to allow redistribution of vscode-cpptools, if used by native open source builds or by those offering VSCode via web services. Developers of blah blah blah believe, whether the code is closed or open source, ALL VSCode extensions should be freely redistributable for the good of the broader VSCode extension ecosystem." If major extension projects are aligned, they could simply add a notice like above to their description on their marketplace page? Trust me, legally, culturally, MS really, really doesn't want to deny access to its marketplace, because a few OSS projects wanted to offer a comparison of their license terms to those of MS. Apple is currently dealing with a marketplace lawsuit. MS doesn't want a marketplace or another antitrust suit.

CrimsonCape 2y ago
Here's a simple example: you write an API consisting of one public function. You compile the API into a binary with a closed source license. You then create another API with one public function. This function is an extern call into the library binary. You publish the second API into Github with an MIT license and proclaim your API is open-source. The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source." Or in other words, who draws the line when someone oversteps the intent of "open-source" for exploitative reasons. I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed.
- mustache_kimono 2y ago
  > The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source." I get it. I disagree that it's false advertising, though I do agree it could be scummy. For instance, if MS created a combination package, licensed that package as MIT, whereas the important bits were proprietary. Maybe any conflation of licenses have since been scrubbed from the marketplace, but from what I see on their license pages right now, I'm not sure MS's behavior rises to scummy. The Python package makes pretty clear it includes pylance, and pylance makes clear it's not MIT licensed. > I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed. It should be well known by now vscode-cpptools and vscode-python are partially closed, which is good enough as closed, which is good enough as BSL, etc. If it's not clear, then that's a failure of the open source community and alternatives to make it clear. The license links seem pretty clear to me. Perhaps it would be better if the situation were made even clearer, like a badge for OSI licensed packages, but it's not yours or my store. My God's honest feeling is transparency and building better stuff is really the only remedy. You either believe in the FOSS development model or you don't. You either have a strong open source language community or you don't. If the C++ or Python OSS people can't muster an alternative, it's not MS's fault for building a better mouse trap which only works with MS products. There is this overwhelming desire in FOSS communities to works the refs, or even FUD wrong-thinking projects, instead of saying: "They have a development model and so do we. We believe ours is better." Python, in particular, has so much interesting language server stuff going on in Rust (see Ruff and pylyzer). Re: C++, clangd is apparently very good too. It stinks for the ecosystem that MS has acted this way, but I think one just needs to very clear about whose fault it is when something breaks, or when someone can't use an MS extension, because it's obviously MS's fault.

CrimsonCape 2y ago

Here's a simple example: you write an API consisting of one public function. You compile the API into a binary with a closed source license. You then create another API with one public function. This function is an extern call into the library binary. You publish the second API into Github with an MIT license and proclaim your API is open-source. The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source." Or in other words, who draws the line when someone oversteps the intent of "open-source" for exploitative reasons. I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed.

mustache_kimono 2y ago
> The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source." I get it. I disagree that it's false advertising, though I do agree it could be scummy. For instance, if MS created a combination package, licensed that package as MIT, whereas the important bits were proprietary. Maybe any conflation of licenses have since been scrubbed from the marketplace, but from what I see on their license pages right now, I'm not sure MS's behavior rises to scummy. The Python package makes pretty clear it includes pylance, and pylance makes clear it's not MIT licensed. > I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed. It should be well known by now vscode-cpptools and vscode-python are partially closed, which is good enough as closed, which is good enough as BSL, etc. If it's not clear, then that's a failure of the open source community and alternatives to make it clear. The license links seem pretty clear to me. Perhaps it would be better if the situation were made even clearer, like a badge for OSI licensed packages, but it's not yours or my store. My God's honest feeling is transparency and building better stuff is really the only remedy. You either believe in the FOSS development model or you don't. You either have a strong open source language community or you don't. If the C++ or Python OSS people can't muster an alternative, it's not MS's fault for building a better mouse trap which only works with MS products. There is this overwhelming desire in FOSS communities to works the refs, or even FUD wrong-thinking projects, instead of saying: "They have a development model and so do we. We believe ours is better." Python, in particular, has so much interesting language server stuff going on in Rust (see Ruff and pylyzer). Re: C++, clangd is apparently very good too. It stinks for the ecosystem that MS has acted this way, but I think one just needs to very clear about whose fault it is when something breaks, or when someone can't use an MS extension, because it's obviously MS's fault.