Tuesday, November 04, 2008

You Can't Copyright a Fact

Previously I have blogged about a key choice in file format and scenery system design: will the file format be "specification based" or "reality based".

Specification based: the format has an exact interpretation of the data. OBJ is an example of this...the format describes triangles and there is only one interpretation of what that triangle could be.

Reality based: the format models real-world concepts; the correct interpretation is "as close to the real world as possible." The nav.dat file is like that.

I have been reading the OpenStreetMap Wiki and hit upon something I didn't realize: you can't use copyright to protect a derived work from a file that simply contains a list of facts!

Now I am a programmer - I am used to writing code, slapping a copyright notice up top, and assuming that it's now mine...heck, I'm the one getting carpel tunnel from typing it out. But consider the nav.dat file; it contains a giant list of frequencies for navaids. It's a fact that the BOS VOR is 112.7. Is my mentioning of that fact in this blog a derived work of the nav.dat file? Of course not, and it's a good thing too because otherwise we wouldn't be able to state facts without IP conflicts.

The OSM guys believe that they need to change their license to something weirder than the CC-BY-SA license they have now because the CC license uses copyright, you can't copyright facts, and OpenStreetMap is really just a huge collection of facts.

Now at this point I've written six paragraphs too many without the obligatory "I am not a lawyer." I am not one. And I must admit, my biggest concern with all of this is that it gets confusing and hard to interpret, and I'd be perfectly happy if there were only 3 or 4 licenses out there for everyone, you'd pick your favorite flavor, and everyone would know what it means.

Suffice it to say, it never occurred to me that a criteria of a file format might be "protectability" - that is, does the file format allow an author to specify something other than facts, so that it is elligible for copyright protection?

If you are an author, the good news is: pretty much all of our file formats would meet that criteria:
  • OBJ and DSF are essentially 3-d modeling containers (DSF is just a damned wierd one).
  • Images are copyrightable, so that takes care of your textures.
  • Plugins are code, clearly copyrightable.
  • ACF files contain, among other things, 3-d models, see the first point.
  • Apt.dat would be the format most at risk of "factualization", but I think you could argue that the arrangement of bezier curves and attributes is more of an artistic 3-d model than a statement of fact.
But who knows, I am not a lawyer.

(Oh yeah, this whole article is written from an entirely US-centric viewpoint...I am even less qualified to speak of such things outside the US than I am here at home.)


Jilles said...

I'm pretty sure your analysis here is not correct. Basically, copyright is about the form (in this case a database) and not about the content (a list of facts). Compiling a list of facts constitutes a work that is (in the US automatically) under copyright. Using such a work to create another work, is something that needs permission from the copyright holder either (e.g. a license agreement). The new work is of course also copyrighted. That's why encyclopedias, dictionaries, law books, etc. are all under copyright.

Of course using the facts in the work is subtlety different than using the work itself. You might argue that this is fair use.

Benjamin Supnik said...


Almost: copyright is indeed about form, but in the United States, it is based on _originality_ of form, not just how much work went into the form. In particular:


That's the ruling that makes the US different from where the EU and UK is going.

No question that the original document, as a whole, is probably copyrightable. But my point is that if the file is a set of facts, derived works that simply use the facts wouldn't be derived works, because the facts they use would not be copyrightable.