dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.88k stars 4.89k forks source link

Reconsider license of vsdbg #4788

Open JaggerJo opened 4 years ago

JaggerJo commented 4 years ago

Reconsider license of vsdbg

The debugger used in most Microsoft owned IDEs (vsdbg) is shipped with a restrictive license (see below). This makes it harder for other Projects to integrate support for languages like C# or F#.

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------

Considering that Visual Studio for Mac essentially is (based on) Mono Develop, this constraint in particular does not seem fair.

My suggestion would be to move vsdbg to a permissive license like MIT or at least allow other projects to use it.

JaggerJo commented 4 years ago

@terrajobst since I got no response I guess this isn't the right repository to file this issue. Would be great if you could point me to the right repo or person.

dasMulli commented 4 years ago

There's already an issue about this.. https://github.com/dotnet/core/issues/505

JaggerJo commented 4 years ago

Hey @dasMulli,

Yes, but the comments went off topic pretty fast. It also never got an official answer (other than the linked one from 2017).

If Microsoft reconsiders the issue and decides that the change to a permissive license would fit it's open source image that would be great, if not at least MonoDevelop should be added to the list of allowed applications.

vivekcek commented 4 years ago

Give this to mono develop or provide a visual studio for linux.

joshudson commented 3 years ago

Having broken down the license chain, I'm going to recommend a change:

From:

"You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you develop and test your applications."

To:

"You may only use the Microsoft .NET Core Debugger (vsdbg) to help you develop and test your applications."

Why? Because it could be accomplished anyway by another IDE programmatically driving visual studio code, and it may be possible to completely hollow out Visual Studio for Mac because of its original derivation from monodevelop which is LGPL.

ghost commented 3 years ago

Issues like this need more love, make it open source already!

rant Why is .net core and the rest of the ecosystem like OmniSharp, coreclr, EntityFramework, etc open source but the debugger is proprietary?

Why does Microsoft care if I download VS Code from Github.com/Microsoft/VSCode and compile it myself versus downloading Microsoft Binaries from visualstudio.com which supports vsdbg?

There are thousands of developers and contributors to the .NET ecosystem. Microsoft benefits from these contributions like vscode monodevelop and countless others.

Why keep the debugger proprietary when there is no logical reason except "it's always been that way"? This seems like it goes against everything the .NET Foundation and .NET open source ecosystem stands for.

xjose97x commented 9 months ago

It's almost 2024. Are there any news regarding this?

Igorgro commented 9 months ago

Not so much. The only (bad) news is that the hot reloading support for debugging was implemented in closed-source Dev Kit extension, not in open-source C# e extension. Looks like they have no plans to open-source neither the extenstion, nor the debugger.

xjose97x commented 9 months ago

@Igorgro Thanks for the reply! That's disappointing, I wonder what's the intention behind not making it open source.

They've already made pretty much the whole .NET environment open source, why not the debugger?

Igorgro commented 9 months ago

I also have no idea. I can understand not making opensource some commerically profittable tools like copilot or integrations with cloud features (like azure). But the debugger is the same core compnent of "SDK" as the compiler for example. They pretend that .NET is an open-source platform but if you start using it, you will soon find that it is not true.

galvesribeiro commented 9 months ago

@Igorgro Thanks for the reply! That's disappointing, I wonder what's the intention behind not making it open source.

They've already made pretty much the whole .NET environment open source, why not the debugger?

That would be the nail in the coffin for Visual Studio. The reason there are not much alternative IDEs/Editors and we are hostages of Rider is because SOS/vsdbg isn't OSS.

Jetbrains had to implement the debugger on their own. Even for them which are a well-funded company it is a considerable amount of non-trivial work. They lag always behind and features (as of this writing, .Net 8 is not fully supported on Rider yet) and even when they "catch up", still not a comparable experience with Visual Studio.

More and more people from the .Net community (including corporate teams) are moving to use Macs (specially after Apple Silicon) and Linux as their development machines, and that means less VS licenses being sold and (because of the lack of alternative) you have to resort to Rider.

VSCode is AMAZING, but the C# extension was aways subpar (to be polite). Now that MSFT took over its development, it may get better, but don't be surprised if the features start to align with VS that they would be behind "paywall".

Don't get me wrong, I'm not against paid software, and would be willing to pay (more than already do) for it as long as it work. I'm just stating the reason most of us believe this (OSS SOS/vsdbg) would never happen.

For now, as someone that has move away from Windows to MacOS since first .Net Core release, all we can do is still be hostages of JB with Rider.

I also have no idea. I can understand not making opensource some commerically profittable tools like copilot or integrations with cloud features (like azure). But the debugger is the same core compnent of "SDK" as the compiler for example. They pretend that .NET is an open-source platform but if you start using it, you will soon find that it is not true.

I don't think .Net will ever get back to closed source. The community got too big around it.

galvesribeiro commented 9 months ago

That would be the nail in the coffin for Visual Studio. The reason there are not much alternative IDEs/Editors and we are hostages of Rider is because SOS/vsdbg isn't OSS.

Tbh, it doesn't actually need to be OSS. All we need is for this license to get relaxed allowing other products to use it, even if it requires those other products to OSS their implementation around the debugger capabilities.

Igorgro commented 9 months ago

As for me I also not against the paid software but only if it worths that. Being forced to pay to be able to debug software to see a unit tests list widget in my IDE (dev kit) is beyond my understanding.

What I'm against of is marking the product (.NET) with "100% open sosurce" slogan with hidden text "but components A, B and C are proprietary". This smells like fraudulent agreement with a hidden conditions. Such things don't give more respect to MS.

Igorgro commented 9 months ago

That would be the nail in the coffin for Visual Studio

Don't see the connection with Visual Studio here. The debugger should be a part of the core sdk the same as the compiler and the runtime.

On the other hand, there is nothing wrong to make a parts of a proprietary commerical product open-source. For example GitLab have a completely open-source codebaser but this doesn't stop them from making money from it.

galvesribeiro commented 9 months ago

I understand your feeling but I can't agree 100% with you.

Javascript is fully open source. But there is no debugger attached to it nor the spec (if the JS developer actually care about debugging and not just console.log() 😄 ). V8, a javascript runtime in other hand, has the debugger/profiler protocol implemented on it. So any tool can just wrap it and provide a debugger experience.

The .Net SDK/Runtime provide ways to implement the debugger interfaces/profiles so you can inspect the runtime. That is open wide and as expected documented. The problem is that it is very complex as I said and not an easy thing to implement. That is precisely what JB did when implementing Rider's debugger. The debugger is considered tooling. If you look at C/C++ for example, you are not obligated to use GDB to debug your application. People using clang don't use it.

In other words, even though it sucks for us, users, it is not a shady thing as it is done everywhere else.

Don't see the connection with Visual Studio here. The debugger should be a part of the core sdk the same as the compiler and the runtime.

I meant to say that Visual Studio sales are not doing well according to multiple articles as people (developers) are moving away from Windows to use other things, like Macs. The only thing that people working with .Net has which forced them stay on windows, was the old .Net framework. If they moved to .Net Core ownwards, that is gone and they can use whatever they want. That directly imply that people would need an IDE/Editor on those platforms. The SOS/vsdbg uses the same closed source binaries which implement the .Net CLR interfaces for debugging used by Visual Studio.

It would be fantastic if they OSS, but, as said, I doubt it would ever happen.

On the other hand, there is nothing wrong to make a parts of a proprietary commerical product open-source. For example GitLab have a completely open-source codebaser but this doesn't stop them from making money from it.

There are multiple ways of OSS as there are multiple ways of doing business. They've just pick one.

Again, it is all sad, we could have nice new IDE/Editors being built by the community and other companies BUT, there is nothing to blame on MSFT on this one, unfortunately...

KhorAMus commented 6 months ago

I would like to change VS code a little bit for my preferences but in that case I can't use it as a debugger for .NET. Microsoft, please make vsdbg free to use.