What if copyright didn't apply to binary executables?

Short URL: http://fsmsh.com/2986


By rights, copyright really shouldn't apply to binary executables, because they are purely "functional" (not "expressive") works. The decision to extend copyright to binaries was an economically-motivated anomaly, and that choice has some counter-intuitive and detrimental side-effects. What would things in the free software world look like if the courts had decided otherwise? For one thing, the implementation of copyleft would have to be completely different.

Hypothetical? Academic? Not if you're a hardware developer! Because this is exactly what the law does look like for designs for physical hardware (where the product is not protected by copyright).

Expression and Function

If you read the basis for copyright law, at least in the USA, you will find that one of the fundamental limits of copyright is that it can only be applied to fixed, tangible representations of particular expressions of ideas, not to the ideas themselves. Thus Anne Rice has a protected monopoly over the novel Interview with the Vampire, but no monopoly on the idea of "interviewing a vampire". You are free to write your own novels in which journalists interrogate the undead, and while critics may well find your work "derivative", copyright law will not.

While copyrighting a recipe for stew may give you a monopoly over printing the recipe, it gives you no power over the distribution of the stew itself

Similarly, while copyrighting a recipe for stew may give you a monopoly over printing the recipe, it gives you no power over the distribution of the stew itself. More significantly, it doesn't give you power over equivalent recipes for stew—that is to say, recipes with exactly the same physical components, quantities, and procedures. In fact, it's very likely that a recipe, which is usually quite minimal in expression, will not be subject to copyright protection at all, simply because there is so little "expressive" content.

Instead, the major content of a recipe is said to be "functional": conveying only that information which is strictly necessary to communicate the composition of the stew.

The difference between The difference between "functional" and "expressive" works: Two cooks will produce essentially the same work, when trying to communicate a recipe, while two poets will produce quite different expressive works. Copyright is meant to only cover "expression", not "function", although actual court cases have lead to some anomalies, such as executable binary software (Character Art: Ryan Cartwright / CC-By-SA)

As a way of further illustrating this distinction, imagine that two different cooks watch a third prepare the stew, and they take notes. Then, each is asked to write their notes up as a recipe, without copying or looking at each other's work. Now, assuming that they are both perfectly attentive observers, they will produce functionally identical works, although their expressive content can be expected to differ.

In practice, because this is a recipe, the two will be nearly identical, because a recipe is fundamentally functional. The residual amount of expression is likely to be so small, that it is not worthy of copyright, simply because of its trivial length.

If, however, two poets observe the same events, and are each encouraged to write a poem expressing their impressions, they are likely to create two quite different works. These are likely to be even shorter than the recipes, but they will be almost entirely expressive, with very little (if any) functional content.

Software is Copyrightable

It wasn't always clear that software of any form should be copyrightable, since it is primarily directed towards accomplishing functional goals. But, software—at least source code—is more like an instruction manual or a set of blueprints than it is like a recipe. It is complex and there are many ways of formulating it which involve much human creativity. Thus, it has significant (and therefore copyrightable) expressive content.

It wasn't always clear that software of any form should be copyrightable, since it is primarily directed towards accomplishing functional goals

But what of binary code? Almost no one ever directly writes binary code. It is usually generated by programs, based on human-authored source code. This is true even of code which is designed in an assembly language!

We have historically defined "creativity" as "something only humans can do", regarding the evidence that a machine can do a job as proof that it requires no creativity. Thus, the fact that compilers exist, which convert source code into binary code with minimal human intervention is enough to prove that binaries are not created by human creativity, but are only the functional end-product of following the "recipe" represented by the source code.

Windows, ReactOS, and the Clean Room

An interesting illustration of these principals, the legal fuzziness surrounding them, and the industry's response, is the case of ReactOS. ReactOS is supposed to be an exact, work-alike clone of the Windows operating system (it is closely linked with the much better known Wine project which emulates a Windows environment on top of the GNU/Linux/X operating system).

Unlike GNU/Linux which is happy to remain a separate platform, requiring specially-compiled binary packages, ReactOS aims to run actual Windows binary executable programs. This means that ReactOS must implement the entire Windows environment. Functions must do exactly what their Windows counterparts would do. In other words, like our notional parallel stew recipes, ReactOS and Windows should be functionally identical.

In order to avoid copyright prosecution, though, ReactOS must be expressively completely distinct and non-derivative from Windows. This is a careful tightrope walk!

ReactOS is a free, clean room re-implemented drop-in replacement for WindowsReactOS is a free, clean room re-implemented drop-in replacement for Windows

So, consider this, especially regarding extremely simple library calls: is it legal for ReactOS to produce identical binary code to Windows? In many cases, it would be extremely hard to come up with code that did the same job, but was in any way different. This becomes even more true when the original code contains bugs, which later software came to depend upon. This sort of "bug compatible" code must often be bit-for-bit identical!

If the binary code were regarded as "functional" (and therefore not subject to copyright, just like our fictional recipes), then there'd be no problem: we wouldn't care what the outcome of compilation were, because that wouldn't be "copying" or "deriving from" source code, it'd just be "using" it.

The industry has adopted a litigation-proof mechanism for making functional (but not expressive) copies of software: it's called the "clean room implementation"

Though the legal necessity of it remains unclear, the industry has adopted a litigation-proof mechanism for making functional (but not expressive) copies of software: it's called the "clean room implementation". In this approach, the functionality of the original software (in this case, Windows) is reverse-engineered by one group of people, who create a "specification document", which contains only functional information about the software. Then, a different group of people attempts to write new software to the same specification.

This gets around the problem of the original software having no published specification, as well as eliminating any cause for believing that the implementors have copied any expressive information from the original work (since they got everything they need from the published specification).

But in the case of Windows, where some of the functions being implemented are essentially BIOS calls consisting of only 10 to 15 machine instructions, the specification is often sufficient to nail the code down to the same 10 to 15 machine instructions. And in the one-to-one simplicity of machine language, the source code is likely to be nearly identical as well (mere differences in the names of variables or labels, while clearly expressive, have not been regarded as sufficient to differentiate two piece of source code from each other for copyright purposes).

So it may well be that creating a "functionally equivalent" operating system to Windows—a true drop-in replacement—will result in a system for which much of the binary executable code is actually identical, even though none of it was copied.

If binary code were treated as intrinsically functional, and therefore non-copyrightable, this would be no problem: two bowls of identical soup made from different recipes.

Why copyright binaries?

So why'd they do it? Well, the short answer is because the copyright office listened to software publishers, and they wanted binaries protected by copyright so they could sell them that way. The only other alternatives were to rely on patents (which the patent office had rejected at the time, and which were not a very popular idea in the industry back then), and to simply rely on the obfuscation which comes naturally to binary code (which is not optimized for human readability).

The copyright office listened to software publishers, and they wanted binaries protected by copyright

Consider what would've happened if binaries weren't copyrightable. Then, a software company, which distributed binaries would have no copyright protection for what they sold. And, like manufacturers of household appliances, they would have no legal recourse against people reverse engineering their products and designing replacements for them. Nor could they bind people into "End User License Agreements" (EULAs), any more than people who sell hammers can. Proprietary source code, would of course, still be kept a closely-guarded secret, just as it is under the current scheme.

What would copyleft look like in a world without copyrighted binaries?

Of course, if the copyright lawyers had taken that route, then the legal landscape that Stallman and Moglen faced in fashioning the GNU General Public License would've been quite different. Assuming no change in the ideology of the "four freedoms", then the "copyleft hack" would've been a bit trickier.

So what would've been the options?

Option 1: Copyleft only applies to source code, binary distribution is unrestricted

Hypothetical Hypothetical "Soft Copyleft": only the design documents are protected, allowing a monopoly on derivative designs that aren't published

The first option would be to apply copyleft only to source code. In this scenario, the GPL would've been essentially identical to the Creative Commons Attribution-ShareAlike license: it would require you not to restrict derivatives of the work, but it would have no true "source code" requirement (because only the source code itself would be covered).

We'll call this hypothetical license, the "Soft Copyleft".

This would mean that copyleft would only affect those who received source code in the first place. Users who received only binaries, would have essentially no right to know how their software worked. Companies could opt to build on soft copylefted software, but never release the source code, only the binaries. Since they never release, they never become subject to copyleft requirements, and the result is essentially no change from the same-old proprietary software publishing game.

Note that this is essentially the effect of the present day GPL if applied in a such a (hypothetical) legal jurisdiction. It is also roughly equivalent to the behavior of the Creative Commons "Attribution-ShareAlike" license in real copyright jurisdictions.

Option 2: Structure copyleft as a contract enforced through a EULA

Hypothetical Hypothetical "EULA Copyleft": A "License Agreement" forces agreement to distribute source with binary products

In this "EULA Copyleft", the license becomes a contract (an "end user license agreement" or EULA) for anyone who receives the source code. It's really quite restrictive, and might very well fail Stallman's idea for "Freedom 0", since use of the source code imposes possibly expensive requirements.

There is also the question of how to enforce the contract: many jurisdictions won't recognize a two-party contractual relationship (one in which you agree to give up freedoms you would otherwise have), unless there is a clear "signing ceremony" and possibly even money changing hands.

Proprietary software has managed to get around this with the EULA, using a "click-wrap" approach in which you supposedly are bound to the contract by the action of clicking on a button during the installation process. But of course, with open source code, you can probably remove the click-wrap before running the installation, so it's questionable whether this would really make sense.

Remember that, even in this scenario, only manufacturers (people who compile the software) are subject to the EULA.

Option 3: Leave as a license, but make derivation trigger copyleft agreement

Hypothetical Hypothetical "Production Copyleft": Derivation triggers copyright agreement, and imposes requirement to publish sources with binary products

This version of the license takes advantage of a another somewhat controversial aspect of copyright. "Copyright" is a monopoly right to copy, not to distribute. You violate copyright not when you sell 300 bootleg copies of a CD, but when you actually made the copies! In fact, the law is written to forbid copying, except for certain "fair uses" (one of which is making a backup copy, by the way—but not making copies for your friends).

Furthermore, you also must have copyright privileges in a work to legally create a derivative of it. This is significant for the publisher described above, who takes a free software, builds upon it, and then sells the result as a proprietary binary.

Had they only made binaries from the original work, they could theoretically have never copied it (using only the copy that was provided to them—or copies made entirely within the bounds of "fair use" exemptions). However, once they make a derivative, there is definite proof that they made a copy. As such, they are bound by the license.

If the license then carries a clause saying that products made from the design (the binaries) must include the source code, or access to get the source code, then the copyleft can be effectively enforced.

The limits of copyleft

Because copyleft is usually included in copyright licenses (and because of the similarity of the name), people often imagine that copyleft is a type of copyright license or that it is bound by the limits of copyright law. This is not true.

Copyleft is actually a consideration or quid pro quo required in exchange for the license to the copyrighted work. Legally, therefore, it can require essentially any form of agreement that is allowed as legal compensation under contract law.

The real limit on copyleft for free licenses, then, is not a legal one, but an ethical one: what sort of copyleft requirements go too far to restrict users' use of the copyrighted work? When does a copyleft become "non-free"? There are a variety of different opinions on this.

Hypothetical? Not for hardware!

This may all seem rather dry and academic: after all, the courts did decide to make binary software copyrightable. Thus, under present-day law, compiling source code to binary is "making a derivative", and distributing that binary is "distributing a derived copy of the original work". Both actions clearly require copyright privileges, and thus there is no problem with requiring source code to be made available to recipients of binaries.

But there are many other cases where an information product (a design, schematic, or Computer-Aided Design/Computer-Aided Manufacturing (CAD/CAM) file) is used to drive production of products which are not covered by copyright. The distribution of these products does not trigger any sort of copyleft clause, because manufacturing parts to a design is mere use, and not copying, under the present-day copyright laws.

Many aspects of open hardware projects are not subject to copyright, which also means they don't have an effective copyleft (Credit: Open Graphics Project)Many aspects of open hardware projects are not subject to copyright, which also means they don't have an effective copyleft (Credit: Open Graphics Project)

There are a few exceptions: for example, in the semiconductor industry in the USA, there is a "mask right", which is a "copyright-like law" restricting the copying and distribution of the mask data used to create semiconductor chips. No such law exists for printed circuit boards, though. Nor for automotive engines or other devices. Indeed, we probably don't want such laws!

Most open hardware designers today use the unmodified GNU GPL to license their work. Many appear to believe that building products from their designs is "equivalent to compiling a source code into binary". From a technical perspective this is sensible. Legally, however, it is not correct!

Using the GPL for hardware designs allows a company to create a monopoly on a derivative design, which they never publish, but only use to manufacture products

Using the GPL for hardware designs allows a company to create a monopoly on a derivative design, which they never publish, but only use to manufacture products. In other words, its effect on hardware designs is equivalent to my "Soft Copyleft" case described above. The only real protection you get from the requirement on providing source code is for "synthesis" tools like those used to create FPGA bitstreams from human-readable Verilog source code (the GPL requires that the Verilog source be included when the bitstream is distributed).

If we want a strong copyleft license for open hardware, we'll have to write a license which operates more along the lines of the "Production Copyleft" option above: something which invokes copyleft requirements beyond the limits of the copyrighted design. Thus far, only the TAPR Open Hardware License attempts to implement a copyleft like this, although it is a relatively untested license, and in any case, is very specific to circuit board designs.

On the other hand, we also have to be much more explicit about what should not be covered by the copyleft, in order to retain our ethical commitment to users' freedoms.

Disclaimers & License

Although I've done my best to get the legal facts right in this article, I am not a lawyer, and this is certainly not legal advice. Although I believe that most of the concepts in this article apply to many jurisdictions worldwide, the focus here, and the explanations I've presented are based on US law.

The article and accompanying illustrations may be re-distributed under the terms of the Creative Commons' Attribution-ShareAlike 3.0 License, with attribution to "Terry Hancock" and a link (or reference, if printed) to this page.

Special thanks to Greg London for a lot of enlightening discussions on the subject of "functional" versus "expressive" content and the formulation of copyright with respect to it.



sepreece's picture
Submitted by sepreece on

While I agree that the pragmatic reason for extending copyright to binaries was that Congress accepted the argument that there needed to be a way to protect software, I think there is also a reasonable rationale.

The argument (which I don't claim as original to me!) is that the binary is not an independent work, exactly because it is mechanically-produced. Rather, it is the SAME work as the source-code version, merely in a different form, and therefore protected by the work's original copyright. This is pretty much the same as would apply if someone tried to print a book reset in a different typeface. It's still the same book, despite the mechanical processing. The very lack of creativity creates the equivalence.

Note, though, that even if you treated the binary as a translation of the source code, which would be more natural, it would still be protected, since translation is one of the rights reserved to the author.


Terry Hancock's picture

Perhaps. It's one of those edge cases where you could argue back and forth endlessly. The problem I see with your argument, is that it still assumes that the manufactured product made from the design is a "work" (in the copyright sense) at all.

This is not considered to be true for PC boards or chip masks, for instance -- even though they are actually made by printing processes! Nor is it seen to be true for parts made on a cutting machine or a 3D printer, even though these are equally mechanistic "copies" of their respective design documents. It certainly doesn't apply to CNC lathe or mill products made from CAM files, no matter how much or little supervision is required in applying them.

A compiler, on the other hand, often requires extensive supervision to produce a usable binary on any given new platform -- so it could be argued that it is much more like a CAM file than like a printing press. So, I think it's easier to understand the inclusion of binaries as an exception.

Of course, the point here is not so much that copyright "shouldn't" extend to binaries, but rather that it would've made just as much sense for it not to have been so extended. And that would've made the copyleft in the currently written GPL practically toothless.

I'm hoping that this "what if" approach makes it easier to understand what the problem is with creating copyleft licensing for hardware (or any design derivative which isn't copyrightable). IOW, the problem with copyleft for open hardware is exactly the same problem as would've occurred for free software had the courts decided not to extend copyright to binary executables.

steveballmer's picture

Whay can't you people ever want to pay for anything?


Mauro Bieg's picture

To summarize: the problem with physical products/hardware (as opposed to digital files/software) is that copyright law doesn't acknowledge the step of manufacturing hardware based on a plan/documentation as making a derivative work. Thus, to prevent people from building hardware based on your plans without sharing their modifications you cannot use copyright law, right?

So we need contract law (like EULAs use). But there the problem is: when and where does the act of concluding that contract take place?

One ugly solution would be to require people to go to a website and click on a 'I agree to the following contract'-button in order to being able to download the plans or documentation. That way you'd have your contract signed. Obviously it would need to contain a clause that says you aren't allowed to copy/redistribute the plans/documentation but through a similar mechanism where the new recipient has to sign the same contract again. I admit, it's complicated and ugly but I guess it would work, wouldn't it?

Terry Hancock's picture

Well, that was my option #2. I've already pointed out the holes in that one in the article. I don't think it would work in practice, and a lot of people would consider it "non-free" as well.

I prefer option #3 (that's why it comes last!): make creating a derivative work trigger an agreement to copyleft the products.

This doesn't require a EULA, clickwrap, or any of that kludgy stuff.

It has the downside that people who simply manufacture from your design don't have to deliver source code to the customer. But that's okay, because the customer can get the source code directly from you (because it's the same source code as you delivered to the manufacturer).

Back before the internet made dissemination of information so easy, that might have been burdensome (on the designers), but it just isn't a problem today.

The critical thing is when a manufacturer improves the design (standing on your shoulders, so to speak). When that happens, you want the quid pro quo of copyleft to kick in and make sure that those improvements go back into the pool of available information (or at least to the customer who receives the product).

But in order to make that improvement, the manufacturer had to derive (or "adapt") the original work. That is a copyright privilege, so doing it implies acceptance of the license (just as with any other free license).

If the license then includes an agreement to distribute source code with the resulting product, then the improved design will be published as an obligation of deriving from the original design work. And that closes the copyleft gap.

Which is my recommended solution to the problem.

Mauro Bieg's picture

yes, it's option #2, except that you couldn't get around clicking the button by just removing it from the open source code because the file you want is on a server...

ah, yes, seems you are right. I thought it was legal to make an unauthorized derivative work as long as you don't publish it. But at least under US copyright law this doesn't seem to be the case and thus your option #3 works great!

So why doesn't that Open Hardware Foundation employ a lawyer to write a general free/open hardware license based on that principles!?

Terry Hancock's picture

Well, because lawyers are expensive.

So I'm writing the draft (my second attempt, actually -- the first one was too complicated). Fortunately, a lot of this can be done by learning from other licenses. Which is not unprecedented.

Discussion is on the OHF licenses list, which you can join at:

OHF Licenses (mailing list)

(Though having just had a hard time finding that, I realize we are not doing too well at marketing).

Once we have something to start from, then we'll start hacking it apart again to make sure we're covering the things designers will be concerned about.

After that, I hope we can have a lawyer review the license. This is not that different from what has happened with other free licenses.

Mauro Bieg's picture

wow, that's cool! As soon as you have a draft I'd recommend making it available for review and announce it at some places to get feedback from as many free/open hardware developers/participants as possible.

If the OHF's name is their motto, they are certainly the right forum to draft, discuss, finalize and then promote such a license. Good luck!

And just as a suggestion: maybe it would help to reorganize the OHF website a bit in order to get the following three things a bit differentiated (as I stopped looking for a Open Hardware license when I had read the general 'about' text on the home page and thus didnt find your efforts either):

  1. Open Hardware definition, license, distribution, theories etc.
  2. Open Graphics Project
  3. General stuff about Open Hardware and other projects

Jovomia's picture
Submitted by Jovomia on

"...there are many other cases where an information product (a design, schematic, or Computer-Aided Design/Computer-Aided Manufacturing (CAD/CAM) file) is used to drive production of products which are not covered by copyright..." Do you have any proof of this statement? I'm working as CAM freelancer and never found copyright issue.

Mia Jovovich

Terry Hancock's picture

I think either you are misunderstanding what I said, or I'm misunderstanding what you said:

The text you quoted is essentially just a definition of CAM, which you obviously know exists: you use a computer file in combination with some CNC machinery to make a physical product.

Your statement appears to confirm what I said, not refute it -- copyright does not interfere with you making products from copyrighted plans.

Are you asking for additional proof to confirm your own experience?

I think it's a fairly basic legal principle that copyright doesn't extend from a plan to a thing made using that plan, even for CAM data. I don't have any legal precedents to back it up, though, and I am not licensed to give legal advice anyway. If you really want to make sure that what you are doing is legal, you'd probably need to consult with a lawyer.

designthemedia's picture

currently designing a new opensource hardware soundmachine.

I targeted a GPLv3, but I'm interested by TAPR OHL.

I'll license the software with GPLv3
But the hardware ?!
I read about the OSHW (http://freedomdefined.org/OSHW)

My purpose:
forbid any company to kill the opensource chain!
it is my main purpose.

julien bayle

Author information

Terry Hancock's picture


Terry Hancock is co-owner and technical officer of Anansi Spaceworks. Currently he is working on a free-culture animated series project about space development, called Lunatics as well helping out with the Morevna Project.