The Newlib Trap: Licenses, Homebrew, and You

almost all homebrew is infringing, but not for the reasons you'd think


Published on July 17, 2022

Does your homebrew project infringe on anyone’s copyright?

You might be quick to respond with “no, of course not”. After all, you’re a good citizen using open-source toolchains (as opposed to leaked SDKs) and open-source libraries (asumming they’re not a stand-in for leaked SDKs). That means you’re doing everything you have to, right?

Obligatory note: I am not a lawyer. This is not legal advice. Most lawyers would probably flee the moment I said “as opposed to leaked SDKs”… That’s fair, really.

Case Study: Newlib

Let’s take a look at Newlib. Newlib is a C library intended for use on embedded systems. Many homebrew toolchains make use of it as part of their stack. It makes sense, as it’s a very mature implementation suitable for this exact purpose. If you’ve built homebrew for the GBA, the DS, the 3DS, the Switch, the PSP, the Dreamcast or many others - you’ve almost certainly made use of Newlib. As it isn’t typically exposed through the manufacturer’s base system, it is typically statically linked into the target binary in a homebrew context. This means that you are redistributing portions of its code in binary form.

What license is Newlib under? From context, it’s clear that it falls into the free software umbrella, but what does it precisely ask of the developer?

This is the copyright notice file for Newlib. Let’s read through some snippets:

Unless otherwise noted in the body of the source file(s), the following copyright notices will apply to the contents of the newlib subdirectory

Chances are, if you’re using Newlib, at least one of the source files you’re linking with carries these terms. Let’s read the second among them:

(2) University of California, Berkeley […] Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: […]

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

… Huh.

When have you last seen a homebrew release reproduce this notice - or, in fact, any notice?

Remember that we’re doing static linking as part of most homebrew. With dynamic linking, we typically include the library explicitly with binary distributions (and thus - hopefully - its copyright notice with it), or not at all (and leave it to the system, the package manager, etc).

It’s not just Newlib

I’ve named this issue “the Newlib trap”, as said library presents a case with the widest set of affected platforms. However, it’s not at all exclusive to it! All code you’re using in your homebrew project will typically be statically linked, therefore all of that code can impose restrictions of its own.

Let’s check with a few more popular libraries:

  • Popular GBA libraries require notice reproduction by virtue of their chosen licenses:
    • Case #1 uses a custom license - see clause 3.
    • Case #2 uses the MIT license.
    • Case #3 uses a BSD-style license.
  • Case #4, a PSP homebrew toolchain, uses a BSD-style license.
  • Case #5, used for file access on many homebrew platforms, requires notice reproduction.
  • Case #6, a Wii U homebrew library, uses the GNU GPL without a linking exception. This is particularly bad, as it means that all Wii U homebrew using it must be released under GPL-compliant terms.
  • Case #7 is actually libc++, used by LLVM as a C++ standard library!
  • Case #8, an abandoned Switch homebrew toolchain, used the ISC license.
  • Case #9, an alternate NDS homebrew toolchain, uses the GNU GPL without a linking exception.

Older platforms are not free from this issue, either:

  • Case #10 and its forks are in the process of figuring out the 26 years of their licensing history.
  • Case #11, a PS1 toolchain, uses the MPLv2 license, which requires distributing a copyright notice.
  • Case #12, a Mega Drive/Genesis toolchain, uses the MIT license.
  • Case #13, a modern 6502 toolchain, uses Apache 2.0 - see Section 4(a).
  • Case #14, a GameBoy sound driver, uses the MIT license.
  • Case #15, a ColecoVision toolchain, uses the LGPL license - but we’re talking about static linking, so…
  • Case #16, a highly-optimizing 6502/68000/etc. C compiler, is licensed for non-commercial purposes only on most platforms.

There’s many more, but I hope these are sufficient to show both the complexity and pervasiveness of the issue.

Why does this matter?

As a chronic overthinker, I see three main reasons worth considering:

  • More and more homebrew is receiving physical and/or paid releases. The NES, GameBoy and Dreamcast scenes have had a sizable number of commercial unlicensed homebrew community-created games, with newer platforms, like the GBA, being experimented with. This gives the profit motive which makes a lot of this potentially worth pursuing.
  • There have been cases of rogue developers choosing to DMCA even their own project for their own choice of license. Most notably, this happened to the CraftBukkit server for Minecraft in late 2014. Given how many parties are involved in the collective sum of homebrew library code, it is unlikely but possible for one of them to try and enforce such an issue.
  • It is a little concerning from the perspective of principle to say “my homebrew creation is 100% non-infringing!” and then immediately follow it up by violating the copyright of a few companies which aren’t the console manufacturer, and a few dozen smaller creators along the way.

Of course, in the end, it realistically doesn’t matter. Many of these licenses have been violated for almost two decades now, and some of these - Newlib’s, certainly - have been violated by much bigger parties than garage homebrew developers. In fact, it’s not like commercial games haven’t 👏 been 👏 caught with similar issues in the past.

However, many people I talk to nonetheless care about being as close to being in the copyright clear as possible. For the benefit and legitimacy of the community as a whole, I think it’s worthwhile to at least discuss the status quo and consider ways to improve upon it.

How do I fix this?

Obligatory note #2: I am still not your lawyer. I give no warranty as to this advice; if you want to be extra sure, especially in the context of commercial releases, consult your lawyer.

Figure out your software bill of materials. Make a list of all libraries your project links to, note their licensing terms, and make sure to comply. For many licenses, this may be as simple as adding the copyright notice to your documentation - a physical booklet or a COPYING/README text file. Alternatively, one could try bundling it in the game itself.

There are some non-obvious and poorly documented sources of such libraries and their requirements, however:

  • While not explicitly provided by the end user, crt0 bootstrap files are also code, and therefore can impose licenses of their own. In this case, the MPLv2 governs the use of this code.
  • It’s not just C that has a standard library - other languages can provide their own standard libraries. For example, while this Nim-on-GBA library uses the zlib license, Nim’s own library is MIT-licensed - imposing a copyright notice distribution requirement.

Conversely, one should remember that a build tool being licensed under given terms doesn’t necessarily impose its terms onto a finished binary - the question is closer to what do you redistribute? than what do you use?.

Of course, having everyone figure out their own SBoM by hand can cause problems. It requires toolchain knowledge not every user possesses, as well as being aware of some peculiarities which can be non-obvious - like the ones presented above. Can we, as the homebrew community, do more to help?

How do we fix this?

First of all, there are many licenses which do not impose terms on redistribution of statically linked binaries. For example:

For new statically linked libraries, especially core or effectively unavoidable ones, it’d be great to consider putting them under these terms. Some common libraries already do so:

  • Case #17, a C++ GBA abstraction layer, is zlib-licensed. However, it depends on other libraries which are not.
  • Case #18, Case #19 and many other newer libraries from the same organization also avoid this issue.
  • Case #20 as a whole, including its 6502 runtime library, is zlib-licensed as of 2015.
  • Case #21 for the Master System uses a mix of public domain and GPL-with-exception terms.
  • Case #22, a set of optimized memory/arithmetic functions for the GBA, uses the zlib license.

For older libraries, a relicensing might be possible - for examples, see Case #23 and Case #24. However, many of them will have contributors which can no longer be realistically reached. In other cases, it’s unlikely we’re going to have the resources necessary to write, say, new language standard libraries from scratch (…unless?). Sometimes, a creator might wish to deliberately enforce an attribution - which a copyright notice inclusion effectively provides.

If a license change is not possible or desired, the best thing we can do is provide clear documentation on what the licensing obligations of the user actually are when redistributing binaries made with a given set of tools.

Conclusion

All of this is probably a giant nitpick.

… No, actually, it definitely is. However, I’ve seen projects fall from grace for less, and so I want people to at least be aware of how the nightmare of software copyright affects the little niche of making ROMs as a hobby. Thank you for your time.