To FOSS projects, leaked source code is highly toxic and infectious. The FOSS community's attitude on leaked source is similar to the corporate world's attitude towards GPL in the early 2000s, but unlike GPL, this is not just exaggerated FUD - the dangers of leaked, unauthorized or proprietary source code is real. Once leaked sources found its way to FOSS projects, the entire project may become illegal and face potential lawsuits (see the history of how BSD was almost killed by AT&T's lawyers). And once leaked sources found its way to your brain, it's not 100% safe [0] to work on FOSS anymore and the best option is banning yourself from participating similar projects, it's almost a memetic virus.
Projects on reverse-engineering and reimplementing proprietary technologies are the most vulnerable. A decade ago, ReactOS's development was suspended for years until the codebase has been reviewed.
[0] It's not illegal. If you can absolutely guarantee your work is not a derivative work based on the leaked source, but just a reimplementation, it's fine to proceed (the clean-room approach is not always needed, it simply offers the strongest legal guarantee). But for a big project with numerous contributors, the risk is high.
Both ReactOS and Wine are open sourced, Microsoft engineers and lawyers look at their code. That's not a hypothetical situation, it happened in the past, the most recent news event on this was: https://www.theregister.com/2019/07/03/reactos_windows_resea....
With the risk of copyright infringement you want to be sure that you're taking active measures to defend your position in case you're facing legal charges.
Yeah, I actually once worked at a place that was clean-rooming. They went to absurd lengths, even WITHOUT the old source code.
If you were designing the new app you couldn't even -look- at the existing UI; you could only get descriptions. Every term was checked by legal to make sure that it was a 'standard' industry term vs something that was specific to the existing software. They even used a different tech stack wherever they could.
I think the other company still tried to sue, IDK how it played out (I was gone by then) but I remember at least thinking they were in a pretty safe spot with how they handled it.
However, maybe having someone external to the project look into, and understand those undocumented functions or system calls, and explaining them to the people which will actually implement them could work.
This is not the first time Windows code leaks. I also have a vague recollection of one of these projects actually having to rip out and rewrite a subsystem because it turned out to be too close to original Windows sources found in one of those previous leaks.
In short, this leak likely won’t affect any project that is seriously trying to reimplement substantial parts of Windows, if they care at all for US law.
Like the thing is a windows binary is not following necessarily following any standard like POSIX. So implementing a compatibility layer without a spec or source can be tough.
AFAIK there are already laws about reverse-engineering for compatibility. May extend that and add something like the right to repair, so the ones who sell software or software services also have to provide documentation and more access to the actual features.
It will reduce the number of eligible contributors. If you have seen the windows source you are not allowed to contribute to wine. Unless someone uses this as an opportunity to document the interfaces and create a test suite and thereby allows a clean room implementation the source code isn't just useless. It actively ruins the wine project.
Regardless of what you do, I'd be extremely careful about looking at leaked commercial source code. While I think you could legally get away with writing code that was just inspired by something you've seen, I not sure I'd want the hassle of having to potentially defend myself if it came to a lawsuit.
