Some pretty bold claims by a Microsoft kernel engineer who works on the Windows kernel regarding ReactOS, the open source operating system that aims to be compatible with Windows.
Axel Rietschin, kernel engineer at Microsoft, has claimed that ReactOS, an open source operating system intended to be binary-compatible with Windows, is “a ripoff of the Windows Research Kernel that Microsoft licensed to universities.”
[…]He says that “internal data structures and internal functions, not exported anywhere and not part of the public symbols, have the exact same names as they appear in the Research Kernel.”
In his recent post, he presents further arguments against ReactOS being a “clean room” implementation done without reference to the source code. “Macros names, parameters, etc. never appears in the compiled code. It is … almost surely impossible that a clean-room reimplementation ends up using macros for the same things, let alone macros with the same or similar names.”
Reitschin does add he is no lawyer, but these claims do raise a number of serious concerns and questions about the ReactOS project. These claims alone will probably ensure no serious commercial entity will ever want to associate itself with ReactOS, and it will be interesting to see if these claims will ever lead to something more serious than mere words.
That’s cute, that’d you’d think a commercial entity would be interested in an OS that strives to replicate a commercial OS. Companies will never get anywhere near that – their corporate legal counsel would have fits over the legal hazards that would be exposed. Even if ReacOS was 100% clean – roomed (which it seems it never has been), no company wants to be the one that has to argue that / prove that conclusively in a court of law. It’s safer to just f’ing license Windows.
Never mind that in 23 years ReactOS hasn’t even reached a beta status.
That it took Microsoft 23 years to discover that an open source project was “stealing” an academic project is troubling.
As you can read (and watch in viton’s video) the claims from Axel that this could only come from the Windows Research Kernel seems wrong. But more importantly this is probably more a question of Microsoft not caring about ReactOS. They probably made an analysis a long time ago about the positives and negatives of going after ReactOS and just decided it wasn’t worth the effort
In one of the posts way down in the thread about this it is mentioned from a (reputable?) source that MS looked at ReactOS quite a long time ago, determined it had lineage right into the research kernel, but didn’t do anything because it is circa NT4 /Win2K kernel code and they were already way past that.
That cost analysis most likely came out that this would make us look bad and move more people to Linux while ReactOS wouldn’t be a threat until everyone in the room was long dead.
That’s the thing about FUD, it doesn’t have to be true, just sounds true enough for people to put add a risk factor.
The interesting thing, in my opinion, is that if this claim is true, then it is likely Wine is also affected since the two projects share so much code. The fact that nothing was said about Wine, which is more widely used, make me wonder.
Additionally, whatever happened to “extraordinary claims requires extraordinary proof”? The “you stole from is” claim is pretty bold.
This sounds exactly like good-ole Microsoft FUD. I still vividly remember most of the claims from the early 2000s. They even invested on SCO during the lawsuit against Linux, just to make sure they could point and say “but think of the risk!” It’s the same here… He shows no proof, but the claim seems plausible, at face value… “Think of the risk!”
1) Wine and Reactos “share code” ie, react takes from wine, not really the other way around.
2) The “shared code” between the projects is win32 api code, not kernel . No kernel in wine.
3) React has always been terrible when I’ve tried it. Who cares about the legal status, if it can’t run basic windows applications reliably.
Any legal action would defiantly be punching down, not worth kicking a dead hoarse.
On github you can get a feeling for how tiny the group of ReactOS developers really is, and of the 14 people listed there, some haven’t contributed in a long time. I assume, the WINE project is much bigger (and has some corporate backing, at least from Codeweavers), so that explains, why the “code sharing” is a one-way street from WINE to ReactOS. But even the much more stable and advanced WINE is not a serious challenge to MS. In part, it might even be the opposite, because MS Office running on Linux only helps to cement their de-facto monopoly.
Microsoft does not change its ways :-/ Its all FUD and EEE – (Embrace Extend Extinguish – Linux that is .. )
When something becomes a threat, they start FUDing and such like they possibly wanted Ubuntu to kill off 32bit software libs to kill Wine backwards compatibility and make Steam less of a threat.
In what possible way could this be Embrace Extend Extinguish?
I thought about the general Linux situation, they have embraced it a lot lately, and now even soon a kernel to run alongside windows kernel(WSL2) and the new Terminal program that is including Bash (?) and Extinguish make Ubuntu “go away” as a “windows alternative” for people like me who use Ubuntu / Linux mint with Wine for 32 bit backwards compatibility and Steam with Proton for a lot of games. I would be forced back into the fold with Win10 ..
Is there any evidence that Microsoft influenced that now reversed decision? And how?
Its not reversed, its just damage control
This isn’t a big surprise. Any sort of Windows compatibility in this manner needs the ability to see how the internals work, otherwise undocumented bugs and behaviour would cause most common programs from the XP era (which ReactOS seems to be targetting nowadays) to fail horribly. If his claims are true, clearly someone has/had access to Windows source code and just did a basic copy and paste
larwilliams2,
Yeah, I’d really like to see specifics underlying his claim. While he could be right, he could just as easily be exaggerating. his post on quora doesn’t provide anything of substance and was more of a rant.
Let’s not forget that ever since the US federal courts have deemed APIs to be copyrightable in oracle v google, all clones of any software are at high risk of infringing API copyrights. Even if developers do create a genuinely new implementation of windows, microsoft could conceivably win a case against them over the windows API which has to be used for compatibility. Barring independent devs from cloning defacto standard APIs is a rather drastic departure from both the intent as well as execution of copyright law in the past.
Copyright law now serves -the machine- there is no public service left.
But is US law applicable if ReactOS is mosly non-US-based?
MikeMe,
You know, that’s a great question. I don’t know.
This is not copyrights, but there have been many cases where US courts excerpted authority over accounts held on overseas servers. The companies argue that US courts don’t have jurisdiction over foreign servers, but it hasn’t stopped US courts from disregarding location and granting access to US prosecutors.
https://www.cozen.com/news-resources/publications/2017/microsoft-supreme-court-decision-on-jurisdiction-over-foreign-located-communications-anticipated
Another example of overstepping jurisdiction is the european GDPR where the law claims to apply in foreign countries. While I don’t necessarily object to the goals of this law, I think it’s ridiculous and dangerous to have courts pretend that there’s no limit to their jurisdiction.
https://www.compliancejunction.com/gdpr-for-us-companies/
IMHO it is wishful thinking that it can be applied against companies that don’t exist locally, since they cannot bring US companies into their courts. However they still might opportunistically detain/punish individuals traveling to europe. I wonder if there have been any cases yet?
As far as the US is concerned, it has no qualms having individuals arrested to go after foreign companies without much regard to jurisdiction. Who knows if the EU would do the same thing if their laws were otherwise powerless against foreigners?
https://www.nytimes.com/2018/12/05/business/huawei-cfo-arrest-canada-extradition.html
Back to React-os, they can fly under the radar because nobody cares much about it today, including microsoft. They’d probably face more severe legal threats by exporting software to iran, haha.
s/excerpted/exerted/
Hmm, I don’t remember typing “excerpted”, might have been auto correct. Every now and then I catch these errors once it’s too late to edit.
Its applicable if some one tries to sell or otherwise make money off of it in the US. I think it also counts if its being distributed to US based persons/entities.
Alfman,
It would be interesting the see what the courts think of libffi. Is it any longer copying an API if you match the calling convention and memory layout when jumping to some memory address? With a language like Java, the language does its linking when loading a classfile, and so relies on the API more tightly, but with native code, hopefully there’s more leeway there. Otherwise, it would literally be insane to copyright calling conventions and memory layouts.
kwan_e,
Yea, but then you should never underestimate the ability of corporate lawyers to contort all reason and have it pass muster with an unqualified judge. In lower courts, the oracle/google case had a judge who had some software qualifications and understood the different nature of API versus implementation, but his rulings were overturned by a higher court that did not have a sound grasp of software interfaces.
As much as I’d like to have faith in ‘reason’ winning the day, that fails to happen a lot of the time.
I’d be pretty surprised by a copy/paste, after all the noise they made about their audit
https://slashdot.org/story/06/02/01/1944257/reactos-code-audit
https://www.reactos.org/wiki/Audit
https://twitter.com/reactos/status/1127515495228485632
they put development on hold for quite a while while checking things out.
But if the MS dev is right, well, I imagine there is some way for a third part to see ReactOS code and MS code and deliver a verdict.
Did you actually read the links you posted? They didn’t have an audit performed, they checked themselves. And as you can read in the first link you provided they don’t really care about being legal: ” If people made mistakes and there was a violation of the law, I question the justice of the law and or anyone that would try to prosecute any of the developers who just want the freedom to learn and create a more free system.””
yeah I read them and read them when they were new. That they were doing the audit themselves is a bit off. If you read my original comment, I said I’d be surprised by a straight copy paste, as something like that would be so easy to see and so easily disprove what they were saying. Wouldn’t surprise me at all if they had the Windows source open in one screen and were rewriting it in another. I would mostly be surprised if the infractions were as blatant as the MS dude was saying, given ReactOS’s stance on it.
React was comparing stolen production NT 4 code, the claim here is that the code came from windows research. Ie different code. Its entirely possible that there is stolen research code, but no windows NT production code.
If that were the case, shouldn’t we expect ReactOS to be reasonably stable by now? In my experience, it is the most unstable, most crash-happy OS I have ever touched, and this is only getting worse. And the main justificiation for why it takes so unbelievably long has always been that they had to rewrite the kernel from scratch. If ReactOS really is WINE code running on top of a ripoff of a Microsoft research kernel, I would assume that the task of producing a relatively stable OS out of it would not be quite that Herkulean.
I’d put on my “conspiracy” hat:
What if someone close to Microsoft wanted to “poison” the ReactOS code by introducing these changes?
… hat out
Given the long history of the project, I do not think there would be fundamental issues affecting its future. However they might need to sit together with some Microsoft folks to clean out any conflicts. It might even be possible that Microsoft can give a reprieve considering their recent positive behavior towards open source.
sukru,
I don’t think microsoft really cares about reactos today. Hypothetically, suing react-os for a symbolic win wouldn’t be terribly useful for microsoft even if it could crush them in court. Reactos has no serious customers anyways. Microsoft would only incur negative publicity, criticism and perhaps even new anti-trust scrutiny. So it may be best for microsoft just to leave well enough alone at least until reactos can conceivably pose a more plausible threat and/or high dollar royalties are at stake.
Alex explained everything here:
https://www.youtube.com/watch?v=2D9ExVc0G10
1) Download everything – MS leaking a lot of info: symbols / headers
2) Look everywhere: books / tools / blogs
3) Lots of hard work
viton,
The point is that the accusation also talked about macros, which are not in the symbols, and apparently highly specific to the internals and not just part of the external headers.
Steven Edwards, ReactOS developer, stated that ReactOS code must comply with the “US standard method for reverse engineering”, defined by him as “one person tears apart the implementation of a device, writes documentation and another reads that documentation and implements.” Edwards said the team would “rewrite all code found to have been implemented not using the US method for reverse engineering,”
So basically Steven thinks it is okay for 1 person to have a look at the source code, write documentation about all the function calls (something like DoSomething(int a, int b) {print a} and write the documentation as “DoSomething(int a, int b) {}” with more documenation like “this function just prints a and isn’t calling any other functions”. Now a second person just has to write the actual code to print a and that would be reverse engineering according to Steven. This would both explain why the same function names (and macro’s) show up while ReactOS still claims to be reverse engineering
avgalen,
No, his definition is legally troublesome. The biggest case of reverse engineering allowed in the US was when Compaq reverse engineered the BIOS. It has to be clean room. The documentation written must be functional/behavioural descriptions.
Copying even function and macro names probably would not be considered cleanroom, let alone specifying internal macros that aided a specific way of implementing something – decidedly not a functional specification.
We agree here, so you meant ” Yes, his definition is legally troublesome”
Alfman already brought up the legal decision that API’s are copyrightable*
* Morally I think that this was a wrong decision and just like Steven and Alex my personal opinion is that you should be able to re-implement the actual code by “taking the API/functions and filling them in yourself”. However personal opinions don’t matter when we are talking about legality. So I greatly respect the work that is put into ReactOS, but I also think that it can be shutdown legally whenever Microsoft decides to give a damn about it
There is nothing that say it have to be clean room, the fact that the IBM BIOS was done like that was to make sure IBM would have no chance of claiming a copyright violation AS THERE WERE NO CHANCE OF COPYING IN THE PROCESS. Remember IBM was huge back then, they had so many lawyers they’d be able to postpone the delivery of the Compaq computer so many years the whole effort would be useless.
But there is nothing that says reverse engineering _have_ to be clean room. Nothing.
Megol,
From a legal perspective, yes it does. And I was speaking from a legal perspective.
Anything that reproduces internal macro names that are not necessary to the functional design of a feature may well as be copy and pasted code, at which point it is not reverse engineering, but copy and paste.
Why can’t I reply to the correct post?
@kwan_e
Then please give references supporting the requirement of clean room reverse engineering. If that is legally required it would be easy.
Megol,
Are you dense? The requirement that is has to be clean room is easy enough to deduce – you can’t straight up copy code. How else can anyone prove that they did not straight up copy code without documented clean room reverse engineering?
Or do you have no idea how common/English law systems, like in the US, work? There does not need to be statutory laws stating outright clean room engineering. All it requires is the legal frameworks in existence, like patent law and copyright law, that makes is extremely unlikely that you can’t keep within those laws without clean room engineering. And when it gets tried in court, as is the way of common/English law systems, there is almost no way any judge or jury would let any non-coincidental similarities get past.
That’s why map makers create trap streets. Please learn how the law works.
There is, as far as I can find, no “US standard for reverse engineering”. There is an IEEE standard. What Mr. Edwards self-defines is not the IEEE standard.
A c macro would not show up in the binary. If a large number of specific c macros were found with the same name and function in both source codes, that would be a pretty unlikely coincidence.
From the article
“In his recent post, he presents further arguments against ReactOS being a “clean room” implementation done without reference to the source code. “Macros names, parameters, etc. never appears in the compiled code. It is … almost surely impossible that a clean-room reimplementation ends up using macros for the same things, let alone macros with the same or similar names.”
No way it was anything close to reverse engineering.
Deeper in the discussion there is an eluded to NT kernel hack that an MS programmer was not proud of, but solved a problem of adding functionality that many ISVs had requested. The hack was very specific to the MS developed kernel code because fixing whatever edge case existed that needed to be solved first, before the new feature(s) could be added, was deemed too risky.
The discussion states that the same hack exists in the ReactOS code. The probability of the exact hack being executed because two separate implementations of an API both arrived at the same edge-case issue is beyond extremely unlikely.
https://www.youtube.com/watch?v=zjbtZ4NgtdA
“The point is that the accusation also talked about macros, which are not in the symbols, and apparently highly specific to the internals and not just part of the external headers.”
Did you watched the video?
Thanks for posting that video. It also explains how he could have gotten the Macro-names: Basically leaked/mistaken-builds that shouldn’t have become public but did. This isn’t what a “clean room” implementation means and it is clear from this video that this guy has a questionable morality*
* At the end he mentions that he obeys NDA’s because he doesn’t want to go to jail and doesn’t want to be a paria
* Around the 17-19 minute mark he mentions that he doesn’t condone looking at leaked builds, but does do it “not for research purposes but to see how things work”
* He keeps mentioning that when things are public you can look at them
* He also mentions that he “used the same names” …aka copying….which is not a good idea when there is copyright on something
All in all my impression is that this is a great guy with a lot of knowledge and skills that is both having fun with ReactOS but should know that it will never “mimic the success Linux had in making the Unix operating system freely available to the masses, except we’re doing it with the Windows operating system.”
avgalen,
My point was that this apparently went beyond API functions. Even if you call it reverse engineering, if it’s detailed enough to specify implementation specific internal code, then they may as well just have copied it and change the names around.
I don’t agree with copyrighting APIs. But I think we all agree that copyright still exists for the actual implementation source. Otherwise, open source copyright licences don’t work. To specify something so tightly as to spell out internal macro names and their purpose is to basically substantially copy the work itself because internal macros, by definition, are not necessary to the function of the code.
Basically, if the accusations are true about highly specialized internal macros and functions, then the “reverse engineering” claim is just an act. It would be a straight up copy.
Don’t hang on to the “reverse engineering” claim because ReactOS isn’t claiming that. From https://reactos.org/joining/faqs: Is ReactOS legal?
Yes we are. All the code that make up the ReactOS operating system has been written from scratch by our developers. We go to great lengths to ensure that the code our developers create is clean. and we make sure that the methods we use to understand Windows internals is also clean. We use a variety of methods to achieve this, which include clean room reverse engineering, using existing documentation freely available both in books and on the web, using extensive tests (tens of millions) which apply black box engineering methods against both public and private APIs which are exposed by the operating system. We believe commercial operating systems should be freely available, and we’re pushing to mimic the success Linux had in making the Unix operating system freely available to the masses, except we’re doing it with the Windows operating system.
APIs have never been considered worth of copyright. They shouldn’t be.
Megol,
[q]APIs have never been considered worth of copyright.[/q[
The US courts have. In the US, that’s the end of story. I hate it, but it’s the fact that the US courts do consider APIs worthy of copyright. To say they never have is just factually wrong now.
Trying to apply some common sense, this story makes no sense.
– if the ReactOS project was eager to copy from leaked Windows sources, then you would expect them to be in a much more advanced state today
– why would someone from Microsoft would lie about ReactOS? it is not a treat to Windows in any meaningful way and it won’t be in the foreseeable future
Except that you shouldn’t expect them to be in a much more advanced state. They’d be where they are, actually – stuck around the early 2000s in terms of compliance. The Research Kernel is circa NT4 / Win2K era code. Microsoft stopped that initiative around then because many licensees of the Research Kernel were ignoring the license and sharing the code.
The Research Kernel code predates removing video drivers from the kernel, the One Windows initiative, all of the security fixes that Microsoft implemented as one of the XP service packs, etc…. It’s ancient.
Really with the USA doing trade barriers. Microsoft might be worried that Reactos might in fact get serous commercial support.
https://www.youtube.com/embed/2D9ExVc0G10
Also is not a new problem where parties who have made mistakes on how much information has leaked out by Windows Driver Kit and MSDN and binaries files. Yes 10 mins in on that video shows a lot of information about Windows source leaked out due to how Microsoft built there binaries..
Dont forget, this is just a single dev who happens to work at Microsoft. As far as I can gather Microsoft (the organisation) is not involved.
+1 to @adurbe
This dev posted this in 2017 and it’s coming back up now again. It’s quite possible that this occurred by a plucky young dev but I agree that Microsoft won’t do much with it — There is no financial nor IP threat from a few functions. Windows has moved long past this level of OS.
Cloning an OS without any real competitive advantage is destined to be relegated to a hobby OS/emulator.
Copying code is endemic problem from college through professional software engineers, and the bigger question is the ethics.
I thought it was referring to copying code from their .net Research OS Singularity, which would have been much more interesting than the older code.
Until some actual evidence is presented, you have to take this with a grain of salt. I’d bet that any “copying” is of the same nature as the “copying” of TSG UNIX into the linux kernel – it was all BSD code that TSG didn’t properly attribute and hence later coders thought they owned it. I’d believe ReactOS has BSD code in it before believing it has W2K code in it. And I’m TOTALLY willing to believe Windows had (has) BSD code in it that’s not properly attributed.