Replace DOS stub due to potential copyright issue

[joshudson]

Whenever dotnet build or dotnet pack is ran, it copies this 64 byte part of itself into the output binary (the MS-DOS stub). Guess what license that 64 byte block of code has...

It's certainly not the license for the code I'm shipping on nuget.

Right now I'm casting about, looking for anything interesting I can do about it. I have a replacement for that 64 byte block of code, but trying to replace it in a post build step results in an infinite regression trying to replace the 64 byte block of code in the code that runs the post build step.

An alternative: if you could locate where the code lives in the build tools; I could provide a replacement, and explicitly dedicate it to the public domain so nobody ever has to have this problem again.

[KalleOlaviNiemitalo]

FWIW, the content of the MS-DOS header is hardcoded in PEBuilder.cs. That source file starts with a comment referencing the MIT license.

The MS-DOS header is also standardised in ECMA-335, 6th edition, June 2012, section II.25.2.1 (MS-DOS Header). The section is normative; if you changed the MS-DOS header in the SDK, then it would no longer conform to the standard, and that might become a problem if some patent licenses are granted only for conforming implementations.

That version of the standard includes copyright license terms. The ECMA website also has a page on Ecma International policy on submission, inclusion and licensing of software but I'm not sure whether it applies to the MS-DOS header.

[joshudson]

@KalleOlaviNiemitalo : That spec is wrong in a couple of different ways.

1. Fixing the size of the DOS stub violates the PE specification itself. This is doubly true because they didn't fix the value at 0x3C. Thus the DOS stub can change.

2. There exists a port of .NET to DOS using a DOS extender. Guess how that works.

It's easy to verify that changing the DOS stub does nothing to the .NET runtime by applying a hex editor. I don't have tools strong enough to verify that applying a larger header doesn't mess up the assembly loader. (The DOS port doesn't use an assembly loader, nor can it. Only single file EXE target works.)

[KalleOlaviNiemitalo]

ECMA-335 §II.25 mentions this is "a subset of the full Windows PE/COFF file format". As a subset, it can define more constraints on the MS-DOS header than what is in the PE specification.

[jozefizso]

Guess what license that 64 byte block of code has...

So what license does the block has?

[joshudson]

@jozefizso : Assuming that its embedding is intended to convey the license (which is not in evidence); you end up with the MIT license variant requiring to retain copyright notice, which is not what you want. Most likely this is a mistake and the actual license is the Win32 SDK license from 1993. The Win32 SDK is alive but I was not able extract the license text from it by inspection. https://winworldpc.com/product/windows-sdk-ddk/nt-3x

[KalleOlaviNiemitalo]

The first release of the MS-DOS stub as part of open-source .NET seems to have been https://github.com/dotnet/roslyn/blob/3611ed35610793e814c8aa25715aa582ec08a8b6/Src/Compilers/Core/Source/PEWriter/PeWriter.cs#L561-L579, with a "Microsoft Open Technologies, Inc." copyright notice.

Re "an infinite regression" in a post-build step, you could use a third-party tool like dd to overwrite the bytes; then you wouldn't have to build that tool yourself.

[jozefizso]

I am not sure how the header is against the MIT license. The .NET source code is MIT licensed and the header is part of the runtime source code.

And compiled programs must match the design of the operating system they are running on so the compiled output does not necessary have to be MIT compliant.

[marcpopMSFT]

@richlander may want to take a look at this one.

[richlander]

Can I ask why this matters? The commit in question is from 11 years ago and has produced A LOT of executables in that time.

Is there a concern that the copyright holder is going to act or that one of your users will ask for clarity on these bytes in your executables?

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Whenever dotnet build or dotnet pack is ran, it copies this 64 byte part of itself into the output binary (the MS-DOS stub). Guess what license that 64 byte block of code has...

It's certainly not the license for the code I'm shipping on nuget.

Right now I'm casting about, looking for anything interesting I can do about it. I have a replacement for that 64 byte block of code, but trying to replace it in a post build step results in an infinite regression trying to replace the 64 byte block of code in the code that runs the post build step.

An alternative: if you could locate where the code lives in the build tools; I could provide a replacement, and explicitly dedicate it to the public domain so nobody ever has to have this problem again.

Author:	joshudson
Assignees:	-
Labels:	area-Meta, untriaged, needs-area-label
Milestone:	-

[joshudson]

I got concerned when running a scan for MS-owned code and my own binaries matched on these bytes.

Since I'm dealing with GPL'd .NET binaries I really do have to account for the provenance of all executable code.

There's something else I know that I'm keeping close to the chest right now. The discovery pathway didn't start with .NET binaries; it started with EFI binaries.

[richlander]

PTAL: dotnet/core#9069

[joshudson]

@richlander : It's entirely possible you have a completely different interpretation of the license than I do. I read your document.

[richlander]

completely different interpretation

Hopefully not completely different.

The intent of the additional statement was to say that the binaries the compiler produces carry no additional license burden.

I do want to clarify that we (the authors of that doc) are representing Microsoft, which happens to own those bytes in question as well. Putting .NET Foundation aside for the moment, there is only one copyright holder at play here.

Can you give me a hint on what you'd like to see? Or do I misunderstand your response?

[joshudson]

I was ready to say it was good enough once it hits master.

I just found it odd that it says it's already the case, which doesn't really matter.

[richlander]

I think the primary issue was that there hasn't been any clarity on this point. I hope the doc resolves that.

It would be helpful for you to approve the PR if you are good with it, as the OP of this issue.

[joshudson]

Doesn't look like I can review PRs on this repo.

[richlander]

Apologies. GH permissions don't work the way I thought. A comment would be great.

[richlander]

This is now resolved.

https://github.com/dotnet/core/blob/main/license-information.md