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.

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!

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

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

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

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.

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.

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.