Handle non-required files under non-open source licenses

[omajid]

When ArPow builds a tarball for the complete .NET source code, it includes code from all the individual repositories. Some of those repositories have code that's still under a non-open source license.

Some of these are blockers to releasing .NET and are being worked on (eg, dotnet/runtime#56394 and #2344).

However, there are additional files without clear movement upstream. They are also not strictly part of "building the SDK". Some are tests, some are samples. For example:

• [Bug]: Non open source code in end to end tests NuGet/Home#11094
• jquery-validation-unobstrusive in samples is licensed under a non-open source license aspnetcore#34785
• This project is under Apache but the nuget package is licensed under a different license? aspnet/jquery-validation-unobtrusive#140
• Non-open source code in this repo Humanizr/sample-aspnetmvc#1

As a workaround, maybe we can delete these files when building the tarball?

[omajid]

In Fedora, I have this set of steps to remove similar issues in 5.0: https://pagure.io/dotnet-sig/dotnet5.0/blob/master/f/build-dotnet-tarball#_153

# Remove files with funny licenses, crypto implementations and other
# not-very-useful artifacts to reduce tarball size
rm -r src/aspnetcore.*/src/SignalR/clients/java/signalr/gradle*
find src/aspnetcore.*/src -type d -name samples -print0 | xargs -0 rm -r
rm -r src/NuGet.Client.*/test/EndToEnd
rm -r src/runtime.*/src/mono/
rm -r src/Humanizer.*/samples/

That was more of a blunt hammer; we can be more surgical about what we delete.

[dagood]

Fixed by workaround for 6.0:

• [release/6.0.1xx] [ArPow] Delete optional files under non-open source licenses installer#12507

Think this is worth a followup issue to figure out what's going on upstream?

[richlander]

Can we re-consider this solution for .NET 7? Even if we got half of these remediated for .NET 7, that would still be a step forward. Fair?

[omajid]

Sure, we would love for this to be fixed in the individual component repos. But as you can see, we have had no traction on the individual issues. Some of them have been open since 2020!

This solution was only adapted because it let us "fix" the issue without bothering the consumers of source-build (eg, RHEL, Fedora).

[richlander]

Can someone point out where the ref to the Humanizr project is coming from?

[MichaelSimons]

Can someone point out where the ref to the Humanizr project is coming from?

roslyn and roslyn-analyzers reference it in a number of places.

https://github.com/search?q=humanizer+repo%3Adotnet%2Froslyn+repo%3Adotnet%2Froslyn-analyzers+extension%3Acsproj&type=Code&ref=advsearch&l=&l=