OTOY vs. Kozlov

Last month, the High Court of New Zealand ruled that Andrey Kozlov, a former OTOY employee, stole the source code to OctaneRender from an encrypted drive in our office. The court ordered him to pay damages, immediately cease repackaging and reselling OctaneRender as his original product “FstormRender”, and turn over and destroy all stolen source files and derivative works.

Kozlov, now in Russia, is claiming he cannot comply with this court order because he has never possessed any OctaneRender source code.

Evidence of theft of Octane source code

Kozlov submitted the following evidence on July 25th 2017 to prove to the court that “FstormRender” was not using any OctaneRender source code:

Yeah. Holy shit.

He didn’t realize that his Microsoft visual studio user project files — FstormRender.suo and Fstorm3dsmax.suo …literally still point to our stolen Octane source code files and folders on his computer — while he is actively loading them into Fstorm.

For the record, this is a hex dump with exact byte offsets from the court filing:

The computer name recorded by Visual Studio is “Karba DRON-PC” (Karba and Dron Kozy — are aliases of Kozlov)

Structured Storage Viewer, which parses .suo files, provides a snapshot of every open source code window and its position in Visual Studio from when Kozlov last opened the Fstorm source files (shown below). Octane source code files are listed as open documents in FstormRender and Fstorm3dsmax on his PC in Russia.

If he had taken a picture of himself from his apartment in Russia — in front of our source code on his monitor — that would actually be less incriminating evidence of theft.

The Octane source filenames and directories loaded by Fstorm that you see above and below are an identical match to our original source code names in OTOY’s internal SVN tree (of which ‘Octane_Trunk’ is the main branch).

None of this information is known or shared outside the active core engineering team at the company. No employee is allowed to remove or work on any of these files from anywhere other than the encrypted drives on PC’s in our office.

Below, Kozlov had also made a copy of the Octane source code, this time in the same drive and directory (“D:\Works\C++_Works\”) as the Fstorm source code. In these examples, the source code in the Octane files are actively being inspected in Visual Studio (the “OutliningStateEx” list in the .suo shows files that have their source code functions expanded or collapsed with +/- widget in VS)

The duplicated Octane source files loaded into Fstorm, as above, would be a first step to Kozlov making some minor revisions to our code, or sometimes none at all, before saving our files under a slightly different name in an Fstorm folder.

Kozlov, argued to the court, that any duplicate code we presented was coming form the the MAX SDK, or otherwise from him randomly typing the same code twice. He alluded to this publicly. This is provably false.

Putting the 3DS max code aside, Kozlov was adamant that the Fstorm GPU renderer was 100% his original code, and did (and could not) use any of Octane’s source code, since he didn’t have access to any of Octane’s source code while ‘creating’ Fstorm.

Comparison of Fstorm and Octane GPU render source code

The earliest portion of the GPU renderer in Kozlov’s court submitted source code is the QMC (Quasi Monto Carlo) Sampler — that folder was created May 4th 2015. There is no earlier file or folder in the GPU render source tree:

The two versions of QMCSampler.cpp submitted by Kozlov, are largely unchanged and from 2016 to 2017. He did not provide the code to the 2015 or earlier version. All the GPU render kernels in Fstorm connect back to the QMCSampler. Every ray in every image ever made in Fstorm, goes through that code. This is the spine of the renderer, it is why it is in the earliest portion of the source code.

The 2016 version of “QMCSampler.cpp” that Kozlov provided as evidence is presented at right below. On the left is the Octane source code file we submitted for comparison with the same name (in lowercase) “qmcsampler.cpp”, and it dates back to only a few months before Kozlov left the company (the date on our file shown below is from the time the file was copied to our local machine, the original date the file was made is shown in SVN screenshots that follow).

Using the free windows application “Text Compare”, we can run a trivial identical text comparison between these two files and display any identical text found, side by side, which we’ve done below.

The Fstorm “QMCSampler.cpp” file is 13,517 bytes.

Incredibly, only 964 bytes in that file non-identical to our original “qmcsampler.cpp” code.

Here are all the identical blocks of code, with the original line offsets included:

NOTE: for the record, two Unix double carriage returns in line 167 in the left column had to be removed in order for the text compare application to show the highlighted identical lines side by side.

Note that even formatting, tabs, variable names — these are the exactly the same. This is not just identical code — this is identical text.

You might be wondering if this is a freak accident? Perhaps both these files used common code found on the internet to product exactly the same text?

No. This specific source code text has a unique origin we can pinpoint.

This code could have been written differently — in fact it was changed significantly before and after the version shown here.

But the exact specific text shown above was created on September 10th, 2014, by a senior engineer working on Octane — and for the record this was not Kozlov (and even if it was, that would not change this being theft of our company code).

You can see the unique formatting changes and variable names added by our engineer on Sept 10th 2014 below. This is the first time this code ever existed, and to be clear, unless Kozlov stole this file from our SVN, it is impossible that a block of 13 Kb of identical code would show up unchanged in Fstorm’s identical “QMCSampler.cpp”, and match the text fromatting as well as code created by a developer at OTOY in our internal SVN.

It is worth noting that Kozlov didn’t steal the prior version of this file (shown on the left), which was the only one he had actually worked on while at OTOY. He chose to steal the newer version, made by the other lead engineer, for inclusion in Fstorm.

For the record, this block of identical code remains unchanged in the latest Fstorm (as of July 25th 2017), even after two and a half years. In the court filings, Kozloz actually claims this specific file is 100% his original code and work, and not copied from Octane. You may now all judge for yourself whether this is true or not, and whether anything he has said in public posts on the court case are true — such as that our evidence of code theft was a single Max UI screenshot.

As for the 964 bytes of code that don’t match ours in this file? We confirmed that the last few lines in the Fstorm in fact don’t appear in any source code from any shipping version of Octane.

BUT — they do show up in an unpublished branch of Octane source code created by yet another other lead Octane engineer . Kozlov apparently also stole that code from this private source code branch in our SVN (which Kozlov did have access to), even though Kozlov had no involvement at all in any part of this code, and it wasn’t worked on by anyone other than this developer:

Kozlov has tried to deliberately game the court’s source code examination Process

Shortly after our lawsuit was filed, Kozlov made changes to ProxyGeometryIO.cpp (which he knew was part of the evidence we used to get our injunction last July), and renamed it GeometryExport.cpp. Perhaps because of the court case, or because this was one of the files he didn’t even change the name or filename case before saving to the Fstorm folder, he did not submit his original ProxyGeometryIO.cpp file for the court’s source code comparison to our submitted ProxyGeometryIO.cpp. He still has not provided ProxyGeometryIO.cpp — but we know it exists.

Still, even the modified “GeometryExport.cpp” file contains ridiculously long stretches of identical code to ours, sometimes broken up by trivial modifications like replacing “Octane” with “Fstorm”:

There is much more incriminating identical code in the earlier version, including identical spelling errors, which resolve the differences introduced when Fstorm’s ProxyGeomtryIO.cpp became GeometryExport.cpp.

Here are the different portions of code at the beginning of ProxyGeomtryIO.cpp at and GeometryExport.cpp:

Below is the evidence where the differing code (getFirtZeroBit) not present in the GeometryExporter.cpp file Kozlov submitted for analysis — is actually in ProxyGeometryIO.cpp. Kozlov deliberately did not submit for the court examination — this file existed in Fstorm folder (before our lawsuit was filed), and should have been included in snapshot of source code he provided for the 2016 branch of Fstorm:

Fstorm is not a separate shell project later filled with Octane source code — it is literally our Octane project renamed as Fstorm

As of August 6th 2015, “Fstorm” literally included our “Octane” windows, class, name, functions, callbacks and code everywhere. Of course Kozlov changed this later, and would never knowingly submit this version as evidence, however he forgot to wipe earlier partially compiled Fstorm code where you can still see “Octane” window class names all over the place in supposedly original files like FstormMaterial.cpp, FstormBitmap, FstormColorCorrection.cpp and many, many more :

Look at the Fstorm debug info above, and then look at the Octane Source code below (Kozlov has not produced any files that explain the above). Our code below is what makes all these windows and functions show up with the same Octane class and function name in Fstorm and Octane:

If Kozlov had actually started a new project instead of modifying ours and then changing the name later, presumably to save time, none of the Octane code above would have never shown up in any Fstorm code in the court supplied evidence.

Like what you read? Give Jules Urbach a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.