Hacker News Reader

Comment by Dinux | Hacker News Reader

I don't see the beneficial element to this project. Visual Studio Code is opensource, free of charge and used by millions at this point, why would anyone want another license just because of the license alone?

View on HN

The source license and binary distribution license are different. The source code is MIT licensed; nothing wrong with that. Great license for this. The binaries are provided with a different license that also covers components from third parties that may not be in the vs code repo as well as telemetry and other data gathered.

If for whatever reason you don't like this license, you can build from source. This project seems to do that and remove all of the MS branding and telemetry. There are only a handful of commits on the project so it does not look like it is massive change. The big question is whether that adds enough value and whether this project will make enough effort to keep it's fork up to date.

I agree that for the vast majority of users, using the official binaries should be perfectly fine. MS did a fine job with this product. But nothing wrong with having the choice.

Looking around, this repo is just a few ~10 line shell scripts. Very simple, and it isn't a fork of vscode. It clones the Microsoft repo directly and builds it from that.

How different is this from Chromium and Chrome?

For use in FLOSS distributions like Ubunutu or Debian. Like how Firefox got rebranded as [Iceweasel/Icecat](https://en.wikipedia.org/wiki/GNU_IceCat) so their logo/branding didn't have to be distributed by FLOSS distributions.

Actually I think this would be rather useful to have.

I don't use VS personally, but if I understand correctly their binaries are not free even though users can build their own from a free source code. If this "VSCodium" simplifies the building process, and also removes some anti-features in the process such as telemetry, I think it has value.

? VSCode is definitely free in the "beer" sense.

Sorry, I mean "free software" I wasn't talking about price.

Ah gotcha! Apologies, then. I probably should've read a little more closely.

For me, it's more about telemetry than licensing.

AFAIK telemetry can be disabled with "telemetry.enableTelemetry": false

isn't it agains't GDPR having it be like that?

wouldn't downloading and agreeing to the eula suffice for purposes of this?

No. GDPR requires that users must be able to use the service after opting out of data collection (except if the data collection is required for rendering the service to the user). A EULA, in contrast, must be accepted, otherwise the service may not be used.

An opt-in is required under GDPR for personally identifiable information, not "any data ever".

Anonymous/aggregated data collection is allowed under the GDPR, though this data collection should still be made clear to the user (and it is on https://code.visualstudio.com/docs/supporting/FAQ#_gdpr-and-...).

Doesn't it suffice to set the following in your User Settings?

    "telemetry.enableTelemetry": false

Honestly I'm very happy to give telemetry data. Microsoft is doing so much to improve the experience, they can make it better with some data.

This doesn't suffice unfortunately. That setting has worked inconsistently, or not at all, and add far as I've seen in my own testing it never disables all telemetry. There have been issues open on GitHub about this for a long time, though it's a few months since I checked there for updates (I stopped bothering and just put it in my firewall rules; I still see blocked connections in thy log today).

I'm a very happy vscode user, but this is one antifeature does continue to bother me.

It really is annoying that they don't make it opt-in instead. They've got plenty of users; I can't imagine they need to be collecting usage statistics from everyone.

I'm curious what would happen if a moderate-size country (say, Belgium) were to pass a law saying that telemetry must be opt-in. I bet it would convince everyone to just be universal opt-in for simplicity's sake.

That said, I bet it's still nothing compared to the level of data collection that a typical website does these days.

> @bunderbunder I bet it's still nothing compared to the level of data collection that a typical website does these days.

I'd say the opposite. Consider that (a) you typically visit websites briefly and periodically while most vscode users have it open as long as their computer is on, and (b) Electron provides access to lot more device data than the browser sandbox. The reason websites tend to have such far-reaching and devious user-tracking methods is because they're working in such a restricted environment and have to innovate; native desktop apps have far less restrictions.

Another big difference, though, is that VSCode's telemetry is publicly documented.

So, regardless of what they're able to collect, I know what they are collecting, and how personally identifiable it is, and I know that it's pretty tame compared to what I've seen elsewhere.

Ah, that is a fair point. I hadn't looked at what they collect, I was just speculating about what they could collect if desired.

Are you sure the additional telemetry isn’t from extensions? Our extensions (Salesforce) have our own telemetry setting, but we do also respect the global VSCode setting due to this exact possibility of confusion. However, I know that there are other extensions that dont respect the global setting.

I tested without extensions back when I was following the open GH issues, so that wasn't the case then.

It could be that MS fixed the issue since, and the connections I see in logs now are from extensions, but I also presume this isn't the case as my firewall rules are IP-based rather than purely app based (since the latter would kill the market browsing functionality).

Can you share the firewall rules/domains to block to disable telemetry for VSCode?

There's a lot of traffic that comes from VSCode, so it's sometimes hard to tell which is which—e.g. the autoupdate checker, and the "Code Helper" queries to schemastore to get JSON validation configs for the JSON files in your project, and the NPM queries for package.json

I block most of it anyway, with a couple of individual exceptions, but other than those examples mentioned above, there's also:

- dc.services.visualstudio.com (40.114.241.141, 52.169.64.244)

- vortex.data.microsoft.com (40.77.226.250, 65.55.44.109, 51.141.13.164, 51.140.40.236)

- bingsettingssearch.trafficmanager.net (13.95.93.152)

I actually have no clue what the last one there is (Bing)—I must have known at some point, but have long forgotten.

Notable exceptions allowed: marketplace.visualstudio.com (13.107.6.175, 191.238.172.191, 13.85.19.92)

> I actually have no clue what the last one there is (Bing)

workbench.settings.enableNaturalLanguageSearch

There used to be at least one issue about this, and of course it has been fixed by now: https://github.com/Microsoft/vscode/issues/16131

If you want to send as little data as possible to Microsoft there are other settings to consider:

        "telemetry.enableCrashReporter": false,
        "code-runner.enableAppInsights": false,
        "update.channel": "none",
        "extensions.autoUpdate": false,
        "extensions.ignoreRecommendations": true,
        "workbench.settings.enableNaturalLanguageSearch": false

What stops Microsoft from adding new settings tomorrow?

Or from re-enabling disabled settings with an update, like they've done with Windows 10.

They are different products, different teams, different target markets - I've been using VSCode since it was first released, and they haven't done any anything scummy in that time, or given me any reason to distrust them or their motives. All they've done is provide a great product that I love.

The VSCode team is responsive on GitHub, and are driving development based on the feedback and telemetry they receive. I really am a staunch privacy advocate, but I'm not dogmatic about it - telemetry has it's place.

It can also easily be disabled if you don't want to send it.

Honestly, I don't see the point of this 'fork'.

>> ... Honestly, I don't see the point of this 'fork'.

"Those who cannot remember the past are condemned to repeat it." -- George Santayana

https://bigthink.com/the-proverbial-skeptic/those-who-do-not...

I'm actually old enough to remember Microsoft's past. But I'm not so old I'm cynical enough to think ill of their ongoing OSS efforts.

Your list is incomplete. From the most recent VSCode changelog @ https://code.visualstudio.com/updates/v1_26#_offline-mode:

Offline mode

Some users do not want any outgoing network requests from VS Code unless they specifically invoke features that require online access. To support this offline mode, we have added new settings to turn off features such as automatic extension update checking, querying settings for A/B experiments, and fetching of online data for auto-completions.

Below is the complete list of settings to control VS Code features that make network requests:

  update.channel
  update.showReleaseNotes
  extensions.autoupdate
  extensions.autocheckUpdates
  extensions.showRecommendationsOnlyOnDemand
  workbench.settings.enableNaturalLanguageSearch
  workbench.enableExperiments
  telemetry.enableTelemetry
  telemetry.enableCrashReporter
  git.autofetch
  npm.fetchOnlinePackageInfo

Telemetry should not be on by default without express user consent.

It is only without express user consent for those who enter into contracts without reading them. Assuming you aren't one of those people then you consented.

What do you mean? Just to see what you were talking about, I downloaded VSCode from their official website, installed and started it. At no point was I (to their credit) presented with a "contract".

OTOH, there was (again, to their credit), a notification when I started the software about how to disable telemetry.

If there's people that use Chromium binary builds, there's people that will use this.

Makes sense for inclusion in package repositories.

The VSCode binary release is not open source and not redistributable but rather "source available", and "free of charge" doesn't confer "freedom to tinker". VSCode does have costs associated with it's use, specifically its users' privacy, which they give up by agreeing to Microsoft's data collection terms. You may not value your freedom to tinker or your right to privacy, but the people who run and use this project do.

You can replace “VSCode” with “Chrome” and “Microsoft” with “Google” in your comment.

I guess that’s why this project is called VSCodium.

F the EULA license. That's what VS Code is licensed under when you download from their site, _not_ the MIT license. That's the heart of why this is excellent.

Exactly. I like the idea of having VSCodium as an option but I don’t have an urging need to use this fork since just removing a license and telemetry endpoints doesn’t really add any value compared to the official package.

It doesn't look like a fork to me. It only seems to be a build script for building VS (and possibly remove some anti-features).

Removing telemetry adds a lot of value. To each its own, I guess.

It would add value if VSCode didn't allow you to disable it and didn't document what data was sent - but it is documented, and it's trivial to disable it if you choose to do so. I don't see the point of this.

Reply on news.ycombinator.com