Vscode: Binary redistribution with Chocolatey package

[pascalberger]

While Visual Studio Code source code is available under MIT license, the binary product is not and has its own license which disallows binary redistribution.

I'm maintaining the Visual Studio Code Chocolatey Package which currently downloads the installer from the website and runs it afterwards. This makes the package dependent on having an internet connection though, and also might be an issue in an enterprise environment. While Chocolatey Business Edition supports internalization of packages it would be easier if we were allowed to package and redeploy the Visual Studio Code installer in the package available from the Chocolatey community feed.

Would it be possible to get permission to redeploy the installer directly with the Chocolatey package?

[pascalberger]

@chrisdias Any news on this?

[gep13]

@chrisdias @kieferrm @egamma would any of you be able to provide some input on this question?

Thanks!

[gep13]

@egamma just wanted to follow up with this request again. Could you provide some input? Thanks.

[egamma]

@gep13 our goal is that all binary distributions of VS Code have the same quality and are smoke tested and sanity checked by team. Therefore we are careful in singing up for additional distros since this will increase our test matrix size.

@gep13 @pascalberger we haven't seen many requests for a chocololatey distribution since this issue got reported, therefore can you motivate, why you are suggesting this additional distribution channel?

[gep13]

@egamma said...
our goal is that all binary distributions of VS Code have the same quality and are smoke tested and sanity checked by team. Therefore we are careful in singing up for additional distros since this will increase our test matrix size.

A Chocolatey Package is simply a wrapper around the published, quality and smoke tested, distribution. At the minute, the VSCode Chocolatey Package simply downloads the exe from the published URL during installation:

You can see more here:

https://chocolatey.org/packages/VisualStudioCode#files

The request here that @pascalberger was making was to allow the Chocolatey Package to be more resilient, by containing the actual installation file, rather than downloading it. During the creation of the Chocolatey Package, the same download file, from the above URL would still be used, so I don't think this would add anything to your testing matrix. At the minute, we the Chocolatey Community, can't embed the installer, since the license does not permit it.

To date, there have been 116,385 downloads of the VSCode Chocolatey Package, so I would say that it is a reasonably popular package. It is certainly the way that I install VSCode onto any machine that I am using.

Please let me know if you have any questions. Would be happy to Skype/Call, if you wanted to talk further.

[pascalberger]

@egamma Please note that the number of downloads @gep13 has mentioned only contains downloads of the package from the chocolatey.org server. In enterprise environments it's common to use an internal server which caches the packages and the actual number of installations of Visual Studio Code through Chocolatey is therefore propably much higher.

[majkinetor]

@egamma, can we get some answer to this ? Even negative one.

The reason for additional channel of distribution is because package that contains the binary can be cached in the company. This is typically done with tools like Nexus, Artifactory etc. This means that local developers have speed and stability and local security as it can be subject to local storage anti-x protections. You also keep protecting version that you developed with which may be important on given project (technical docs may depend on version of development tools and usually do). It is IMO way easier to just use the cinst visualstudiocode --version x.y.z then lurking around for historic downloads. This can help testers compare versions easily.

Besides that, Chocolatey community gallery itself provides additional protection with integration with VirusTotal.

As stated, this is chocolatey automatic package which grabs the official Github release few hours after it is published by vscode team.

[egamma]

@majkinetor I'll look into this and will update the issue.

[simoniz0r]

I would be interested to know the outcome of this also. I would like to build an AppImage for VSCode, but I noticed that the binary license is far more restrictive than the license for the source...

[kirtangajjar]

@egamma Any updates on this?

[seanmcbreen]

Hi all,

Stepping in here to help. With what is likely not great news.

Today (and we will keep reevaluating this) we would like to only distribute the binary for VS Code via our own web-endpoints. So any package management should call those endpoints and request the latest version.

We want to do this to preserve maximum flexibility in shipping schedules [which helps us preserve our velocity] and help everyone keep on the latest, latest. Any indirection (via distributing the package in another way) is something for the time being we would like to avoid.

As I say we can and will continue to evaluate this but for now distribution should be managed via those endpoints and the Linux packages we publish.

I'll close this issue for now - but we can re-open if there is more to discuss immediately. Just let me know.

Sean
VS Code Team Member

[gep13]

@seanmcbreen thank you for getting back to us, even though the answer isn't the one that we had hoped for.

I do just want to point a couple of things though, just in case they had been missed...

The Chocolatey Package for VSCode is currently maintained on the Chocolatey Core Team Packages Repository. This is a fully automated system, that checks the web endpoints for all the packages that are maintained by it every 6 hours. As a result, a new Chocolatey package version for VScode would be available within at most 6 hours after it was shipped and published to the website. So in terms of affecting your shipping schedules, and ensuring that everyone has the latest, latest, version, I don't see how this cause an impact.

For example, if you have a look at the release dates for VSCode:

https://github.com/Microsoft/vscode/releases

And compare them to when the corresponding Chocolatey Package was made available:

https://chocolatey.org/packages/VisualStudioCode

You will see that they very closely align. NOTE: I am going to assume that the differences are due to things like there being a slight delay between the release being created on GitHub and the download actually appearing on the website.

Another suggestion, if you and the team would be interested, would be for the VSCode team to take ownership of the Chocolatey Package and you guys push the new package versions to Chocolatey.org as part of your build/release pipeline. That way, there would definitely be no change in your velocity, and the new package version would be immediately available.

I just wanted to put these thoughts here in case they could add to your on-going discussions. And I also wanted to add that 347,734 package installations from Chocolatey is not a small number of people who are actually making use of the package that is currently being made available.

[kirtangajjar]

@egamma @seanmcbreen - Is there a reason why you disallow binary redistribution in your license? How about allowing unmodified binary distribution? Perhaps that will solve @pascalberger's Issue.

[seanmcbreen]

@kirtangajjar great question - it really comes down to wanting to have some degree of control over the experience of distribution. Our primary concern is to ensure that all users get the most up-to-date bits, bits that are auto updating and that we can adequately monitor how well that experience works (e.g. failures in downloads, network performance, ...). We also know our users are most successful when they discover our website and the related docs.

To date we have been lucky enough to be able to encourage people to simply point to our endpoints (both within MSFT and outside of is).

Distribution in abstract is actually not something we are against and I can see how it can actually be a win-win-win for the distributor-our joint customer-and us. so I'm sure we will continue discussing this.

[seanmcbreen]

@gep13 this is helpful context and I need to digest it a little. I agree the install count is not a small number. We actually love the fact the package exists and are very impressed at the speed of updates.

So thank you for the extra content, the key concern for now is the offline distribution [and packaging of the distro] that's the only part giving me pause.

Sorry, not much of substance in this response but I did want you to know I reviewed your response and we will keep thinking about it. But for now our preference is to continue with the existing model.

[gep13]

@seanmcbreen said...
So thank you for the extra content, the key concern for now is the offline distribution [and packaging of the distro] that's the only part giving me pause.

Please let me know if you wanted more information. I would be happy to jump on a Skype call, or similar, at some point to discuss any further points that you wanted clarification on.