Relaxation of redistribution clause in Microsoft License

[ThadHouse]

It's been about a year since this issue was last discussed (#17283), and I would like to bring it up again. In today's software world, the no redistribution clause is becoming more and more restrictive as time goes on. In addition, we are supporting a group of high school robotics teams using VS Code for their programming this year, and we're trying to make a 100% offline setup for our users. Over the past year, with OpenJDK 11 becoming full featured, VS Code is now the only part of our product we can not distribute. This makes usability more difficult, as we cannot have a self contained setup. Using the open source builds is not an option for us, as access to the extension gallery is very important to our users, in addition to wanting our users not using custom tools. It makes support easier for everyone to use official distributions.

I would have brought this back up in the above posted issue, however that issue is closed and locked, but the end of the discussion in there said there was a possibility of re-discussing this issue in the future.
Offline scenarios are a very useful thing in a lot of ways, and even though a lot of software is making these scenarios harder and harder, this is something me and my users depend on all the time, as we're often at places with no internet connection.

[ThadHouse]

Is there any chance this can be looked at again, or maybe somebody I could talk to about this offline? I can show examples of what we are doing, and the reasons for doing them. This was the most complicated part of our setup, and it would be really awesome if something could be worked out with this.

[Friday32]

This is also a problem for my company. We'd like to redistribute VSCode on products that do not have online access. We'd also be interested in speaking directly with someone to work out an arrangement.

[ThadHouse]

Any update to this? This one thing is still by far the most painful thing in our setup to deal with. I would greatly enjoy the opportunity to discuss this further with someone.

[chrisdias]

Hi - can you explain your scenario more please?

[ThadHouse]

I work with the FIRST Robotics Competition, a High School Robotics Competition with about 3500 teams building and programming 120 lb robots to solve a game challenge. About 2700 teams program their robots in either C++ or Java using libraries provided by my team. We provide the entire setup, from the libraries, to the compilers, to the IDE, to the documentation. For our IDE in 2019, we switched over to VS Code hooking in with a Gradle based build system in order to make the installation and usage an easier process for our users. A majority of our teams are small High School based teams, many without mentors to help them with the process. Because of this, for most teams the documentation and setup we provide needs to be both comprehensive and extremely easy to use.

With our changes for the 2019 season, we were actually able to move the installation of all utilities, including a JDK, our C++ compilers, our tools, and the VS Code plugins we use all into a single easy to use installer. This was a great boon to teams, as our process before was very complicated, and the feedback was extremely positive. However, the only piece we were not able to include was VS Code, because of the restrictive licensing. Many of our users download our installer just once in order to install on a number of machines, many of which don't have internet access. In addition, our competitions also rarely have internet access. Our solution for the 2019 season was to include an extra button in our installer that would manually download the VS Code portable zip for the user, which would then be installed by the installer.

If we were able to distribute VS Code as part of our installer, it would truly become a 1 file setup for our users, which would be a huge usability improvement. We can't distribute open source VS Code, because the C++ extension does not allow usage with the open source VS Code, and also we want the users to be using actual VS Code for troubleshooting, and to be able to install more extensions if they wish.

One thing that is critical to us and our users is to have a fixed version of the utilities from January to April, which is the competition season. We have been burned before by automatic updates, including some in VS Code during development. Being able to install a portable independent copy of VS Code is very useful to our users, as breakage during the middle of the season is a very hard thing for many of our teams to handle.

You can see our current process here.
https://docs.wpilib.org/en/latest/docs/getting-started/getting-started-frc-control-system/wpilib-setup.html

And more about what we do here.
https://www.firstinspires.org/robotics/frc

[Friday32]

I have a similar scenario where we deploy multiple software applications with a single installer. This is how we've packaged our solution for many years. The software is installed on a Windows 10 embedded product that we manufacture.

Customers are able to write C libraries for our product to extend its capabilities. We developed a simple editor that used Visual Studio's compiler to build these libraries. We once supplied a copy of Visual Studio, through a deal with Microsoft, with our software. Visual Studio Pro prices went up substantially, so we made it an optional item . But, it was much too expensive for our purpose, So, we replaced the compiler with gcc. VS Code and our extension replaces the old editor.

I have the exact same redistribution problem that ThadHouse has with the C++ extension. We would like to redistribute the ms-vscode.cpptools extension.

No one is happy with the idea of making our customers download VS Code and the C++ extension separately. Some customers cannot connect to the internet. They would need to download copies to a thumb drive and install it from that.

Other problems include documentation and stability. VS Code and its associated pages update monthly. Some of these updates broke my extension during development. Having our customers download VS Code instead of providing a copy ties us to its release schedule, not ours. ( Yes, you can download specific versions, but it's not easy to describe where to find old copies.) We should continuously test our extension and verify our documentation against the current release. If something breaks, then we would need to test fixes against old versions; We won't know which version a customer has. We have very limited engineering and audit resources, and our product is updated much less frequently than VS Code.

[ThadHouse]

@chrisdias Is there any update to this? It seems like every time we get some communication from Microsoft asking for use cases, we give them and we're just talking to a wall. No responses, no communication. At least some communication would be nice.

[ThadHouse]

With the removal of vscode-update.azurewebsites.net breaking ALL of our old installers, I'd like to bump this issue again. This regressive license just caused a massive pain and massive break to us. All of which could be avoided by getting with the times and allowing redistribution of the binaries.

[lorne-maxim]

@ThadHouse, it seems the source code itself is released under the MIT license. Is building it from source and distributing your own version a possibility?

[ThadHouse]

No, it is not, because we use the C++ extension, which does not work in open source builds.

[lorne-maxim]

That's a bummer. (I just realized you mentioned the C++ restriction in an earlier message. Sorry about that.)

[ThadHouse]

Yeah. @chrisdias Any update to this?

[Kamori]

I also would like to express interest in this. I have 2 use cases.

1. For my organization. I'd like to setup, and enable teams to setup, a custom vscode configuration for new members of their team. Currently we provide guidance on how to setup an environment via a doc. But, if we have anyone not familiar with vscode, they won't get the benefits of this configuration (eg: auto-styling on save) until AFTER they running through the recommended config. Which might not happen before their first commit. Not to mention the ease of use of being able to redistribute onto fresh devices to people who might have only intermittent connectivity, or bandwidth restraints.

2. Education. Unlike the Author, I'm not a formal educator in any way. However, I hop in discord with friends who have expressed interest in coding. Its so much easier when I can provide them a ready to use environment so we can focus on coding first. And then environment configuration can come a bit later.

Thanks for such a great product!

[ThadHouse]

Since its been a year, I figured I should ping this again. @chrisdias Any updates, or anyone else willing to take time to discuss this issue? It looks like the license was changed at some point in the past to explicitly remove the word redistribution, so is redistribution allowed now?

[chrisdias]

Thanks for the ping, sorry that I have not responded. Please also note, I am not a lawyer :).

I think there are three scenarios in this thread:

1. internal to your company/entity distributions

Internal distributions are permitted under section 1.a. INSTALLATION AND USE RIGHTS which states General. You may use any number of copies of the software to develop and test your applications, **including deployment within your internal corporate network**.

2. External/public facing distributions

External distributions are prohibited under section 5. SCOPE OF LICENSE which states you may not share, publish, rent or lease the software, or provide the software as a stand-alone offering for others to use.

This is a standard clause on Microsoft licenses, and it basically prevents others from repackaging our products and creating confusion for customers.

Further, and as pointed out in the original issue #17283, we want to control the distribution end points and experiences for VS Code. The most important reason is for security updates. We need to make sure that if we have a critical fix that we can push it to all distribution endpoints immediately. Since VS Code "ships as a service", the only way to get the fix is to roll forward to the latest release, we don't patch earlier versions. So, locking down to a release can leave customers (for example, your students) at risk of a potentially significant vulnerability.

We don't have plans to change this restriction and continue to recommend how you are currently offering the download from your installer. As a reminder, our download locations for VS Code indicate that the user accepts the license and privacy statement by using the software, so I would ask that where you are surfacing links to the download directly, you also include a sentence along those lines: of By downloading Visual Studio Code you accept the license terms found [here](https://code.visualstudio.com/license). Note, the download endpoint is not a public API, which is why it can change on you. The safest way to go is to send them to the download page itself, that is stable.

3. Consistent, pre-configured development environments

For this, we recommend using development containers. There is a ton of information on that page, but in a nutshell this lets you define a fully custom development environment that VS Code can connect to and run inside of. You define the operating system, system components, runtimes, frameworks, tools, extensions for VS Code, etc. in a Dockerfile. Include the Dockerfile (and optionally Docker Compose file for multiple containers or a .devcontainer.json file for tweaking the container) in the repo and everyone who opens that repository will have the exact same environment. And if you are using GitHub Codespaces, you will get the same development environment there through both the desktop and web.

Probably not the answer you want, but I hope the reasoning makes sense.

Chris

[ThadHouse]

The answers and reasoning make sense, I was just hoping they'd be different, especially with much of microsoft open source having much less restrictive licensing. Realistically, this would be less of a problem if most microsoft extensions didn't nuke themselves when used with open source VS Code, and the extension marketplace worked with open source VS Code. But I do understand the decisions, and we'll just keep doing things how we're doing them.

The only pain point I really have is this one.

" Note, the download endpoint is not a public API, which is why it can change on you. The safest way to go is to send them to the download page itself, that is stable."

I do think that should be reconsidered. Sometimes, stability is important. I usually test each update, and we had a year where a patch update completely broke our extension. So had we been using VS Code as a service, every team would have broke. This is why we explicitly disable automatic updates, and download old and tested versions. It would be nice if the individual download endpoint was considered public, or at least a large message in the changelog if it was changing. The last change was extremely painful, because it was never notified that there was a new endpoint, and everything just suddenly broke.