Hacker News Reader

Comment by Pannoniae | Hacker News Reader

People when a piece of software is source-available but not strictly OSS: outrage

People when Microsoft pulls this trick (core repo OSS, most useful things around it are full of DRM and legal traps): silence

The hypocrisy is really astounding and in a way, MS has managed to pacify even the strongest FOSS advocates by offering something which looks like OSS but it actually isn't. This is on par with claiming that a repo is GPL but the build API keys are not. (Yes, this also happened elsewhere, and not even in a corporate project at all!)

The Open Source Definition is hilariously unfit for purpose in 2024 because it allows shenanigans like this.

If you enjoy a rabbithole, look at how much DRM there is in Pylance (another extension that MS has locked down): https://github.com/VSCodium/vscodium/discussions/1641

The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.

View on HN

"Source-available but not strictly OSS" is, in most cases, not really giving anything of value to the community. You are not free to use it in building your own solutions. At best, it allows easier collaboration with customers.

Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.

This isn't just hypothetical. As far as I know, no source-available license allows you to actually use it to build your own product. While VS Code has many other products built on the core (including products that lawyers have reviewed closely for compliance).

> You are not free to use it in building your own solutions

Tell that to the LLMs.

With licenses like Elastic I agree 100%, but what about delayed licenses like BUSL or FSL?

There are several complications; see here: https://lwn.net/Articles/984249/.

For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available? Does any security fix, even the simplest one, require clean room reverse engineering on part of the community? Unless these questions are answered clearly by the copyright holder, BUSL/FSL are not really usable as open source even after the expiration date.

> For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available?

Yeah, it’s tricky. By default, I think it does go back to source-available, but I would trust the vendor to explicitly release the fix as open source instead. Of course, it should be addressed in future versions of such licenses, and in the meanwhile vendors should promise to not hold security updates out.

It’s not something exclusive to delayed licenses though: vendor of a permissively licensed software can make a security fix under a proprietary license. They don’t do this because it would be a dick move and the community will fork the software, but this is a possibility.

Never "trust" a vendor to do something in your best interest for free. That's like trusting your landlord not to raise your rent.

> Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.

Depending on where the line is drawn. How functional the "core" in a real life scenario is. Often companies use some "enterprise security" features as closed thing, like saml/oauth/... where one could argue those should be default state of things these days.

vscode is seemingly on the right side of the line, considering all the places where monaco and oss vscode has been used.

A program that allows me to freely use and modify it as long as I’m not a multi-billion-dollar corporation is much more useful to me than a program which allows anyone to use and modify a part of it.

> If you enjoy a rabbithole, look at how much DRM there is in Pylance (another extension that MS has locked down): https://github.com/VSCodium/vscodium/discussions/1641

The funny thing is that I’ll never understand why it’s not open source and why its license prohibits its use in VSCodium. Pylance is good, but not that good. Certainly not on a level of PyCharm. What incentive do they have to keep it secret except being evil?

>What incentive do they have to keep it secret except being evil?

Money. Which is OK. Developers need salaries. They need to justify the department budget to bean counters and sales internally. The company you work for is most likely not a charity too.

If you want to strictly use free software (as I do), VsCodium is great for everything I need.

Ok, I’ll rephrase: how do they make money with Pylance?

They make money with VsCode (by forced, or at least hard to disable, telemetry, ads [1], and probably many other subtle things. Plenty of ways to monetize developer eyeballs). Pylance is just a vehicle to encourage people to use proprietary VsCode instead of open forks like VsCodium.

[1] https://github.com/microsoft/vscode/issues/60989

You can't use Gitpod, Theia IDE, etc with Pylance. Or GitHub Copilot. Or Live Share or numerous other VSCode extensions.

The idea is people start a project in VS Code, need to scale up to a reproducible dev environment for multiple users, and follow ads in VSCode to GitHub Codespaces, which charges by the hour for VMs. Now you're locked into that, you're locked into GitHub as well, and they can cross sell you GitHub Actions, GitHub Advanced Security &etc.

Therefore, Pyright is almost the minimum needed to add type checking to your CI process.

Edit: to clarify, not only is Codespaces advertised in VS Code, it also uses private APIs so no competitor can publish an extension which replicates this functionality on the VSCode marketplace.

Like I wrote here [0], corporate has an azure subscription. All the companies code repositories already live there, including build automation. A capable vscodium isn´t going to eat into Azure baseline.

I don´t think MS is after solo hobby devs. For startups they have other incentives to lure them into their ecosystem, like free Azure credits.

And that is why open source projects on github are free too. Because the paying organizations depend on the free software ecosystem, build by volunteers in their free time. MS wants control [1] about that nonetheless, because not having that is a risk to their baseline

____

0. https://news.ycombinator.com/item?id=41695356

1. That is not necessarily harming libre software per se, but keep in mind that MS is only interested into OSS as long as their commercial customers depend on it.

> The funny thing is that I’ll never understand why it’s not open source and why its license prohibits its use in VSCodium.

And also the fact that Pyright, the underlying library that powers Pylance, is open source. Microsoft even has a mostly workable demo extension built from it, which is fully open source, published in their marketplace, and receives regular updates.

VSCode is build to sell Azure and other Microsoft services, which they won’t if you use VSCodium. To a lot of people this will probably be less obvious than it is to anyone working in a Microsoft heavy enterprise organisation. The VSCode extensions integrate incredibly well with the Microsoft infrastructure you already have when you’re tied into Azure and the Microsoft AI services. It also ties in rather well with both Azure DevOps and GitHub, which are other services you’re then likely to purchase.

I don’t mean this as a negative thing as such. It’s just Microsoft being better at selling products to enterprise organisations than anyone else. One of the reasons Azure has grown from around 10% to 25% of the global market share during the previous past 5-10 years while AWS has actually lost its position is simply sales. When AWS first entered Europe they were a lot like Google Cloud, in that even if you were a municipality you would end up in an automated support loop. Then Azure came along and sold the same Microsoft support as they’ve always done, which is basically the best IT business partner you can have as an enterprise organisation, and naturally they won. It’s not like Amazon didn’t notice, a few months after Azure really rolled out we suddenly had an AWS account manager and direct phone support. But by then the ship had sort of sailed because of how Microsoft simply offers great value. Teams is another good example, it was a worse communications platform than what we had at the time, but it was “free” because it was attached to every user license we had, including the cheap educational ones. Almost nobody in non-tech enterprise will spend money on something they get for free, even if the free product takes years to become as good.

VSCode is the same. We pay for co-pilot and we pay for a lot of the Azure integrations, because why wouldn’t we? In the giant IT budget heading to Microsoft they are tiny costs which are in the “services” category in the excel sheet that heads for the budget. It is tiny, but when you consider just how many EU enterprise organisations buy these services it’ll amount to millions and for some services billions of revenue for Microsoft.

A good way to think of the “new” Microsoft strategy is similar to how cartoons are used to sell toys. You can watch Lego Dreamzzz for free on YouTube because Lego knows it means a lot of people are going to buy their Dreamzzz sets. It’s the same thing with VSCode. On top of that, they’re winning the familiarity game. When you hire a new developer, they’ll want to use what they know, which for many people is VSCode.

Agree with your post, but this gist still doesn´t make much sense to me:

> VSCode is build to sell Azure and other Microsoft services, which they won’t if you use VSCodium

If corporate has bought into MS, they will use Azure services anyway. So for MS it would not matter if vscodium also integrates well with Azure or has a good .net core debugger, their customers will still bring the whole IT budget to them.

Because you are spot on. Corporate buys the whole MS store, only walk the road that MS marketing has blessed and it happily walks into the Azure trap. They outsource IT strategy and planning to MS anyway, and MS names it "Azure".

I’m agree, but my organisation is an example of one which would be in the atlassian ecosystem if it wasn’t for the MS integrations. Which would honestly also be there from the Azure CLI but I’m the only one who uses that and no decision maker likes it. I’m not advocating for it since I personally dislike the atlassian ecosystem (shhhhh).

Hmm.

Source Available is fine by me so long as it isn't being misrepresented as Open Source in an attempt to sponge off of the goodwill generated by Open Source communities. So I'm not feeling the "outrage".

And I spent a good portion of my open source advocacy activities on license compliance at the ASF, helping projects to ensure that even with all the bundled dependencies the aggregate licensing of the distributed artifacts complied with the terms of the Apache License Version 2.0. So I'm not feeling that "silence" either.

What I'm feeling is "hypocrisy" being projected onto a straw man by someone who's got an axe to grind with OSI and the Open Source Definition.

I concede the last part, it is slightly a soapbox from my part about the OSI. However, it's not really a strawman because these issues are very much linked together. The definition itself is very strict yet not comprehensive - false positives and false negatives are both common.

The sentiment that "VSCode is OSI-compliant so it's morally okay to support it" is very common, and it's substantially derived from the OSI definition. I do not think that it's an irrelevant issue or that it would be misrepresenting the definition.

Is it really free (as in freedom) software when it contains DRM? Is it really open source when critical extensions are unusable if you build the software for yourself? It might meet the definition strictly by the words but in my view, this is not much better than TiVo-isation (when the license is adhered to but the user can't effectively use a modified version) or other shady practices.

No moral qualms here. There are large pieces of it that are useful without VS Code (for example, the Monaco editor and the language server protocol). Not to mention al the use people get out of it for free. It seems like the good well outweighs the bad.

>It seems like the good well outweighs the bad.

Oh, I definitely agree. While I don't use the editor (mainly because I prefer full IDEs and not glorified text editors personally) I agree that holistically, the existence of VSC is a net positive to the programming community. My argument comes from a moral perspective - even though the good outweighs the bad, the bad parts are really scummy and need more awareness.

Like, my perspective is not utilitarian, it comes from a deontological point of view. I see people and companies get regularly flamed (or even harassed/intimidated) for much smaller things such as the crime of creating their non-OSI-compliant licenses and various related things. In contrast to that, the VS Code ecosystem is much more proprietary, grants much less practical freedoms and operates from a way less clean moral background than any of these projects. Yet, many people are willing to excuse this because Microsoft has figured out a way to implement vendor lock-in without breaching any of the four freedoms in techicality. To me, this is way worse than someone saying "no we won't let you use our software for anything"...

I am also not a fan of the LSP (good arguments can be found in https://www.michaelpj.com/blog/2024/09/03/lsp-good-bad-ugly....) but that's another topic :)

> crime of creating their non-OSI-compliant licenses

Just don't call it "Open Source" and you won't get nearly as many complaints.

The big problem arises when somebody tries to leech off of the goodwill built up by Open Source communities and give their Source Available proprietary offering some FOSS-juice. (Most often VC-backed companies who have failed to understand that "Open Source is not a business model").

Well, this thread is getting off-topic real fast but okay, I'll reply :)

This argument would make sense from a strictly logical perspective if these were all the facts but the problem is that the expression "open source" wayyyy predates the OSI. It's been used in the 80s and the 90s on Usenet and in various places, and it simply meant software which was distributed in source code form. (as opposed to binary form) These pieces of software didn't even have a license file attached to them which was implicitly understood as public domain, or "do whatever the fuck you want to do with it".

The OSI simply appropriated the term to a narrower, stricter meaning which grants certain freedoms to the user and takes certain freedoms away from the creator. (Such as the freedom to change your mind in licensing! You can't practically change your mind since these are all non-revocable grants)

Furthermore, I don't really agree with the "leeching off the goodwill of OSS" framing. From a practical perspective as a user, having the source code available is way closer to OSI-licensed software than proprietary, closed-source software. You can view the code of the program, you can usually share your modifications with others (which is technically disallowed but the developers are very unlikely to care as long as you don't resell it), you can fix bugs in it, you can change functionality you don't like. A less-commonly talked about side effect is that if the source is available, the developers are less incentivised to provide user-hostile features, simply because they know that the users can patch it out relatively easily. There's many cases of rugpulls and forced functionality changes in software nowadays and almost all of it is possible because the user can't simply change the code to change the unwanted behaviour but must put up with it instead.

Naturally, this is a huge advantage compared to closed-source software. And if a company is willing to share its source code with its users, this should be lauded and encouraged! Obviously, the developers want some benefit from sharing the code, and one of the huge benefits is goodwill by customers. If the developers are not incentivised - but more commonly, harassed and mocked - to share their source but disallow competitors to steal it, in most cases, they will simply not share the code at all, leaving you, as a user, with way less freedom in practical terms.

Both you and the company can't really do anything with paper freedoms - you can't really use paper freedoms and the company can't survive if their licensing permits others to profit off their work while discouraging them of doing so. In this view, having more practical freedoms should be encouraged because it helps both the user in having more usable and more modifiable software, and helps the developers not to go bankrupt when Amazon decides to commoditise their offering or something.

EDIT: I conflated "developer" with "company" when writing this post. My apologies. Of course, everything above also applies to natural people who develop software too, not just corporations. I made this mistake because of the subject matter (Microsoft), sorry.

> users can patch it out relatively easily.

This applies to the situation where the users are programmers. And I am a programmer. But I have never and probably never will modify any open-source applications I may be using. Too much work. Some library-code perhaps but not a full application (like VSCode).

Too easy to cause more errors rather than fixing them, creating a dependency to my own modifications. When it becomes time to upgrade to the next version of such OS software I will need to merge my modifications to the official app or library, and there is no guarantee that my modification would be compatible with the latest version of the said software. If it is not compatible that means either more work for me, or that I can't upgrade.

You specific having the time/resources is not the point. The point is that for users with the resources, they have the freedom to do this (either themselves or by hiring someone).

"I don't have the resources to exercise my freedoms" might be a problem for you, but it's not a problem caused by the freedom or the mechanic granting it.

Right, freedoms are great. But my point is such a freedom is not very valuable to anybody else than programmers, or rich people and companies who can afford to hire them.

And even for programmers like me it is not very valuable, especially if we're talking about sw-applications like VSC as opposed to library code.

The nice thing about society is that it allows people to come together and pool their resources, in order to achieve an expensive thing that no individual might be able to reasonably afford.

I get that nice things that you want are sometimes expensive, but that's just life, isn't it? The world doesn't owe you a cheap-and-easy-to-hack-on piece of software.

I don't believe the term "open source" was used much before a certain meeting in 1998 [1] when it was suggested as an alternative to "free software." Some people say it predates that meeting, but I haven't seen clear evidence. Do you have examples where it was used?

On the other hand, people were using licenses that are now called "open source" licenses well before that, so the practice certainly precedes the term. Also, the OSI definitions were derived from the Debian Free Software guidelines.

[1] https://web.archive.org/web/20021001164015/http://www.openso...

Of course the topic of spirit-vs-letter of Open Source is worth discussing. (I've personally meditated quite a lot on "open governance" vs. "open source", which is tangential but related).

But I think your portrayal of FOSS advocates at large as unconcerned about the spirit vs. letter of open source compliance is wildly inaccurate. If anything FOSS communities discuss such topics obsessively. (How many bits have been spilled onto the internet about TiVo-isation?)

Also, see pxc's excellent analysis elsethread for an illustration of the utility of the OSD: https://news.ycombinator.com/item?id=41693457

Thank you for your insight, I really appreciate it!

>If anything FOSS communities discuss such topics obsessively.

I don't see this the same way. Whenever topics like these come up, "quoting the OSI definition word-by-word" is a fairly a common moral argument. (See every Mongo/SSPL or ElasticSearch thread on this site and you'll see)

While there is definitely discussion of this, you are entirely right, there's a substantial proportion of people (I'm not claiming that it's necessarily the majority or anything - but influential enough to derail or block things) who do not take the spirit of the Free Software movement into account at all. At a glance, many arguments against these licenses don't come from a viewpoint that these licenses violate the spirit of Free Software - they just mechanically quote the OSI freedoms without any critical evaluation or moral reasoning.

pxc's analysis is great and morally I definitely agree with it. I don't think that most people agree with it though - which legitimises the VSCode "open-source" approach.

> MS has managed to pacify even the strongest FOSS advocates

I'm not sure that's the case. I think the strongest FOSS advocates gave up on Microsoft decades ago, and just don't engage with anything they put out. If MS release source-available stuff, strong FOSS advocates don't peep because they've not even looked at it. Why bother - it's Microsoft. If someone else does it, well, the FOSS advocates still had some hope that what they didn't wouldn't be terrible, so there's space for those hopes to be dashed.

Yeah, I think this is the problem that this (people) are, expecting another corporate entity to do the same thing is actually hilarious.

hey, we welcome microsoft to countribute to FOSS, but expecting to behave like another is laughable given the alternative

> If you enjoy a rabbithole, look at how much DRM there is in Pylance

So just don't use it? The linked discussion points to Basedpyright https://github.com/detachhead/basedpyright/ as the best free alternative right now (with some additional features around Python optional typechecking that aren't even in Pylance itself).

Does this fix Jupyter too? As far as I know VSCodium Jupyter is broken, unless you use Pylance.

What are the benefits of running Jupyter from VS Code rather than on its own? Isn't Jupyter the sort of thing that can only be made more fragile and complicated by IDE integration?

Sane editing experience to start with. And proper intellisense, etc.

Is this comment meant to apply generally to MS behavior? In my experience, MS faces some of the toughest judgment on anything related to OSS.

Absolutely, this is not just a random tangential comment! With a bit of searching, any time criticism of VSCode comes up, it's shrugged off with "it's OSS!". Even from people who use Linux, a substantial proportion of programmers bring out the OSS card to deflect criticism of these exploitative practices.

(Example here: https://www.reddit.com/r/linuxmasterrace/comments/v3n8w4/wou... but this sentiment is really ubiquitous)

Convenience and comfort are freedom's enemy. What is going wrong with the traditional editors and programming tools that (assumably) younger devs are going for those full-blown IDEs? Has the complexity of development with back/front/ops exploded so much that older editors are lagging behind modern needs?

As OSS old-timer, I gave VS Code a try, but it was too noisy and distracting, slow, and didn't allow enough control over what was being installed and when. To each their own of course, but I didn't see any particular reason why VS Code is much better or deserves to be more popular than other editors, and if any functionality is missing from other editors – especially those that are incorporating tree-sitter – then maybe we can just improve those alternatives?

Talking about modern editors, I like where Zed is headed, but that project also has some non-OSS components or aspirations if I remember right.

The editor is open-source. If you want DRM trap to be open-source, create them yourself. VSCode is a text editor at its core, and you're free to use it as you see fit.

The blog read like the author is crying that Microsoft is not giving away extension for Gitpod to make money

This behaviour has a specific name.

Microsoft is embracing open source, gaining market share with proprietary extensions, and then those to extinguish any truly OSS forks.

Embrace, extend, extinguish. Once again.

That's not how that term ever worked, but go off.

It's a bit of a reach to invoke EEE for a piece of software they wrote in the first place.

Of course it's a post relating to MS so there will be at least one such comment

Back during the early 2000s, when OpenOffice threatened to eat Microsoft's lunch, they created the new .docx/.pptx/.xlsx Office Open XML file formats and got ISO to standardize them as ISO 29500-1.

The standard isn't detailed enough to create your own Office implementation. Not even Microsoft Office implements it correctly. Microsoft only created the standard so they could claim they were as open as OpenOffice, to prevent OpenOffice from becoming the standard, to make sure third parties would continue building upon Microsoft Office, and to ensure third party implementations would always be slightly worse.

As leaked emails later showed, even Microsoft employees used the Embrace Extend Extinguish term to describe this project.

I'm not sure why you think the VSCode situation is so different.

> As leaked emails later showed, even Microsoft employees used the Embrace Extend Extinguish term to describe this project.

Source?

> I'm not sure why you think the VSCode situation is so different.

I'm not sure how they're related? How is something MS allegedly did with Office over 20 years ago related at all?

It's not like they can make plaintext source files incompatible with other IDEs

Microsoft pretended Office was open so third parties would continue building an ecosystem around Office. But no matter how "open" Office was, you had to get MS Office to get the best experience, so no one could really compete.

Microsoft pretends VSCode is open so third parties continue building an ecosystem around VSCode. But no matter how "open" VSCode is, you have to get real VSCode to get the best experience, no one else can really compete.

Do you understand it now? It was never about the files themselves, but always about add-ins, extensions and an entire ecosystem.

>Microsoft pretends VSCode is open so third parties continue building an ecosystem around VSCode.

That's not the case here. Gitpod wants extensions for free to monetize them.

The text editor is free and open-source, and they utilize it for their UI, as shown in the tweet posted in the blog. Someone observed that many tools employ the VSCode UI.

The VSCode Marketplace is Microsoft's proprietary platform for VSCode extensions, separate from the open-source code.

However, anyone can create their own marketplace for open-source VSCode extensions.

The EEE (Embrace, Extend, Extinguish) tactics you described don't apply to VSCode.

EEE typically involves Microsoft embracing a standard and then killing it. there's no standard to embrace. When we have thousands of text editors out there, each with their own extension ecosystems.

The extension interface that matters here is LSP (which Microsoft introduced).

You can't get enough users to actually make building your own LSP for C# worth it.

But you also can't use Microsoft's C# LSP unless you ship unmodified VS Code.

As result, GitHub's codespaces, VS Code and Azure are the only ones that can have a usable C# LSP.

Do you see the issue now?

I'm using vs codium. What most useful things am I missing? I have not found anything missing. Now I'm really curious.

"Remote SSH" and "Dev Containers".

https://code.visualstudio.com/docs/remote/ssh

https://code.visualstudio.com/docs/devcontainers/containers

Remote ssh works on vs-codium. (With a slightly different extension).

I thought the server part of VS Code (to be exact a proprietary Node addon) is the problem?

https://github.com/VSCodium/vscodium/issues/1229#issuecommen...

Stupid me, the solution is one post below :D

https://github.com/VSCodium/vscodium/issues/1229#issuecommen...

Would you mind sharing which extension works for you, to help consider a switch to vs-codium?

I guess that's https://github.com/xaberus/vscode-remote-oss

I'll take a look at it, thank you for the suggestion.

Same, I wonder if the people complaining have experience with vscodium (to know the difference). Everything I want works with vscodium and I never had any problems with it. The only thing I know doesn't work are dev containers, but I never personally wanted to use them.

"most useful things around it are full of DRM and legal traps" is a HUGE overstatement. Vscodium is great and have everything anyone can want (except, maybe, devcontainers)

MS is a bit weird. After realizing that most competent developers had left the MS ecosystem, they went for a Zeitenwende. But they did only for 90%.

I wonder to what extent this halfheartedness should be ascribed to the MS org chart or to reasoning like "we should prevent a competent competitor to run away with our tools".

In the mean time, there is a capable replacement named Theia [0] with none of the strings attached. We as a whole would do best to move to that one. [1]

___

0. https://theia-ide.org/#theiaide

1. That is to say: for vscode kind of experience. Native IDE's are unbeatable imho.

To be honest, Theia (the last beta I tried some months ago) is everything people always complain about Electron apps: slow as molasses - way worse than e.g. Atom (or Pulse) (which VS Code actually isn't).

> The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.

Huh? There's been lots of outrage about this. Repeatedly.

However, the problem is that nobody with any resource is willing to step up and replace the Microsoft closed source plugins. And developers aren't willing to put themselves out to use non-encumbered extensions.

It's basically a big "Put Up or Shut Up" from Microsoft, and nobody is willing to "put up" so we wind up with "shut up".

>The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.

Huh? If anything, MS prevents people from shooting themselves in the foot and illegally installing a piece of software against the license terms.

You can use vscodium for free, it's great, you literally don't have access to a few MS extensions (with open alternatives, which you can support financially if you care).

Yes, PyLance has a pretty strict license and makes it very clear it cannot be used in forks (and that's not really surprising and pretty standard I'd even say for a corporation such as Microsoft, it's like the current licenses saying this is open source but cannot be used by competitors, what's really surprising for me is that forks are choosing to ignore this):

> INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the ThirdPartyNotices file(s) accompanying the software.

One thing I don't understand is how forks (I'm actually talking about Cursor which is one I'm actually evaluatinng) are getting away with scrapping all extensions from the VSCode marketplace... I even e-mailed them but had no official position on that. Maybe they have some separate contract with Microsoft -- they do have OpenAI backing, so, maybe they have some bridge there, does anyone know? Or maybe Microsoft is just waiting to see how they themselves can profit for it and so is taking no legal action at this point?

-- disclaimer: I'm on the author of PyDev and I do have my own Python extension that I publish to VSCode and OpenVSX (https://marketplace.visualstudio.com/items?itemName=fabioz.v...)... it's completely Open Source in Eclipse, but for VSCode it's currently commercial. I discovered that's a nice way to have less people requesting support, even though 99% of it is still Open Source ;)

It's not really DRM. You can make most extensions work on codium by changing a few settings. It's just not officially supported.

I hate the way they don't open source the useful ones like the ssh debugging though

They have integrity checks and obfuscated code. That's not just changing a few settings. See the issue I linked about Pylance, for example...

> It's just not officially supported.

Isn't it worse than that? They're not just unsupported, I thought it was against their EULA to use the MS extensions with anything but the official VSCode.

It doesn't matter to the average person using it for personal projects but it's a liability to businesses. It wouldn't matter most of the time but this is Microsoft we're talking about.

Meh, for me personally I don't care about EULAs, as you say.

And for business, they will use the official VS Code anyway. My own employer is up to their armpits in Satya's ass. Over the last 8 years the MS sales goons have managed to get us to throw out every third party solution they had an option for. We even have to use Edge now.

> And for business, they will use the official VS Code anyway.

Our company only has VSCodium in their repos.

Its close in spirit to DRM: they enforce that if you are using their projects, it is under their legal terms.

Many of their VS Code extensions[0] have license terms which /prohibit/ them from being used in editors that are not Microsoft's VS Code editor, and Microsoft can issue cease-and-desist for violations of this, as well as 'open source forks of VS Code' using their marketplace services.

Microsoft also has a pattern they follow where they publish repositories on GitHub to proclaim they are open source, while actually distributing proprietary binary blobs in them that are fundamental core parts of functionality to the codebase[2][3][4]

[0] https://github.com/microsoft/vscode-cpptools/issues/6388#iss...

[1] https://github.com/microsoft/vscode-cpptools/issues/5784

[2] https://github.com/microsoft/win32metadata/issues/766

[3] https://devlog.hexops.com/2024/building-the-directx-shader-c...

[4] https://github.com/microsoft/Azure-Kinect-Sensor-SDK/issues/...

The Pylance extension literally attacks your computer using a ReDoS attack if you open it in a debugger. [0]

[0]: https://darmstadt.social/@claudi/112866065489514979

> People when a piece of software is source-available but not strictly OSS: outrage

There's no longer outrage, since this has become the norm. Biggest most obvious example: Chrome.

It's really important to realize that some 70% of the OSI's funding comes from proprietary services houses (Amazon, Microsoft, and Google mostly and then like... Comcast and IBM), and so nobody at the OSI legitimately cares about openness. The reason SSPL is not OSI approved is because Amazon pays an entire OSI staff salary a year and the SSPL costs Amazon money.

> The reason SSPL is not OSI approved is because Amazon pays an entire OSI staff salary a year and the SSPL costs Amazon money.

This is slanderous nonsense. SSPL is not OSI-approved because field-of-use restrictions are not compatible with the Open Source Definition, clause 6.

https://opensource.org/osd#fields-of-endeavor

> 6. No Discrimination Against Fields of Endeavor

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Here's the decision:

https://web.archive.org/web/20230411163802/https://lists.ope...

I've read the arguments, but those arguments apply equally to the AGPL, which would not be approved by the OSI today. SSPL has no field of use restrictions, it simply has restrictions that require viral open sourcing.

And there's nothing slanderous about pointing out that, yeah, Amazon pays out a significant portion of the OSI's entire operating budget. (edit: Actually FWIW, Amazon is apparently not currently on the Sponsors page... maybe they didn't renew this year. But they used to be at the top.)

>I've read the arguments, but those arguments apply equally to the AGPL

How? You can use AGPL code to develop nuclear weapons and murder drones, as long as you publish the code.

You can also use SSPL code to develop nuclear weapons and murder drones, as long as you publish the code! Additionally, you can also use SSPL code in a business offering that code as a service... as long as you publish all of the code for that service!

Oh. I've read more about SSPL and I actually like it. I don't see how it's not open source. I guess OSI, Red Hat and Debian know better than me, I'll have to check their reasoning. Though you are right that I don't see how it's fundamentally different from AGPL.

Thanks for correcting me!

>Specifically, this is discriminatory against users of the software that use proprietary software within their stack,

(From wikipedia) That's... the point.

The difference between the AGPL and the SSPL is that while both relate to software which the end user interacts with over a network, the AGPL places no restrictions on what the software is used for, while the SSPL encumbers commercial SAAS.

This is a field of use restriction, and it is indeed the point of the SSPL! But field of use restrictions are disallowed under OSI's Open Source Definition — because it's critically important that Open Source software must be usable for any purpose to avoid uncertainty and exclusion, as explained elsethread [1].

[1] https://news.ycombinator.com/item?id=41691577#41694133

You can't just keep claiming there's a field of use restriction when there isn't. It merely conveys a requirement for open sourcing dependencies required for operating services, an entirely noble copyleft behavior.

Any business which isn't exploiting open source in order to benefit proprietary source won't even be phased by this. It's simply a requirement to open source your stuff, which the OSI would support if supporting open source was actually their mission.

OK, I believe I understand the distinction you're making here.

I had to fight my way through your aspersions about the motivations of the people who take part in OSI license discussions, some of whom I am personally acquainted with. I consider the notion that they are driven by allegiance to Amazon and the like risible, although you don't have to take my word for it (and shouldn't, it's an argument from [negligible] authority).

The idea is that a "field-of-use restriction" should deny a license grant based on field-of-use, as opposed to granting a right to users to obtain source code based on field-of-use. This seems like a technicality when the obvious effect is to cripple commercial competition which some see as illegitimate and advantage certain other parties — something completely at odds with the idea that Open Source software needs to be available for any use, deeply cherished by myself and many other FOSS advocates.

For what it's worth, while I generally support, develop, and use open source software, I think "freedom 0" is somewhat problematic. Beyond the fact that I feel us doing labor to support the common good should not inherently require it be usable for corporate greed (I think a noncommercial license shouldn't be treated as a sin by the open source crowd), I think there's a sort of Paradox of Tolerance issue if you allow proprietary developers to compete directly with open source developers using their own code.

If we aren't able to say "hey, this is for open source use only", companies unburdened by ethics will always have a market advantage over ethical open source companies, and that in the long term will ensure open source doesn't win.

ladies and gentlemen, this is a perfect example of the word-by-word interpretation I was talking about in another subthread:) The SSPL is a perfectly sensible license, the only thing it does wrong is to stop SaaS exploitation of software. As the GP said, the OSI is mostly funded by hyperscalers, it's in their vested interests to keep the status quo.

Field-of-use restrictions are certainly a useful tool in fighting open source exploitation, and the blanket disallowal of them just plays into the hands of Amazon and whatnot, allowing them to massively profit off everyone else's work.

Also, note that the OSI doesn't even follow their own definition by the letter! I quote,

  Section 13 is very obviously intended to be a restriction against the field of endeavor of offering the software as a service, and thus not in compliance with OSD #6. I don't see how you can change this while maintaining the intent of your license, which is indeed to specifically encumber vendors other than MongoDB who engage in that field of endeavor.

So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! The conflict of interest is blatantly obvious here...

> So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field!

Stopping hyperscalers is restricting usage in a field.

The primary reason that field-of-use restrictions are part of the OSD is to avoid excluding anyone from the community, and also to avoid fights about whether anyone belongs. Historically, military uses were often excluded in certain licenses — but just what constituted military use could be very hard to determine and potentially could result in endless litigation. Dual-use technology, anyone?

The same reasoning applies to hyperscaling. If you allow any restrictions on field of use in "Open Source", then a fundamental guarantee that countless users of OSS have been counting on goes up in smoke. Before, it was software that anyone could use for any purpose. But now, everyone has to wonder, "am I actually allowed to use this Open Source Software"?

I firmly agree with these arguments, and I'm glad that the OSI continues to be intellectually and morally consistent in applying them — despite your asserting that they must be corrupt to do so.

Wouldn’t the GPL also violate this clause because you’re not allowed to use a GPL-licensed program for developing proprietary software?

the gcc very clearly states it can be used to create proprietary software. always has.

the same goes for anything LGPL licensed, but I'd be surprised if you count that as GPL ;-)

Reply on news.ycombinator.com