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=

[dougbu]

Adding @mkArtakMSFT and @Pilchie to give them additional background on the license issues in our two repos.

[richlander]

It sounds like @ChrisSfanos is going to make the required fixes, including in Humanizr.

[MichaelSimons]

Now that the nuget-client license issues are resolved, the source-build logic to account for these should be removed.

[MichaelSimons]

It looks like the licensing issue in Humanizer has been addressed but now we need the product repo(s) to update to a newer version. I opened dotnet/roslyn-analyzers#6186 to track this.

[MichaelSimons]

All of the known licensing issues have been resolved - closing.