MAME Completes Its Move to GPL-Compatible Open-Source Licensing

On March 4, 2016, MAME announced that the project had completed its move to licenses approved by the Open Source Initiative and Free Software Foundation. MAME 0.172, released on March 30, was the first regular release distributed as a whole under GPL-2.0-or-later, with the great majority of files-including core code-available under the 3-clause BSD license.

Why the older license was not open source

MAME had long published source code, but source availability is not the same as open-source licensing. Its historical custom license restricted commercial use and imposed project-specific conditions. Those restrictions conflicted with the Open Source Definition’s requirement not to discriminate against fields of endeavor and complicated inclusion in free-software distributions.

The old policy reflected legitimate concerns about exploitative arcade cabinets, misrepresentation, and ROM piracy. A license, however, is a copyright permission for MAME’s code; it is a poor substitute for trademark policy, accurate attribution, and enforcement against unauthorized game distribution. Moving to standard licenses separated those concerns more cleanly.

MAME was nearly two decades old and contained work from many developers. The project could not simply replace every copyright notice by editorial decision. Maintainers spent roughly ten months contacting past and current contributors and recording which approved license they selected for their code.

The May 2015 MAME 0.162 announcement said more than 96 percent of source had already been covered by an open-source license while outreach continued. By the March 2016 announcement, over 90 percent-including core files-was under the permissive 3-clause BSD license, while remaining components used compatible licenses that allowed the combined program to be distributed under GPL-2.0-or-later.

File-level provenance remains important. “MAME is GPL” describes the obligations for the combined work; it does not mean every source file has the same inbound license or that BSD-licensed portions lose their separate terms. Redistributors must retain notices and follow the licenses applying to the material they use.

GPL for the project, BSD for much of the code

GPL-2.0-or-later permits use, study, modification, and redistribution while requiring corresponding source and license compliance when distributing covered binaries or derivative works. The 3-clause BSD license permits broad reuse with copyright, license, and non-endorsement conditions and can be combined into GPL-covered distributions.

This structure lets another project reuse eligible BSD-licensed device code without importing every MAME component, while a full MAME build carries the project’s GPL obligations. Developers must inspect current file headers and repository licensing information rather than assume a 2016 percentage applies unchanged to every future file.

What changed for distributions and research

The change made integration, packaging, and reuse compatible with established open-source ecosystems while preserving attribution and license obligations. It also made a conceptual boundary clearer: open emulator source does not grant rights to proprietary ROMs, disk images, artwork, or firmware required by particular machines.

Standard licensing made it easier for GNU/Linux and other software distributions to evaluate and package MAME, for preservation tools to reuse machine-device implementations, and for researchers to build and publish modifications under familiar rules. Public source history also supports reproducible study of how hardware models change.

Open licensing does not certify accuracy, security, or support. Downstream projects still need tests, provenance, update plans, and clear disclosure of modifications. A fork may lawfully change behavior while being a poor historical reference.

ROMs, artwork, and trademarks remain separate

MAME’s executable does not include original commercial game code. ROM, disk, tape, hard-drive, firmware, key, artwork, sample, and manual files can have their own copyright and distribution status. The GPL or BSD license on emulator source grants no rights to those third-party artifacts.

The MAME name and logo are also governed by trademark rules. Open source allows forking code; it does not automatically authorize branding a modified product in a way that implies official origin or endorsement. MAMEdev’s current project information explicitly separates license, software-image, derivative-work, and trademark expectations.

Why the 2016 milestone matters

Relicensing a decades-old multi-contributor codebase required permission and provenance work, not simply editing a header. The result strengthened MAME as executable hardware documentation and as a foundation for preservation research.

It also provides a governance lesson for long-running preservation projects: obtain contributor agreements or precise inbound licenses from the beginning, preserve authorship records, avoid custom terms when standard licenses meet the need, and keep copyrighted third-party data outside the source distribution. Cleaning up decades later is possible, but expensive and incomplete provenance can permanently limit reuse.

The event did not “legalize MAME”; MAME had existed for years. It converted a source-available project with field-of-use restrictions into free and open-source software under established licenses, expanding the lawful ways its own code could be studied, packaged, and reused.

What the dates and percentages actually mean

MAME’s project history gives two separate milestones. On March 4, 2016, the project announced that it was free and open-source software under GPL-2.0-or-later. MAME 0.172, released March 30, was the first regular release using the new project-level license. The announcement and the release are related, but they are not the same event; citing only “MAME 0.172 on March 4” would combine the announcement date with the release version incorrectly.

The same announcement describes a mixed-license codebase: over 90 percent of files, including core files, were under the three-clause BSD license, while the whole combined program was distributed under GPL-2.0-or-later. That percentage describes the files covered at the time, not a permanent proportion for every later release and not a promise that all files can be copied under BSD. New contributions may have different notices, external dependencies have their own licenses, and generated or bundled assets require separate review.

Apply the license at the file and distribution level

For reuse, start with the exact MAME version and file, read its copyright and license headers, and inspect the repository’s license documentation. A BSD-3-Clause file generally allows source and binary redistribution subject to retaining notices and conditions, including a non-endorsement clause. A full MAME build includes components with GPL-compatible terms and is distributed as a GPL-2.0-or-later work. A downstream project should not infer the license of one source file from the license of the executable as a whole.

GPL-2.0-or-later permits users to choose version 2 or a later GPL version when the license grants that option, subject to the selected version’s conditions. In broad terms, when redistributing covered binaries, the distributor must comply with the license’s requirements for notices and corresponding source or a qualifying source offer. The precise obligations depend on what is copied, modified, linked, and conveyed; this summary is not individualized legal advice. Preserve license texts, copyright notices, modification notices, and provenance in source packages and binary distributions.

This distinction is useful for device reuse. A researcher may be able to reuse a specifically BSD-licensed MAME component without importing the entire emulator, but only after checking that component’s file-level provenance and dependencies. Copying a folder can bring along files with different licenses. A clean build recipe and software bill of materials make that review easier than relying on the repository’s top-level label.

An author normally holds copyright in an original contribution unless rights were assigned or another legal arrangement applies. Maintainers therefore needed a basis for changing the terms of code written by many past contributors. Contacting developers and recording their choices was a governance and provenance task, not just a source-format conversion. The history shows why projects benefit from license clarity at contribution time: years later, an unlocated contributor or unclear file history can prevent relicensing even when the code itself is technically straightforward.

For an established codebase, maintain a ledger that links each file or contribution to its author, chosen license, inbound dependencies, and any relicensing permission. Keep the record with version control rather than in a one-off announcement. New contributors should receive the current license policy and know whether the project accepts contributions under BSD, GPL-compatible terms, or another stated choice. These practices reduce uncertainty for downstream distributions and research projects.

Source licensing does not license the emulated artifacts

MAME’s source license covers MAME code. It does not grant rights to commercial game ROMs, disk images, firmware, keys, artwork, sound samples, manuals, or trademarks owned by others. MAME’s software lists and hash metadata identify expected files and machine configurations; they do not authorize users to obtain or redistribute those files. Likewise, a freely licensed emulator can be used with content only when the user has a lawful basis to possess and use it.

The MAME name and logo are also separate from copyright permission to modify source. The project’s legal guidance distinguishes software licensing from trademark use. A fork may need its own name and visual identity to avoid suggesting endorsement. Maintainers should read the current project legal page and the relevant notices rather than treating “open source” as a blanket grant over every element packaged near the code.

What remains current

Current license wording should be treated as version-specific. The 2016 announcement described the combined project as GPL-2.0-or-later, while MAME’s current About page and repository-level COPYING identify GNU GPL version 2 and explain that individual source files can use less restrictive licenses. The historical or later wording must not be silently carried forward to a current checkout. Before redistributing, inspect the COPYING and legal documentation for the exact release, plus the headers on every file and the licenses of its dependencies. The durable 2016 lesson is that open-source status depends on clear permissions and traceable authorship, while preservation data, branding, and platform support remain separate questions.

Related:

Sources: