Remote Containers and VSCodium

[rawtaz]

In #967 @kieferrm writes:

• Reminder: You may only use this software with Visual Studio family products,
• as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)

Right. But since when isn't VSCodium a "Visual Studio family product"? It's quite clear that it is, given that it's built off the VS Code source code. The differences are minimal and not relevant in this context. It's clearly a "Visual Studio family product".

So, can you please remove the restriction in this extension such that VSCodium can use it fully? There's no point in not letting users of VSCodium use it the same way that they would if they were running VS Code.

Again, the differences between these two builds of the VS Code source code are minimal and of a completely different nature than what is relevant to this extension - the two builds would use and communicate with the extension in the very same way, hence the differences in the builds aren't practically relevant to this extension at all.

[brianclinkenbeard]

Even whether or not VSCodium would be a “Visual Studio family product” I think the licensing of this product to force users to use the proprietary version of vscode really goes against the spirit of making vscode OSS to begin with. This is similar to how Visual Studio Code is advertised on the website as open source when the builds provided are actually proprietary. It seems that Microsoft wants the to have the advantages both of the software being open source (better PR and image) and proprietary (i.e. not putting the user interest first).

VSCode is one of the best things MS has done in a while, but it seems that if they want to choose open source, they should actually embrace it instead of adding caveats to lock the user in.

[bhack]

Honestly It doesn't make so much sense to use Vscodium and then select proprietary extensions, It Is counterintuitive IMHO.
When this extension was realased there was still a ray of light about having opensoudce code at some point in the timeline and separate MS commercial cloud services.
See #179 (comment).
But I don't know the current status.

[rawtaz]

@bhack Consider the following combinations of what you run:

• VSCode and the proprietary extension: One component you know does telemetry and similar, and one component that might do it.

• VSCodium and the proprietary extension: One component you can verify does not do telemetry and similar, and one component that might do it.

At this point you have set yourself up for a much lesser risk of being tracked, because you have eliminated known telemetry and are now only exposing yourself to potential telemetry.

I believe that the parts of the extension that runs under VSCode does not do telemetry, because I haven't seen any suspicious outgoing calls from it. It could still do some telemetry inside the containers though, I haven't checked that.

Regardless; Personally I need this extension in order to have a working development environment, but the this doesn't mean I want to support telemetry in VSCode, so there's reasons beside the technical ones to run VSCodium instead of VSCode.

[bhack]

I understand but while I think Vscodium is an interesting project I think that It has any sense to make an opensoruce political battle or philosophical strategy on let be able to combins Vscodium with propietary extensions.
IMHO a a more profitable effort would be to try to push Microsoft to sperate extensions source code from subcomponents related to its own commercial cloud services.
I see some margin in the Microsoft original declarations that I've mentioned in #179 (comment)

[bhack]

If you see It Is still in the official FAQ https://code.visualstudio.com/docs/remote/faq#_why-arent-the-remote-development-extensions-or-their-components-open-source

[matkoniecz]

Honestly It doesn't make so much sense to use Vscodium and then select proprietary extensions

My plan was to temporarily install it, do task that required it, uninstall it.

[mpql]

I posted this about the WSL Remote extension, but believe it to also be relevant to all remotes:

#6193 (comment)

Would it not be relevant to fully embracing the open-source movement to thus embrace use of product functionality by those that choose an open-source route? Containerization is very important to the development-deployment process, and this particular extension is the literal connection between VS Code / Codium and WSL in Windows. This goes for all of the remotes, as in #1925.

I understand this requires engineering effort, and by all means, plan it as you would any other medium-priority feature and get it on a roadmap, but unless I'm misunderstanding, pipeline adjustment is not that high of an investment. In fact, I'm sure the open-source community (myself included) would be more than willing to contribute to that engineering effort if we were able to do so.

I don't mean to be pushy, but I have been waiting for remotes for years -- the entire time I've been using VS Codium, and seeing stale tickets on the matter is incredibly dishearting. Please get this on a roadmap if possible!

[KaspianDev]

VScode is a good example of corpos not understanding (on purpouse) FOSS. Microsoft tried to put their product to your neck by banning open source vscode complitaions in codespaces for example.

Pathetic.

[DeepDoge]

is there any alternative to Dev Container extension? that let's you run your workspace in a docker container with its own settings and extensions?

[Always-Self-Hosted]

Are there any workarounds for this restriction? It isn't clear to me if its possible or not for the community to build our own server to support this feature? (this comment is based on my understanding that we hit the issue where the server has strictly hardcoded Microsoft urls and hashes for resources used?) I can see there is open source versions of the remote ssh functionality, and I do not have enough knowledge or experience to know if the same can be done for dev containers?

Clearly VScodium users are a small part of the eco system, but we are still part of it. We clearly like the products Microsoft is building and want to use the features, we just don't agree with closed source or restrictive licenses, neither of which vs code's core has. So what can we do about accessing the dev container feature or convincing Microsoft to align this feature with vs code's core?

[DRKV333]

You could use the open source SSH remote extension, and set up containers with sshd running in them to connect to. Although that's a bit more manual.