Software and copyright, some thoughts

This work is Copyright © Ingvar Mattsson, 2005, <ingvar@ hexapodia.net>. Permission to distribute and re-publish this work unchanged is hereby granted.
Previous version

Copyright applies

Software is, in the interesting ases, a creative work and thus copyright applies, just as it does to books and films.

What is less clear is if the copyright extends to only the source or to the compiled binary. This is where we need functioning analogies. Is the copyright on a film different from the copyright of the script used to produce the film? If so, it clearly should extend to software, since the analogy between the script being "the source" for the audiovisual experience that is the film has a fairly distinct parallel in how the sourec code is clearly what causes (in conjuction with compilers and linkers) the executable code.

What constitutes a derivative work?

Let us, for the moment, accept that copyright extends to binaries. This means we need to figure out what constitutes "derivation". One obvious watershed is linking. Does linking object code imply derivation? Two possibilities exist, "yes" and "no".

It is, again in analogy with books, proper that copyright extends from source to binary. The binary s but a translation of the source. This does leave open the possibility that more than one legal entity has copyright on the binary, though. A translatoa scopyright on the translation (though not the work itself, if I remember correctly).

Linking implies derivation

If we see running software (and the memory space allocated to teh process) as similar to a book and its covers, it is fairly obvious that linking would imply derivation, since a book cannot be published without copyright problems unless there's permission from the owner(s) of the different parts (I am ignoring "fair use"-quoting here).

This has some interesting implications for older computers, where running software has, in practice, access to the whole of the memory space. It doesn't really trouble us, though, since the other running programs are not relevant to the functioning of our imagined program.

It also means that all programs running on a computer is implicitly derived from the operating system. This isn't too surprising, though, since it's much easier to write non-prortabel software than it is to write portable software. Similarly, there is definite exceptions on the GNU General Public License (GPL) that frees a programemr from concern about depending on system-provided libraries.

Linking does not imply derivation

This takes the view that linking is a user-requested operation. Clearly, a book that starts "please buy a copy of book X, cut out pages 77-96 and insert them between page 17 and 18 for the most interesting plot twist you can imagine". Well, OK, it would probably have to state if it's a hardback or paperback edition and probably what printing, since books are occasionally re-paginated between editions and formats.

Clearly, a book starting that way is not a derived work (especially if it readable without that step being followed). This is, in a way, analogous to software referencing external libraries. They only refer to an external library, by name (and quite often version) and a linking header in the executable file lists all such external libraries that need linking in before the program is runnable.

What view is correct?

At this moment in time, I am not sure what would be the "correct" interpretation. I'm leaning towards "linking implies derivation" and "OS providers explicitly allow derivation from system libraries, unless otherwise clearly stated". This, too, is why compiler manufacturers either charge for shipped units or explicitly allow shipping executables linked to their libraries.

This is one of Ingvar's essays

All fields below are mandatory, your email address will not be displayed by the site. All comments are sent to a moderation queue, so do not be surprised that it doesn't show up immediately.

Name:
Email (will not be displayed):
Comment: