Clean-Room Legal Roadmap

This record is part of the red-team investigation archive. It records investigator-side observations and evidence for later green-team filtration into implementation-neutral specifications; it is not blue-team implementation material.

Date: 2026-05-18.

This record states known facts, open gaps, and project rules for a future clean-room reimplementation. It is not legal advice.

The governing focus is United States and Australian law. The project is not being undertaken in Europe. The EU decompilation regime is included only as a comparison.

Current Project Classification

Known facts:

• This repository contains red-team investigation work.
• The investigation has used a lawfully held copy of Zoo Tycoon 2.
• Investigators have run the game under Wine.
• Investigators have inspected memory, disassembled executable images, decompiled runtime images, named functions and data, carved executable material, patched local experimental binaries, and studied the wrapper/protection boundary.
• The repository contains records, analysis scripts, symbol/name ledgers, wrapper notes, SecServ trampoline evidence, and local experimental artifacts.

Classification:

• This repository is the red-team investigation database.
• It is not the future blue-team implementation repository.
• Records in this repository may contain facts that can be filtered into a green-team specification.
• Records in this repository are not automatically blue-team material because many of them were written from direct binary inspection.

Project rules:

1. Before publishing red-team investigation material, verify clean boundaries.
2. Do not publish original files, carved executables, patched binaries, memory dumps containing original code, SecServ bypasses, wrapper bypasses, or asset archives.
3. Present red-team findings to a green/spec team for filtration.
4. Give blue-team implementers only green-team specifications.
5. Require users to supply their own legally obtained game files and assets.
6. Use Zoo Tycoon, Microsoft, Blue Fang, SafeDisc, C-Dilla, Macrovision, Rovi, TiVo, and Xperi names only for factual or nominative reference.
7. Do not use those names, logos, title art, screenshots, or trade dress as project branding.
8. Treat copyright, anti-circumvention, patent, and trademark questions as separate questions.

Current Effort To Date

The project has produced or used:

• runtime memory dumps and Wine execution logs;
• Ghidra/Rizin analysis of executable images;
• symbol/name ledgers, including hundreds of function names and many data labels;
• wrapper-boundary analysis of SecServ trampolines and runtime slot tables;
• carved or patched executable artifacts for local experimentation;
• asset and XML investigations used to infer domain schemas and game semantics;
• records describing the known binary layout, resource inventory, wrapper layout, SecServ .txt transform, and unresolved regions.

This is red-team reverse engineering for understanding, interoperability, and possible future reimplementation.

This repository is not a distributable replacement engine.

United States Law

Copyright And Intermediate Copying

Known authorities:

• Sega v. Accolade: the Ninth Circuit treated disassembly as fair use where it was needed to inspect unprotected ideas and functional concepts for a legitimate compatibility purpose.
• Sony v. Connectix: the Ninth Circuit held that intermediate copying of the PlayStation BIOS during development of a compatible emulator could be fair use.
• Atari v. Nintendo: the Federal Circuit recognized that reverse engineering object code in lawfully possessed chips could be legitimate; Atari's use of a source-code copy obtained from the Copyright Office under false pretenses created a provenance problem.
• Computer Associates v. Altai: software infringement analysis filters out ideas, processes, facts, public-domain material, efficiency constraints, external constraints, and standard techniques before comparing protected expression.
• Google v. Oracle: reuse of software interface material for a new compatible program can be fair use in context; that case does not authorize wholesale copying of implementation code.

Rules derived for this project:

• Red-team work may document facts, behavior, file formats, schemas, interoperability boundaries, and runtime interfaces.
• Green-team specifications may use filtered factual material.
• Blue-team code must not copy original source, decompiled pseudocode, instruction sequences, recovered function bodies, or expressive game content.
• Provenance records matter. Keep red, green, and blue materials separated.

DMCA Section 1201

Known rule:

17 U.S.C. § 1201(f) permits a person who has lawfully obtained the right to use a copy of a computer program to circumvent access controls for the sole purpose of identifying and analyzing elements necessary to achieve interoperability of an independently created program, when those elements are not otherwise readily available. It also permits necessary means and limited sharing for interoperability, subject to the statutory conditions.

Project rules:

• Wrapper/protection analysis must remain tied to interoperability of an independently created program.
• Do not publish a crack, patched original game executable, wrapper bypass, game asset archive, or general-purpose circumvention package.
• Do not distribute SecServ or SafeDisc code or binaries.

Australian Law

Known provisions:

• Copyright Act 1968 (Cth) section 21 treats deriving source code from object code by decompilation as a reproduction of the program.
• Section 47D permits reproduction or adaptation by or for the owner or licensee of a copy where it is for obtaining information necessary to make an independent program or article interoperate with the original program or another program, only to the extent reasonably necessary, and only where the information is not readily available elsewhere.
• Sections 47E and related provisions address error correction and other limited computer-program purposes.
• Section 47G can remove the benefit of the exception if copies or information made under those provisions are later used or supplied for another purpose.
• Australia also has anti-circumvention provisions with interoperability exceptions for access-control technological protection measures, subject to statutory conditions.
• Stevens v. Sony construed an earlier TPM definition narrowly in the PlayStation mod-chip context. It is not a current general rule permitting game-protection bypasses.

Project rules:

• Keep Australian-facing reverse-engineering work tied to independent-program interoperability.
• Do not distribute original code, copied assets, patched executables, memory dumps, carved binaries, or general-purpose circumvention tooling.
• Do not reuse information obtained for interoperability for unrelated purposes.

EU Comparison

Known rule:

Directive 2009/24/EC, Article 6 addresses decompilation for interoperability where reproduction or translation of code is indispensable to obtain necessary interoperability information, subject to conditions.

Project fact:

• The project is not being undertaken in Europe.

Use in this record:

• The EU rule is a comparison point only.
• It illustrates the same operational boundary used here: decompile only for necessary interoperability information, do not use the information for unrelated purposes, and do not copy protected expression into the independent program.

Comparable Projects

Known facts:

• OpenMW is a replacement engine for Morrowind. It does not ship the original proprietary Morrowind content; users supply their own game data.
• OpenRCT2 is an open-source reimplementation of RollerCoaster Tycoon 2. Its documentation states that original RCT2 files are required to play.
• OpenGOAL is a decompilation/recompilation project for Jak and Daxter's GOAL code. It openly describes recovering source-like GOAL code from the original game.

Project rule:

• The public-distribution model for a future blue-team project is replacement engine plus user-supplied assets, not distribution of original executable code, original assets, carved binaries, or patched binaries.

Copyright Boundaries

Known rules:

• Facts, ideas, systems, procedures, file-format facts, protocol behavior, observed input/output behavior, and functional requirements are not the same as copyrightable implementation expression.
• Original implementation code, source-like decompiled structure, expressive text, art, audio, video, missions, scenarios, and asset content are copyright material unless another legal basis applies.

Green-team material may include:

• asset container structure;
• XML schemas and field names present in user-supplied data;
• file-format records and value ranges;
• observed UI/gameplay behavior;
• black-box input/output behavior;
• high-level state machines;
• compatibility requirements.

Green-team material must exclude:

• original source or decompiled pseudocode;
• function bodies or instruction sequences;
• exact recovered control flow;
• copied implementation constants, tables, or data layouts unless they are functional facts needed for interoperability and are documented as such;
• inferred original source-tree or module structure;
• patched or carved executable bytes;
• wrapper-bypass methods;
• expressive game text, art, audio, missions, scenarios, or UI layouts except as references to user-supplied assets.

Blue-team code must be written from filtered specifications, public facts, independently authored tests, and user-supplied assets.

Trademark Boundaries

Known marks and trade identifiers include:

• Zoo Tycoon;
• Zoo Tycoon 2;
• Microsoft;
• Blue Fang;
• SafeDisc;
• C-Dilla;
• Macrovision;
• Rovi;
• TiVo;
• Xperi;
• associated logos, title art, and trade dress.

Project rules:

• Do not use those names as project names, logos, or branding.
• Use nominative wording only where needed to describe compatibility, for example "compatible with user-supplied Zoo Tycoon 2 game files".
• Do not imply sponsorship, endorsement, or official status.
• Do not ship screenshots, logos, title art, or game UI assets as promotional material unless a separate legal basis is identified.

Patent Boundaries

Known rules:

• Copyright cleanliness does not answer patent questions.
• Patents protect claimed methods, systems, and apparatus.
• A separately written implementation can still infringe an unexpired patent if it practices the claimed invention.

Known project facts:

• Zoo Tycoon 2 is old enough that many patents relevant to the original product may have expired.
• Expiration cannot be assumed for every potentially relevant patent.
• A public release plan needs a targeted patent search for the mechanisms the replacement engine intentionally implements.

Project rule:

• Before public release, perform a targeted patent search covering game-simulation, UI, asset-streaming, pathfinding, and protection-wrapper mechanisms that the project intentionally implements or replaces.

SafeDisc Originators And Rights To Observe

Known facts:

• The protection wrapper is a separate legal object from the Zoo Tycoon 2 game logic and assets.
• SafeDisc began as C-Dilla/Macrovision technology.
• Macrovision and C-Dilla jointly developed and marketed SafeDisc in the late 1990s.
• C-Dilla was acquired by Macrovision in 1999.
• Macrovision later became Rovi, then TiVo Corporation, then merged into the Xperi corporate chain.
• Macrovision sold substantially all Trymedia assets to RealNetworks in 2008.
• SafeDisc operations ended around 2009.

Known gap:

• The present copyright owner of particular SafeDisc program code has not been established from the public sources reviewed here. Depending on asset-transfer documents, ownership may sit in the Xperi/Rovi line, the RealNetworks/Trymedia line, or another successor/assignee.

Patent facts:

• SafeDisc had patent coverage.
• The clearest public SafeDisc-linked patent is U.S. Patent 6,353,890, "Method for copy protecting a record carrier, copy protected record carrier and means for detecting access control information."
• The patent record lists Peter A. Newman as inventor, C-Dilla Ltd as original assignee, later Macrovision/Rovi assignments, and a current listed Rovi-family assignee.
• The patent is listed as expired for lifetime, with an anticipated expiration date of 29 May 2018.
• A 2002 Macrovision announcement described that patent as fundamental to SafeDisc and SafeAuthenticate.

Trademark fact:

• The U.S. SAFEDISC trademark registration appears dead/cancelled for failure to file continued-use paperwork in 2011.

Rules:

• Do not distribute SafeDisc, SecServ, C-Dilla, or related wrapper code.
• Do not distribute carved DLLs, patched binaries, runtime dumps, bypasses, or replacement components derived from protected wrapper implementation code.
• Red-team records may document that SafeDisc/SecServ/C-Dilla wrapper material was observed.
• Green-team specifications treat wrapper behavior as an interoperability boundary.
• Blue-team work must not include copied SecServ logic, copied wrapper tables, SafeDisc-compatible circumvention code, or binaries derived from the original wrapper.
• Patent expiration for U.S. Patent 6,353,890 does not make SafeDisc software implementation code public domain.
• The dead/cancelled SAFEDISC trademark record does not answer copyright or anti-circumvention questions.

Red, Green, And Blue Roles

Definitions:

• Red team: anyone or any agent that has seen the original executable, disassembly, decompiler output, memory dumps, carved binaries, patched binaries, wrapper traces, SecServ trampoline ledgers, or other raw reverse-engineering evidence.
• Green/spec team: a non-implementation review function that may read red-team records and findings solely to filter them into factual, implementation-neutral specifications.
• Blue team: anyone or any agent writing a replacement engine or reusable public tooling from filtered specifications only, without access to original code, decompiler output, dumps, carved binaries, or red-team implementation notes.

Operational rules:

• Green-team exposure to red-team findings is for filtration only.
• Green-team specifications are blue-side inputs only after code-shaped detail and expressive material are removed.
• The green team does not inspect original binaries, traces, dumps, disassembly, decompiler output, carved binaries, or patched binaries directly.
• If a human or agent has worked in the red repository on a subsystem, classify that human or agent as red for that subsystem.
• A red participant does not later implement the same subsystem on the blue side from memory and call it clean.
• Blue agents start from a clean context.
• Blue agents receive only filtered specification files.
• Blue work happens in a separate repository.
• Prompts, inputs, outputs, and review decisions are preserved as clean-room logs.
• Blue patches that reproduce red-side code structure without an independent functional reason are rejected.

Roadmap

Milestone 1: Freeze And Label The Red Investigation Database

Rules:

• Verify clean boundaries before publishing red investigation material.
• Label analysis documents by role:
  • red-team binary analysis;
  • factual interface/specification;
  • blue-team implementation;
  • user-supplied original asset requirement.
• Do not publish carved executables, patched binaries, memory dumps containing original code, asset archives, wrapper bypasses, or decompiler output.

Milestone 2: Produce Filtered Specifications

For each subsystem, write a filtered specification containing:

• file formats and schemas;
• field names and types inferred from assets;
• state machines and behavior tables;
• public or user-visible mechanics;
• black-box test cases;
• compatibility requirements;
• error handling and edge cases observed through execution.

Do not include:

• decompiled pseudocode;
• instruction listings except small addresses used as evidence references;
• original function body structure;
• copied strings unless they are required identifiers from user-supplied data;
• proprietary assets or expressive text.

Milestone 3: Build A Replacement Engine

Rules:

• Create a separate blue-team repository.
• Use a different programming language from the original Windows x86 executable.
• Use a different software architecture and module layout.
• Target a different instruction/machine architecture.
• Do not use recovered function order as an architectural guide.
• Do not directly translate decompiled routines.
• Do not compile, link, embed, patch, or load original executable code.
• Implement against user-supplied assets, XML/Z2F schemas, black-box behavior tests, public gameplay facts, and filtered specifications.

Milestone 4: Compatibility And Distribution

Distributable artifacts may contain:

• original replacement engine source;
• independently authored tools;
• schema descriptions;
• test fixtures that do not contain copyrighted game content;
• scripts that locate user-owned game files without copying them into the repo.

Distributable artifacts must not contain:

• Zoo Tycoon 2 executables or DLLs;
• SecServ or wrapper bypass code designed to run the original binary without authorization;
• packed assets, music, videos, models, textures, campaigns, or scenarios from the game;
• memory dumps or carved binaries;
• trademarked logos or title art.

Milestone 5: Release Checklist

Before public release:

• audit the repository for copied strings, assets, binaries, dumps, and decompiler output;
• document that users need a legally obtained copy of the game;
• add a trademark disclaimer;
• add a contributor certificate requiring original contributions and no copied proprietary code;
• preserve clean-room review logs;
• complete the targeted patent search;
• have counsel review the release package.

Source Notes

• 17 U.S.C. § 1201(f), reverse-engineering interoperability exception: https://www.law.cornell.edu/uscode/text/17/1201
• Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510: https://www.bitlaw.com/source/cases/copyright/Sega-Accolade.html
• Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596: https://caselaw.findlaw.com/court/us-9th-circuit/1452245.html
• Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832: https://law.justia.com/cases/federal/appellate-courts/F2/975/832/163650/
• Computer Associates International, Inc. v. Altai, Inc.: https://www.bitlaw.com/source/cases/copyright/altai.html
• Google LLC v. Oracle America, Inc.: https://www.law.cornell.edu/supct/cert/18-956
• Australia Copyright Act 1968, including sections 21, 47D, 47E, 47G and TPM interoperability provisions: https://www.legislation.gov.au/C1968A00063/2024-03-20/2024-03-20/text/original/epub/OEBPS/document_1/document_1.html
• Stevens v. Kabushiki Kaisha Sony Computer Entertainment: https://www.hcourt.gov.au/cases-and-judgments/judgments/judgments-1998-current/stevens-v-kabushiki-kaisha-sony-computer-entertainment
• Directive 2009/24/EC, Article 6 decompilation comparison: https://eur-lex.europa.eu/eli/dir/2009/24/oj
• OpenMW FAQ: https://openmw.org/faq/
• OpenRCT2 repository documentation: https://github.com/OpenRCT2/OpenRCT2
• OpenGOAL FAQ: https://opengoal.dev/docs/faq/
• SafeDisc patent, U.S. Patent 6,353,890: https://patents.google.com/patent/US6353890B1/en
• Macrovision announcement describing U.S. Patent 6,353,890 as fundamental to SafeDisc and SafeAuthenticate: https://www.cdrinfo.com/d7/content/macrovision-awarded-cd-copy-protection-patent
• RealNetworks acquisition of substantially all Trymedia assets from Macrovision: https://realnetworks.com/press/releases/2008/realnetworks-acquire-trymedia-macrovision
• Rovi completion of TiVo acquisition and TiVo rebrand: https://investor.xperi.com/news/news-details/2016/Rovi-Completes-Acquisition-of-TiVo-New-TiVo-Poised-to-Lead-Media-and-Entertainment-Transformation/default.aspx
• SafeDisc trademark status record: https://www.trademarkelite.com/trademark/trademark-detail/75480951/SAFEDISC