In any case it would be very good to add a license to this repository (the GitHub way, which will also set the project attribute, which currently has unknown license and points to the license file).
Then "something" is strange: https://github.com/microsoft/vscode-cpptools/blob/master/LICENSE.txt says "MIT" while https://marketplace.visualstudio.com/items/ms-vscode.cpptools/license says different - so is this the same with the .vsix as it is with he VSCode binaries - I can build it from the repo and then share the .vsix, but I may not share the .vsix that is distributed via the marketplace?
Sure, I'll see if renaming the License fixes the GitHub license issue: https://github.com/microsoft/vscode-cpptools/pull/5786
See the discussion at https://github.com/microsoft/vscode-cpptools/issues/2274 . In summary, the MIT license applies to the source code checked into the GitHub repository. The vsix includes/bundles other components/binaries not published in this GitHub repo that has a different "end-user" license: https://github.com/microsoft/vscode-cpptools/blob/master/Extension/LICENSE.txt .
I don't know what you mean by "share the .vsix" or what condition in the license you believe prohibits "sharing". The .vsix in the marketplace has the same license as the offline vsix's published at https://github.com/microsoft/vscode-cpptools/releases .
For the license issue: what seem to always help is to just delete the license file and then re-add it with the "assistant" as outlined in the GH documentation.
I don't know what you mean by "share the .vsix" or what condition in the license you believe prohibits "sharing"
Quoting from the extension license that you've referenced:
You may not share, publish, rent, or lease the software, or provide the software as a stand-alone hosted solution for others to use.
Share the vsix = share the software, isn't it?
Furthermore:
You may only use the C/C++ Extension for Visual Studio Code with Visual Studio Code, Visual Studio or Xamarin Studio software to help you develop and test your applications.
So I may not use it in Eclipse Theia or a self-compiled version of the "vscode" repo, may I?
But it seems that I may create a vsix from this repo on my own and use that in Theia... Do you have any dependency and build documentation?
The intent of the license(s) is that our binaries are only to be used by the Visual Studio family of products, while the TypeScript code is free to copy/use (MIT). Which means that no, you may not use the binaries or the VSIX in Eclipse Theia or any other IDE.
I think your point has been taken. We should work with our legal team to update the license to make this more clear. Thank you for opening this issue.
Yeah, what Bob said. Also, our debugger component outputs the restrictive license clause in the output window when it runs and also disables itself when invoked from non-VS Code hosts such as vscodium (see https://github.com/VSCodium/vscodium/blob/master/DOCS.md#proprietary-debugging-tools ), so it's possible cpptools/cpptools-srv could do something similar in the future.
Hmm, are that debugger and the cpptools-srv in an external repo and just used from this extension?
If not I could just drop the restriction from the code and publish a cpptools-free.vsix with a working debugger and cpptools server - or did I misunderstood something?
I suppose you could try to replicate the debugger and cpptools server functionality on your own, but it seems like you would have more success starting from scratch (or another project like clangd) than starting with our TypeScript code and trying to implement all of our protocol messages.
@bobbrow Thank you for the explanation. I'd really prefer if there would be a documentation entry about the licensing explained above and the external dependencies that are necessary to actually have a working extension (and those having a different license). Could you try to get something written in https://code.visualstudio.com/docs/cpp/faq-cpp about this?
Where exactly do you think the legal team could improve the current state, was that about https://marketplace.visualstudio.com/items/ms-vscode.cpptools/license?
In the meanwhile I'm keen to see if https://github.com/microsoft/vscode-cpptools/pull/5787 will fix the repo's license metadata.
I think that the legal team could improve the license at the root and separate it into sections that cover or redirect to the subareas in the source tree. Placing a simple license at the root is not likely to provide the clarity that has been requested.
I don't think we'll be adding much documentation about external dependencies since that won't help any 3rd party developers who are interested in contributing to the open source portion of our codebase. For those developers, the dependencies should automatically download and install while testing the extension. Our Contribution guide should already be covering the steps necessary to contribute to the extension.
You can copy anything from our TypeScript code that looks useful to you, but like I said earlier, it's probably not the best place to start from if you are planning to write your own language server extension for Eclipse because it does a lot of work that is tied very closely to the closed-source code that you are not entitled to redistribute and would create a lot of cruft for you to sift through.
Our Contribution guide should already be covering the steps necessary to contribute to the extension.
It is good, but at least I thought for some time that to contribute to improving the debugger I'd contribute to this extension, while most parts possibly are out of scope. This is the part where the external dependency notes (as "scope of this extension") may be useful.
Thank you for the warning about looking for a different start when trying to create / contribute to a full free cpp extension, that's fair. And yes - for the legal team to work on the main license file expressing the different parts of the extension is a good thing.
We've updated the root license at https://github.com/microsoft/vscode-cpptools/blob/main/LICENSE.md to mention
Additional binary files may be downloaded at runtime after the initial installation; these are governed by the more restrictive proprietary license terms found at RuntimeLicenses.