In some sense, this ought to be an opportunity. VSCode’s ecosystem is, in many respects, quite weak:
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.
VSCode also, by design, obscures what’s really going on on the development environment, so that when I help a VSCode user who gets stuck, they often don’t know what computer they’re logged into, where their files actually are in the file system, which Python interpreter they’re using, what HTTPS_PROXY is set to, and so on. The ssh extension also spins up a server process for every client a user connects, and it seems a bit inconsistent about preserving state across disconnections. All in all, I spend a lot of time helping people fix problems they’ve made for themselves by using VSCode.
> - The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
This is a big concern for our Infosec team. There is no middle ground between open access to every Extension on the marketplace or locked down and Extensions are installed via local files. The latter being a significant overhead in maintaining VSCode.
All these same things are true for emacs/vim/CLion plugins as well. You kind of either have to accept the risk cowboy style, do something in the middle (maybe only allow very well known extensions from source you trust), or live without the extensions.
The clangd extension is much better for me, assuming that you have or are able to generate a compile_commands.json (at least easy in cmake) and point clangd to it.
> The client, accessing remote repos, is wildly insecure, by design
Who's the best kid in the block regarding third-party extensions security?
There's really not much standing in front of a supply-chain attack for my editor of choice, emacs. Most people use a community extensions aggregator that also directly fetches from git repositories. The only slim advantage we have is that I'm sure a much higher % of emacs users would actually look into the source code of the extensions they pull.
If you want to be cautious, I have somewhat higher confidence in the versions of Emacs packages published on the Debian repositories[1] than the ones on ELPA/MELPA.
The downside is that not every package is packaged for Debian, and the versions are a bit stale.
This is quite surprising to me if true. Microsoft has for years touted "Security is everything and the single most important thing right now", yet something that basic is not taken care of for the most security minded audience, and for the audience with probably the biggest impact in case ssh-keys and alike gets stolen?
People randomly installing extensions (and Visual Studio Code suggesting random extensions by "language support") starts to look a lot worse than I thought. Guess I'm lucky I never jumped aboard the Visual Studio Code train...
Extensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or definitions, ...) and on your filesystem (SSH Config, Kubernetes config, Config folder in your home, ...). Sandboxing these extensions is not easy unless everything is configured within VSCode which is rarely the case.
As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
I am still waiting for many Windows extension scenarios that only support in-proc COM written in C++ to finally support out-proc COM with .NET, regarding how the whole security story is going on.
Yes, their C++ LSP isn't really good and I've heard C# isn't good either - but that's because they want to sell Visual Studio too. But especially "Remote SSH" and "Dev Containers" are so called game changers. And their Typescript and Python extensions are actually good.
C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) itself - this is what the base C# extension[1] uses. Both of these are licensed under MIT.
The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].
[2]: https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
Lately they've begun embedding the same C# analysis stuff they have in VS into VSCode if you pay for the license. I haven't used it in anger (long since left for Rider), but it has come in handy when troubleshooting people's VS issues at work from my Mac. The test explorer now blows up in exactly the same way in VS and VSCode :)
in a few tiny comments it demonstrates precisely the problem the larger ecosystem is facing and will almost certainly get much much worse sooner than we think.
VSCode is not open-source, and neither is this extension.
Much F/OSS on Windows and virtually all F/OSS on macOS has proprietary build dependencies (e.g., MSVC on Windows, Xcode and various Apple frameworks and GUI toolkits on macOS), but is still itself F/OSS. It's true that such software doesn't promote or embody software freedom to the same extent as free software written for free platforms and built with free toolchains and dependencies.
But this case isn't about that. Reread the comment of maintainer (presumably an MS employee) at the end:
> I'm sorry to let you know that our license also prohibits using our extension in alternate distributions of VS Code - only the official one produced by Microsoft may be used. So even if we did produce a RISC-V version, you wouldn't be licensed to use it with Code Server.
That's just proprietary, software plain and simple.
Recall freedom 0 of the free software definition:
> The freedom to run the program as you wish, for any purpose (freedom 0).
In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions as the first-party distribution does, VSCode also fails the test of freedom 3, regardless of the license of much of the code:
> The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions, but the actual outcome is the same.
It's not a different story for the term open-source. This:
> May we ask why you'd like to do this? If you're planning to redistribute the language server binaries as your own custom offering, please note that our runtime license prohibits that.
means that the extension fails condition 1 (the redistribution criterion) of the open-source definition. And VSCode not allowing modified redistributions the same rights as the original fails condition 3 (the derived works criterion).
Neither VSCode nor this extension is open-source. They're both just proprietary software with some open-source components.
Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
Partly true, partly false. VS Code is FOSS (MIT license). The VS Code binary that Microsoft distributes is freeware (proprietary license).
> and neither is this extension
Correct.
> That's just proprietary, software plain and simple.
Indeed, the Pylance extension is proprietary software.
> In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions
False. Third party distributions of VSCode can absolutely use compatible extensions. The license of certain proprietary extensions does not allow you to use them with third party distributions of VSCode.
> It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions
The VSCode license prevents you from reverse engineering, modifying it, and you agree to send some telemetry to Microsoft. You're correct that the MS distribution is not FOSS. It's the same with Chrome (the code base) and Chrome (the browser binaries that Google distributes).
> Neither VSCode nor this extension is open-source.
Again, to be clear: VSCode (the binary) is not OSS, but the source code used to build VSCode (the binary) *is* OSS.
Pylance (the extension) is straight up proprietary software.
> Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
The MIT license represents a different view on the social and technical goals of open source software. It's much simpler than the GPLs and only has one obligation for the user/redistributors: display a copyright notice. It's not as copyleft as the GPLs.
clangd is fully open source. You can build it yourself from llvm sources.
It works fine with emacs LSP support. I never used the proprietary extension so I can't compare the functionality, stability nor speed.
"The free software Microsoft is giving away isn't open enough" has to be one of the weirdest modern takes. I remember when "free IDE" meant "Eclipse" or "vim with a billion extensions".
From what I can tell, Microsoft isn't even sabotaging open alternatives, they're just Not As Good. That sucks, but that's just how it works when you're using software made by a company that likes to pay its staff and still make a profit.
I welcome everyone who feels entitled to the source code of Microsoft's very best software to see what true open source, maintained by an independent non-profit organisation looks like. You'll get an IDE that's functional, maybe even features a real debugger, but you'll probably wish you could go back not long after.
People are taking software given to them free of charge for granted. It's not that long ago that you had to buy IDEs for hundreds or thousands of dollars and you had to buy the upgrade if you wanted the next version a couple of years later.
> From what I can tell, Microsoft isn't even sabotaging open alternatives
I think they are. VSIX extensions are supposed to be some sort of open standard, but some Microsoft extensions like Pylance actively refuse to work if they detect running in something other than Microsoft's build of VS Code.
Microsoft's extensions don't work, but that's Microsoft's choice. Whatever open source alternative for Pylance exists (if any) will work just fine.
If they messed with VSCode to sabotage OpenPylance or whatever the situation would be different, but in this case people are just looking a gift horse in the mouth.
>"The free software Microsoft is giving away isn't open enough"
This is not a quote from the article and isn't what the article is saying. It's effectively suggestig that devs are being duped and MS goals are closing essential parts down.
Exactly. Look at the Ashai Linux project. They are doing tremendous work, but getting basic feature parity with a now 3 year old laptop is still ongoing work.
Then once feature parity is done, performance problems are next, if they ever get addressed and completed.
I love the idea for open source software, but the very best software in todays world is always something you have to pay for.
So my problem with MSFT's big plan is that I simply don't know it.
I do know the price I'm paying for using Emacs and Vim. Even though (in theory) they are completely free, in reality there's a price there. Vim and Emacs require time, patience, and dedication, just like any other tools. I know who gains from my choice - myself, the community, and the industry.
I knew exactly how JetBrains profited from my choice of using IntelliJ in the past - I paid for the license and renewed it every year.
But what's MSFT's scheme here? They're giving me this beautiful, nice tool completely for "free"? What price will I have to pay for that choice in the future?
I'm sorry, but I think every dev should remain at least a bit skeptical, do you truly believe that Microsoft, a colossal corporation with a market capitalization comparable to the GDP of Germany, spends an enormous amount of resources to build "a free" code editor, because... I dunno, they love you or something?
We are in uncharted territory. This major corporation has a "big plan" that relies on making their product offerings "open source" while simultaneously surrounding it with a minefield such that the "open source" aspect is camouflage/subterfuge.
"Subterfuge Source" has a nice ring to it, and abbreviated "SS" really drives the point home as well.
They realized by pushing typescript they can drive companies away from java, then when those companies will realize typescript sucks they'll be redirected to c#
Microsoft's software is absolute nightmare pile of trash.
> People are taking software given to them free of charge for granted.
Whooosh: this is the point made by the author of the article zooming over your head. The point is that closed-source software that pretends to be open-source will affect even those who don't need or want to use it.
For example, I don't want to use Azure DevOps (Github Actions) or w/e it's called. It's absolute garbage. Abysmal design, abysmal implementation. But, I'm forced into it because the org I work for has an obligation to put their projects in GitHub. And, against my will, my work and my knowledge is used by Microsoft to abuse their users.
My only consolation is that I do this as a paid job, and I, personally, will not use Github, and will advise everyone I can to do the same. But this is too little. I want to be a good person, and to do my job in such a way that it's valuable to people who requested it. I feel really bad that, instead, I'm indirectly peddling the pile of garbage made by Microsoft to astronomically enrich the few people standing at the top of the company.
Your rant about being forced to use a software your company decided for has nothing to do with the topic at hand, the person you responded to said that VSCode is Microsoft’s very best software. That’s definitely defensible, right now vscode is the most advanced open source editor that ever existed. It came from nowhere in an insanely crowded space and became the de facto standard on every system because it is so good for so many use cases.
Without proposing a model for how the 50+ full time employees who create VS Code justify their collective ~20MM annual budget, this sounds a lot like: “Ugh, they made it mildly inconvenient for my company to benefit from all their engineering work but swap out the product surface and reap the profits by undercutting their product via not needing to fund the engineering ourselves. How lame.”
>Microsoft builds their own IDE for internal use in many other departments
>Budget is acceptable to have a flexible modern tool for their own uses
>Open source it to gain respect within other communities as well as get free code/bug checking and additional extensions written/supported even outside of MS ecosystem, that MS can still use
that's not my problem. my problem is making sure i don't make my own job skills dependent on microsoft's continued goodwill, because historically that has been a guaranteed path to obsolescence. i don't need their engineering work. i have emacs, vim, clang, gcc, idea, eclipse, firefox, and so on
i'm only interested in microsoft's generous gift of blankets if they come without smallpox
Naturally you also generously support emacs, vim, clang, gcc, idea, eclipse, firefox, and so on for them making your livehood possible, selling your skills.
>because historically that has been a guaranteed path to obsolescence
Has it? If there's one good thing about Microsoft, it's that basically anything, even from the stone age, is still supported. You can fire up some executable from the 1990s on Windows and it works and you can probably just be a .net dev for the next 50 years if you want to. If there's one company in this industry that takes long term support and backwards compatibility seriously it's Microsoft
Your skills as a developer are never dependent on the tools, APIs or platforms you use. You can always abstract over that. But yes, effectively using your skills will always be somewhat dependent on some company's goodwill. If a product, platform or feature you use goes away, you need to switch. That doesn't only happen for development IDEs. It's a process of learning that happens (or should happen) continuously in any line of work, and especially in software development.
As a developer you should already be used to having to switch stuff to something else. Going from DX12 to Vulcan, from x86 to RISC-V, from Linux to FreeBSD, from XCode to EMACS, from Perl to Python, from Angular to Flask, whatever.
You also have vscode. What you don’t have is the various proprietary extensions msft makes to vscode, just as you don’t have every proprietary extension anyone has ever made to those listed platforms.
I didn't read the article but I could absolutely see MS doing something shady to promote their AI racket: beginning next year, VSCode Basic edition will remain free, but to use Premium AI Cloud additions will cost just $6/month for a basic plan. (Then shoehorn intellisense and a bunch of other features that used to work fine into the "AI" paywall, because it's 2024 and words don't mean anything anymore).
Or more likely, "the free version will now contain ads and mandatory telemetry, pay to upgrade to premium for a more streamlined experience". Just like the Mafia, create the problem then sell your their solution.
Their business model being bad is not my concern. They're not a broke kid whose bad decisions I'm exploiting.
Edit: OTOH reporting on this as if it's a grand surprise is a bit funny. Like come on, this was obvious from the start. I just didn't care, it didn't feel like a fight worth fighting. And I care about BSD/MIT license devs being exploited about as much as MS' business model potentially falling apart because I turn off telemetry: folks knew what they're going into, and did it anyway because "sempai corpo will notice us." Well, it did, congratulations.
As for me, I don't care. I ain't posting anything on anything lighter than AGPL, ever, but I'm a small bean and ultimately there's stuff I care about way more than software.
Their business model is fine, and telemetry has nothing to do with it. The telemetry aspect of the article is a red herring the author introduced seemingly to elicit more popular support on their website and others like it. The core issue has nothing to to with telemetry and everything to do with licensing and intellectual property.
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.
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.
> 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.
It takes a LOT of reading to find out what the actual point is here, and the concept of a “fractured” “ecosystem” is brought up a dozen times without being explained. A “venus fly trap that is designed to fracture”? What in the heck.
VS Code is an IDE you can download and use for free from Microsoft. It’s not some magical open-source platform/ecosystem thing that anyone can use for anything, which Microsoft has no control over. It’s a product.
It seems like everyone wants to make “universal” developer _services_, but no one wants to build or fund an IDE, or it’s just too hard or something. That’s not Microsoft’s fault.
Not going to defend Microsoft but they provided a massive codebase for free and yeah they have built a product on top, that is mostly free. If you fork you just don't have access to MS servers. Not fair enough?
Also Monaco is the best editor by a thousand miles, front-ends are just using this editor because it's the best. We used to install CodeMirror or Ace when they were the best options.
I'm not sure there was a massive master plan behind the creation of Monaco, on the contrary, they saw an opportunity to make it a standalone project that unlocked countless of web UI.
> The future of software development tooling that is being built is closed as fuck, and people seem to be okay with it because select components meet the OSI definition while missing the bigger picture.
This is such a huge problem and something that I have regularly commented on on Hacker News itself how the open source term is being applied so loosely especially by a bunch of VC funded companies who are further perpetrating this horrible horrible change in language and meaning and the ethos behind the open source movement.
YC itself is funding a bunch of these companies who claim to be open source but do not follow the ethos at all.
The problem is not companies doing this but users and developers not caring or sharing your concerns. All this moralism about ethos and such is just not that relevant.
What matters is that software licenses are legal text documents. The only place where the interpretation of those texts matters is in a court room. I don't think there are a lot of court cases involving VS Code. MS tends to have their house in order on that front.
So, VS Code seems safe enough in the legal sense. Yes, it has some extensions that are not licensed as OSS or that are simply closed source. So what? If that bothers you, don't use those. Or better, fix it by creating some open source. Open source is not a right, it's a privilege that is granted to you at the discretion of the creators of that software. Not something that you can demand from them.
VS Code is a closed source product that includes lots of OSS components. So much that there's VS Codium a well, which is fully OSS. A lot of those OSS components are used in other products as well. And some of those things are fully open source. The value of the VS code ecosystem is that it enables this ecosystem of components and products to thrive.
Readit News
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.
This is a big concern for our Infosec team. There is no middle ground between open access to every Extension on the marketplace or locked down and Extensions are installed via local files. The latter being a significant overhead in maintaining VSCode.
Who's the best kid in the block regarding third-party extensions security?
There's really not much standing in front of a supply-chain attack for my editor of choice, emacs. Most people use a community extensions aggregator that also directly fetches from git repositories. The only slim advantage we have is that I'm sure a much higher % of emacs users would actually look into the source code of the extensions they pull.
The downside is that not every package is packaged for Debian, and the versions are a bit stale.
https://packages.debian.org/search?keywords=ELPA+&searchon=n...
This is quite surprising to me if true. Microsoft has for years touted "Security is everything and the single most important thing right now", yet something that basic is not taken care of for the most security minded audience, and for the audience with probably the biggest impact in case ssh-keys and alike gets stolen?
People randomly installing extensions (and Visual Studio Code suggesting random extensions by "language support") starts to look a lot worse than I thought. Guess I'm lucky I never jumped aboard the Visual Studio Code train...
As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].
[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...
[1]: https://github.com/dotnet/vscode-csharp
[2]: https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
https://github.com/microsoft/vscode-cpptools/discussions/126...
Having not delved too deeply into building from source, this post suggests it's not even possible.
We will need some new terminology to express that a given codebase is OSS licensed and the build dependencies additionally are OSS licensed.
in a few tiny comments it demonstrates precisely the problem the larger ecosystem is facing and will almost certainly get much much worse sooner than we think.
Much F/OSS on Windows and virtually all F/OSS on macOS has proprietary build dependencies (e.g., MSVC on Windows, Xcode and various Apple frameworks and GUI toolkits on macOS), but is still itself F/OSS. It's true that such software doesn't promote or embody software freedom to the same extent as free software written for free platforms and built with free toolchains and dependencies.
But this case isn't about that. Reread the comment of maintainer (presumably an MS employee) at the end:
> I'm sorry to let you know that our license also prohibits using our extension in alternate distributions of VS Code - only the official one produced by Microsoft may be used. So even if we did produce a RISC-V version, you wouldn't be licensed to use it with Code Server.
That's just proprietary, software plain and simple.
Recall freedom 0 of the free software definition:
> The freedom to run the program as you wish, for any purpose (freedom 0).
In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions as the first-party distribution does, VSCode also fails the test of freedom 3, regardless of the license of much of the code:
> The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions, but the actual outcome is the same.
It's not a different story for the term open-source. This:
> May we ask why you'd like to do this? If you're planning to redistribute the language server binaries as your own custom offering, please note that our runtime license prohibits that.
means that the extension fails condition 1 (the redistribution criterion) of the open-source definition. And VSCode not allowing modified redistributions the same rights as the original fails condition 3 (the derived works criterion).
Neither VSCode nor this extension is open-source. They're both just proprietary software with some open-source components.
Free Software Definition: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
Open-Source Definition: https://opensource.org/osd
Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
Partly true, partly false. VS Code is FOSS (MIT license). The VS Code binary that Microsoft distributes is freeware (proprietary license).
> and neither is this extension
Correct.
> That's just proprietary, software plain and simple.
Indeed, the Pylance extension is proprietary software.
> In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions
False. Third party distributions of VSCode can absolutely use compatible extensions. The license of certain proprietary extensions does not allow you to use them with third party distributions of VSCode.
> It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions
The VSCode license prevents you from reverse engineering, modifying it, and you agree to send some telemetry to Microsoft. You're correct that the MS distribution is not FOSS. It's the same with Chrome (the code base) and Chrome (the browser binaries that Google distributes).
> Neither VSCode nor this extension is open-source.
Again, to be clear: VSCode (the binary) is not OSS, but the source code used to build VSCode (the binary) *is* OSS. Pylance (the extension) is straight up proprietary software.
> Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
The MIT license represents a different view on the social and technical goals of open source software. It's much simpler than the GPLs and only has one obligation for the user/redistributors: display a copyright notice. It's not as copyleft as the GPLs.
The same front-end powers their Visual Studio IDE (not Code).
Also, AFAIK, there exist an alternative `clangd`-based C++ extension, which is fully open-source (but I could be wrong).
From what I can tell, Microsoft isn't even sabotaging open alternatives, they're just Not As Good. That sucks, but that's just how it works when you're using software made by a company that likes to pay its staff and still make a profit.
I welcome everyone who feels entitled to the source code of Microsoft's very best software to see what true open source, maintained by an independent non-profit organisation looks like. You'll get an IDE that's functional, maybe even features a real debugger, but you'll probably wish you could go back not long after.
People are taking software given to them free of charge for granted. It's not that long ago that you had to buy IDEs for hundreds or thousands of dollars and you had to buy the upgrade if you wanted the next version a couple of years later.
I think they are. VSIX extensions are supposed to be some sort of open standard, but some Microsoft extensions like Pylance actively refuse to work if they detect running in something other than Microsoft's build of VS Code.
If they messed with VSCode to sabotage OpenPylance or whatever the situation would be different, but in this case people are just looking a gift horse in the mouth.
This is not a quote from the article and isn't what the article is saying. It's effectively suggestig that devs are being duped and MS goals are closing essential parts down.
Then once feature parity is done, performance problems are next, if they ever get addressed and completed.
I love the idea for open source software, but the very best software in todays world is always something you have to pay for.
I do know the price I'm paying for using Emacs and Vim. Even though (in theory) they are completely free, in reality there's a price there. Vim and Emacs require time, patience, and dedication, just like any other tools. I know who gains from my choice - myself, the community, and the industry.
I knew exactly how JetBrains profited from my choice of using IntelliJ in the past - I paid for the license and renewed it every year.
But what's MSFT's scheme here? They're giving me this beautiful, nice tool completely for "free"? What price will I have to pay for that choice in the future?
I'm sorry, but I think every dev should remain at least a bit skeptical, do you truly believe that Microsoft, a colossal corporation with a market capitalization comparable to the GDP of Germany, spends an enormous amount of resources to build "a free" code editor, because... I dunno, they love you or something?
"Subterfuge Source" has a nice ring to it, and abbreviated "SS" really drives the point home as well.
They realized by pushing typescript they can drive companies away from java, then when those companies will realize typescript sucks they'll be redirected to c#
This has to be a joke, right?
Microsoft's software is absolute nightmare pile of trash.
> People are taking software given to them free of charge for granted.
Whooosh: this is the point made by the author of the article zooming over your head. The point is that closed-source software that pretends to be open-source will affect even those who don't need or want to use it.
For example, I don't want to use Azure DevOps (Github Actions) or w/e it's called. It's absolute garbage. Abysmal design, abysmal implementation. But, I'm forced into it because the org I work for has an obligation to put their projects in GitHub. And, against my will, my work and my knowledge is used by Microsoft to abuse their users.
My only consolation is that I do this as a paid job, and I, personally, will not use Github, and will advise everyone I can to do the same. But this is too little. I want to be a good person, and to do my job in such a way that it's valuable to people who requested it. I feel really bad that, instead, I'm indirectly peddling the pile of garbage made by Microsoft to astronomically enrich the few people standing at the top of the company.
That was eclipse.
There are lots of great examples of well funded open source software projects. Companies have a history of killing them off, which hurts everyone.
Doesn't seem that complicated to me...
i'm only interested in microsoft's generous gift of blankets if they come without smallpox
Has it? If there's one good thing about Microsoft, it's that basically anything, even from the stone age, is still supported. You can fire up some executable from the 1990s on Windows and it works and you can probably just be a .net dev for the next 50 years if you want to. If there's one company in this industry that takes long term support and backwards compatibility seriously it's Microsoft
A guitar doesn't make the musician, and the hammer doesn't make the carpenter.
There's specific skill with being able to use tools well, but that's not what makes a programmer, guitarist or carpenter valuable.
As a developer you should already be used to having to switch stuff to something else. Going from DX12 to Vulcan, from x86 to RISC-V, from Linux to FreeBSD, from XCode to EMACS, from Perl to Python, from Angular to Flask, whatever.
Or more likely, "the free version will now contain ads and mandatory telemetry, pay to upgrade to premium for a more streamlined experience". Just like the Mafia, create the problem then sell your their solution.
Edit: OTOH reporting on this as if it's a grand surprise is a bit funny. Like come on, this was obvious from the start. I just didn't care, it didn't feel like a fight worth fighting. And I care about BSD/MIT license devs being exploited about as much as MS' business model potentially falling apart because I turn off telemetry: folks knew what they're going into, and did it anyway because "sempai corpo will notice us." Well, it did, congratulations.
As for me, I don't care. I ain't posting anything on anything lighter than AGPL, ever, but I'm a small bean and ultimately there's stuff I care about way more than software.
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:
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.
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.
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.
VS Code is an IDE you can download and use for free from Microsoft. It’s not some magical open-source platform/ecosystem thing that anyone can use for anything, which Microsoft has no control over. It’s a product.
It seems like everyone wants to make “universal” developer _services_, but no one wants to build or fund an IDE, or it’s just too hard or something. That’s not Microsoft’s fault.
Also Monaco is the best editor by a thousand miles, front-ends are just using this editor because it's the best. We used to install CodeMirror or Ace when they were the best options.
I'm not sure there was a massive master plan behind the creation of Monaco, on the contrary, they saw an opportunity to make it a standalone project that unlocked countless of web UI.
This is such a huge problem and something that I have regularly commented on on Hacker News itself how the open source term is being applied so loosely especially by a bunch of VC funded companies who are further perpetrating this horrible horrible change in language and meaning and the ethos behind the open source movement.
YC itself is funding a bunch of these companies who claim to be open source but do not follow the ethos at all.
What matters is that software licenses are legal text documents. The only place where the interpretation of those texts matters is in a court room. I don't think there are a lot of court cases involving VS Code. MS tends to have their house in order on that front.
So, VS Code seems safe enough in the legal sense. Yes, it has some extensions that are not licensed as OSS or that are simply closed source. So what? If that bothers you, don't use those. Or better, fix it by creating some open source. Open source is not a right, it's a privilege that is granted to you at the discretion of the creators of that software. Not something that you can demand from them.
VS Code is a closed source product that includes lots of OSS components. So much that there's VS Codium a well, which is fully OSS. A lot of those OSS components are used in other products as well. And some of those things are fully open source. The value of the VS code ecosystem is that it enables this ecosystem of components and products to thrive.