Publish to OpenVSX

[ItsDrike]

Arch Linux (Linux based operating system distribution) has decided to switch the marketplace for extensions from the MS Visual Studio Marketplace to OpenVSX in this commit.

Here are some more details about OpenVSX, its goal, and why it was created

For that reason, I can't use your extension anymore, could you publish on OpenVSX too?
(It's typically just a matter of running npx ovsx publish you can also check the full guide for publishing)

[Colengms]

Hi @ItsDrike . Thanks for letting us know. We'll look into this.

[sean-mcmanus]

The OpenVSX is for VS Code "compatible" editors, but our extensions has a license that limits it to run only in VS Code and not other "VS Code compatible" editors. So I think this issue is a Won't Fix unless we decide to change our license terms.

[ItsDrike]

The OpenVSX is for VS Code "compatible" editors, but our extensions has a license that limits it to run only in VS Code and not other "VS Code compatible" editors. So I think this issue is a Won't Fix unless we decide to change our license terms.

Oh, that's a shame since for Arch Linux and all other linux distributions based on it, the "original" VS Code editor is the code repository in pacman, and that is now using OpenVSX, rather than the original MS Marketplace. The reasoning behind it was to support open source more since there are some parts about VS Code editor which aren't fully open and I assume using OpenVSX in the original editor will mean more extensions will publish there too. Therefore giving chances to smaller, usually fully open editors, based on the open-sourced parts of VS Code

But I respect your decision and I get that the license you use doesn't allow this. I'm sure there were a lot of people with arch based systems who also lost access to your extension because of this change so it might be worth considering the license change, but I will understand if you won't do that.

[bobbrow]

We need to follow up with the VS Code team about this.

[sean-mcmanus]

@bobbrow FYI, there's another related thread at EclipseFdn/publish-extensions#86 in regards to Platform.IO which has a dependency on our C/C++ extension.

[ivankravets]

Wooow! 👀 It is something new for the PlatformIO which we didn't know... It looks like we are locked and our customers as well.

If Microsoft prefers to lock others just to VSCode, we will stop using this extension. Indeed, we use only 5% of the functionality (just code completion) and the rest of PlatformIO tools and services are fully independent of VSCode and are our native implementation including debugging.

@robotdad, could you provide more details? We have a related issue platformio/platformio-vscode-ide#1802 and we can't resolve it.

P.S: I still believe it was a "typo" on the Microsoft management level and they will fix it.

[CrossR]

It may be possible to do something like the MS C# plugin.

tl;dr someone forked the repo and released an extension without the proprietary parts https://github.com/muhammadsammy/free-omnisharp-vscode, such that it could be published on OpenVSX.

Of course, for that to happen the license here would need to be clarified as to what is MIT licensed and what is not, to ensure any forked ext fits with the license.

I believe generally as more "VSCode compatible" editors come out, there will need to be a clearer response from MS about limits and usage, as there is open issues about this for VSCodium and more, as well as LSP consumers who want to use the C++/C#/Python extensions etc in non code editors like Vim, Emacs, Sublime etc.

(I say this from a very biased position of someone who works on a VSCode compatible editor and gets regular questions about those plugins and the Docker/WSL/SSH ones, as it is unclear inside the editor where the OSS stuff ends and closed source proprietary stuff begins).

[robotdad]

I'm unfamiliar with the issues here around the license. I'll do some research and report back.

[sean-mcmanus]

I believe the primary reason for the license restriction was due to the cppvsdbg debugger on Windows/cl.exe, which isn't applicable to Linux anyway (see https://github.com/microsoft/vscode-cpptools/blob/master/RuntimeLicenses/vsdbg-LICENSE.txt ). We were considering loosening the license restriction for Linux ARM/ARM64, but then VS Code published a release for ARM/ARM64 so then we didn't see a reason to continue pursing that...it's possible we could reconsider -- see the thread at #5980 .

The cpptools/cpptool-srv binaries are not MIT licensed, see https://github.com/microsoft/vscode-cpptools/blob/master/RuntimeLicenses/cpptools-LICENSE.txt and https://github.com/microsoft/vscode-cpptools/blob/master/RuntimeLicenses/cpptools-srv-LICENSE.txt (the same license is placed next to the binaries).

One potential issue with opening up our extension to other non-VS Code distros is that there could be additional compatibility issues to deal with. One example is #6090 .

[ivankravets]

@sean-mcmanus thanks for the explanation! I see that @bobbrow already told the legal team (#5980 (comment)):

Is it possible to split this extension into 2 parts: debugging (where we have a license issue) and the rest?

[bobbrow]

Wooow! 👀 It is something new for the PlatformIO which we didn't know... It looks like we are locked and our customers as well.

If Microsoft prefers to lock others just to VSCode, we will stop using this extension.

@ivankravets, For what it's worth, this is not a policy change. It has always been this way. We have been very clear that we don't support forks of VS Code like VS Codium, headmelted, etc because we are not licensed to run with those editors. The surprise for us (cpptools) was that Arch had its own fork of VS Code and was previously violating VS Code's license by linking directly to the Microsoft Marketplace for extensions. They had to switch to a new repository to comply and unfortunately that means they lost a lot of extension support.

We're looking into it, but unfortunately I can't promise that we'll be able to change the license.

[ivankravets]

@bobbrow Thanks for the details!

The surprise for us (cpptools) was that Arch had its own fork of VS Code

From a business point of view, Microsoft did everything correctly. Nevertheless, VSCode is still a community project and would be good if Microsoft respects it. Over 1,000 contributors...

The community needs a neutral and independent registry for the VSX packages and Open VSX is a good candidate.

It has always been this way.

Is it possible to remove the MIT license and explain in README that this is a mixed license project? The companies that build their own IDE solution based on VSCode/VSCodium/Thea/Onivim will not be affected.

Thanks!

[bobbrow]

We agree that a clarification would help and are working with our legal team on that as well. This is tracked by #5784

[sean-mcmanus]

@bobbrow There is no legal team follow up pending in regards to #5784 (I was going to close that eventually). We follow the same licensing pattern as https://github.com/OmniSharp/omnisharp-vscode, e.g. it has a MIT license on the GitHub repo, but a RuntimeLicenses folder that applies to the downloaded binaries and the binaries themselves include the restrictive license (as well as at the root with the published vsix's). Did we want to re-start a conversation to in regards to a "clarified" license or some better way to explain the dual license issue?

[bobbrow]

We should put something in the root readme.md then so that it shows up on the first page.

[KaungZawHtet]

Any progress on this issue ? I mean not about openVSX but about bug in your "MIT license" declaration. License issue should be fixed urgently.

[sean-mcmanus]

@KaungZawHtet What did you have in mind in regard to license changes? The open source code on GitHub is covered by the MIT license, but the published vsix has the more restrictive license as do the closed source binaries that are downloaded, see https://github.com/microsoft/vscode-cpptools/tree/master/RuntimeLicenses .

Many people are on vacations now, so progress on this probably won't occur till January.

[github-actions]

This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.

[github-actions]

This feature request has received enough votes to be added to our backlog.

[caio-vinicius]

Up for this.

[mfouesneau]

May I ping on what's the status of this issue?

[sean-mcmanus]

@bobbrow ?

[bobbrow]

I didn't realize this issue was still open. Nothing has changed from a licensing perspective.