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?
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.
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.
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:
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.
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.
> @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.
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).
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.
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:
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.
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.
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.
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 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.
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.