Is it possible to be a limit for china because of us-china trade war?

[SongOfYouth]

Some people thinking to turn to some else programing language like java in china, because they worried that the us-china trade war will make the C# became to be not available for chinese.

[richlander]

Microsoft has no policy on limiting the use of .NET for any reason. This topic literally never comes up.

Both Java and C# are sponsored by US companies and have open source implementations. In all likelihood, whatever happens (or doesn't happen) for one will be the same for the other. Also, there are other popular programming languages that match the pattern (sponsored by a US company and open source). No need to stop at C# and Java. I'm confident that nothing will happen.

Zooming out ... Trade wars typically use tariffs are their key implement. Both .NET and Java are free, so fly under the radar of tariffs. There's also bans, but no one wants to ban C#. Global developers (including in China) have and will always have unfettered access to C#.

If Chinese developers want to learn more about C#, I'd recommend this Bilibili space: https://space.bilibili.com/483888821. My team has been contributing to it. Even better, the .NET Website has been translated to Chinese! Check it out: https://dotnet.microsoft.com/zh-cn/. Needless to say, the .NET Team is a friend of Chinese-language developers, wherever they may reside.

[qrli]

@NPUlrk Not a lawyer but from what I know: US export control did expand to take opensource into the scene and requires opensource projects with encryption capability to register, thus even opensource project may have a code from EAR. However, because of the nature of opensource, it is not meaningful to ban the software. Instead, EAR defines subitems to differentiate the case which US really care about - which is software with encryption and especially non-standard encryption algorithm (which is rare). For majority of opensource projects, if there is any standard encryption algorithm included, they want to know it - so the project owner register and get an ECCN code, and that's it.

Practically speaking, all commercial software with ECCN 5D002 is at risk. However, for opensource, e.g. almost all projects under Apache are classified as 5D002, which is in a much worse position than .NET and many other opensource projects. Still, since they are opensource, they cannot really be banned from export in practice. At worst, US may demand commercial companies to stop providing them, but that will re-enforce the community stand on the software.

[qrli]

@NPUlrk Oracle Java is 5D992, same as .NET. (5D992 can be treat as safe.)
Python, even though not owned by a company, is even worse - it is classified as 5D002 because of encryption code.
Even Linux kernel is 5D002.
If you treat that as risk, you cannot use almost anything.

[NPUlrk]

@qrli The strategy I have now persuaded leaders and experts is that .net is the same 5D992 as the Windows operating system, so as long as the Windows operating system is available, .Net is available.

[qrli]

@NPUlrk No, they are different. .NET is in a much better position than Windows.

Windows is a commercial software, which can be practically export-controlled regardless which classification EAR. They can change the rules anytime. The same applies to any commercial software from US, or even with components from US.

.NET is opensource. (It not only runs on Windows, but also Linux, BSD, etc.) The fact it is opensource has much bigger impact than the EAR classification. In EAR, there are exception clauses specifically for opensource software as it is not practical to export-control. Even if the worst happened, 5D002 ones like Linux or Python will be the first to have trouble than .NET or Java.

[NPUlrk]

@qrli Thank you for your reply, it gave me a lot of confidence to continue using .net

[jamshedd]

I'm cross-posting my answer from another thread here so everyone here also has this available.

After discussions with our trade and legal teams we determined we can classify all versions of modern .NET (.NET Core) as "Not subject to EAR". This change is now reflected on the Export Control website: https://www.microsoft.com/en-us/exporting/exporting-information.aspx

Note: .NET Framework unlike modern .NET (NET Core) is a component of Windows and closed source, therefore all versions of .NET Framework will continue to be classified 5D992.c and are subject to EAR