Thursday, February 11, 2010

Objective-C Categories and Derivative Works in Software

This post examines the concept of derivative works in software, as it is understood in the open-source and free software communities, through the lens of the Objective-C programming language, and in particular Objective-C "categories." In short, I'm asking whether Objective-C's categories changes the derivative works analysis for software, given the settled interpretation that's arisen from the open-source community.

What is a derivative work in software?  Nobody really knows, because there are only a handful of cases (if that) on the issue.  Yet, lawyers advise clients every day on the risks of using open-source software, such as that licensed under the GNU General Public License.  This is because, over the course of the past two decades, the open-source community and the free software community have gone to great lengths to build up what is now a well-accepted set of concepts, principles, rules of thumb, and guidelines.  Because these concepts and principles resonate somewhat with traditional copyright concepts and principles, they have been accepted by many IP lawyers, businesses, and developers.  But are they legally sound?

As a former Unix programmer, a copyright lawyer, and someone who often counsels clients in open-source licensing issues and copyleft "contamination," I've been puzzled for some time by what I call the "bit-centric" view toward derivative works in software put forth by organizations like the Free Software Foundation (FSF).  By bit-centric I mean that the focus often seems to be on whether the bits of a library or a module are combined with an application or another library, not whether the application is conceptually based on the library.

I have been to many a FSF presentation in which the FSF lawyers state with great confidence that compiling or linking a math library with a calendar application that uses that library creates a derivative work, simply because all the bits of the two works end up in the same file on the filesystem.  But why?  Why is that the proper focus?

As any copyright lawyer will tell you, according to the Copyright Act, a "derivative work" is:
based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.
In light of this definition, one could argue, with a straight face, that a calendar application is not a derivative work of a math library.  It is not based on the math library in the traditional sense; it is not a sequel or the same work of authorship in a different medium.  It is not an abridged version, or a translation. In fact, it hardly seems to be a recasting, a transformation, or an adaptation of the math library at all, conceptually.  It is simply another work of authorship that ends up getting combined with the bits of the math library to create a single application.  Putting aside the likely sharing of headers, the calendar application doesn't even use any source code from the math library.

We open-source lawyers have all come to accept this bit-centric view of the derivative works in software question.  But there is little foundation for it.  (An examination of the relevant copyright precedent is beyond the scope of this blog post.  I may return for a discussion of cases like Microstar v. Formgen and Galoob v. Nintendo in a later post.)

Now I come to the impetus for this post.

Over the weekend I was reading an Objective-C book in my ongoing quest to write a useful iPhone/iPad app and, when I was reviewing the section on Objective-C categories, I was reminded again of the general weirdness of the bit-centric view in open source jurisprudence.  In Objective-C, categories offer the author of an application the ability to modify classes written and provided by someone else by adding methods that were not in the original class.  And one can do this without having the source code to the original class. You just declare the new classes in your own source code.  This, to me, seems like the quintessential derivative work: you're basing a modified version of the original class on the original class, thereby creating a transformed or adapted version of the class.  But, under the bit-centric view, so long as you kept the bits sufficiently separate, this would not pose what some call a reciprocity problem and what Heather Meeker calls a heredity problem.

Is that the right result?  It may actually be, from a law and economics perspective, or simply from a business standpoint.  But am I the only one who thinks that the bit-centric view is unfounded in the law?

Wednesday, February 10, 2010

Science and Art in the Constitution

I'm rereading Professor Goldstein's fascinating book Copyright's Highway: From Gutenberg to the Celestial Jukebox.  In the chapter on the history behind the passage of the earliest laws protecting copyright, there is an interesting tidbit regarding the definition of certain key words in the Copyright and Patent Clause (Article I, Section 8), which says, "The Congress shall have Power . . . to promote the Progress of Science and the useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."  This is obviously the clause that gives Congress the right to pass the Copyright Act and the Patent Act.  It turns out that, at the time, "Science" was the subject matter of copyright and "useful Arts" was covered by patents.  I guess everything was all topsy-turvy back then, what with Federalists being in favor of a strong federal government and Democrats being frothy-mouthed states-rights literalists.

The original Copyright Act (1790) gave a fourteen-year copyright not only to books but also to maps and charts.  We have certainly come a long way since then.