I was pleased to be asked to speak again on some topics remaining from my speeches in June and August in front of users of Open Source software.  An accomplished open source software developer and I are tag teaming on the talk.  We plan to discuss several technical and business aspects of intellectual property (IP) and software.

Refresher

The permission-based licensing model of Open Source preserves downstream permissions to source code. Open Source relies on Copyright plus Licensing for protection and permission.

Copyright, Licensing, Open Source – General Pointers

Under US law, copyrights cover original literary, dramatic, musical, artistic, software, and other intellectual works of authorship.  17 U.S.C. § 102(a).  The copyright owner generally has exclusive rights and abilities to authorize others to exercise the rights of reproduction, distribution, public performance, and display.  17 U.S.C. § 106.  Fair Use provides an exception to copyright infringement, 17 U.S.C. § 107.  As a short guide to fair use, I recommend:  Don’t Be a Creatively-Lazy Fan.

The copyright owner’s rights extend to the preparation of derivative works.  17 U.S.C. § 101.  Copyright protects both published and unpublished works.  The form of expression, not the idea behind the writing, is protected.  17 U.S.C. § 102(b).  The copyright protects against a copy that amounts to an unauthorized, substantially similar work.

An IP owner can retain ownership of the IP and grant a license to others for a selected subset of the rights.  The license can be exclusive or non-exclusive to the grantee.  In general, the terms and royalties may be negotiated.

In various situations, businesses may coordinate an approach to employ Open Source Licensing –permissions– in tandem with Proprietary mechanisms –rights– (including Patents and/or Trade Secrets). In Open Source “free” refers to freedom, not price. People who redistribute free software are encouraged to charge as much as they wish or can.

A prominent class of free software licenses is the GNU General Public License (GPL) including its versions 2 and 3 (GPLv2 and GPLv3). The open source aspect is the source code must be made available to whom the binary file is made available. You can charge any fee you wish for distributing a copy of the software, with a pricing limitation that the fee to download the source code cannot be greater than the fee to download the binary file (i.e., the executable). After someone pays your fee, they are free under GPLv2 or GPLv3 to release the software to the public with or without a fee.

As further background, folks may be interested in reviewing some of my earlier posts on Open Source and Intellectual Property Law.

Open Source: IT, IP & Business – August 16th, 2008

Jacobsen v. Katzer Summary – August 19th, 2008

You Can Be the Fairest (User) of Them All – September 18th, 2008

Intellectual Property in an Open Source World – June 11th, 2008

Right Here, Right Now

Today’s topic focuses on software add-ons, including extensions, plug-ins, and patches.  We will walk through the technical analysis to review particular situations.  The technical terminology may have some flexibility, so the terms “add-ons, extensions, plug-ins, and patches” are meant to indicate the subject matter, rather than force the treatment.

Our Open Source model for discussion is the GNU General Public License (GPL).  Useful resources on this topic are the relevant Frequently Asked Questions (FAQs) about GNU Licenses.  We’ll use that input from the GNU Project as our guide.

Let’s look at the licensing relationship between a main program released under the GPL, and plug-ins used by the main program.

Separate Programs

If the main program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for the plug-ins.  The fork function is the primitive for creating a process.  The exec family of functions is for executing a file as a process image.

Single Program

Where the main program dynamically links the plug-ins (i.e., dynamic linking occurs at run-time), and the main program and plug-ins make function calls to each other and share data structures, the treatment is as a single program.  This single program would be treated as an extension of both the main program and the plug-ins. So, the plug-ins need to be released under the GPL or a GPL-compatible free software license.

Borderline Case

Toward favoring GPL control, the main program may dynamically link plug-ins.  Moving away from GPL control, the communication between the main program and the plug-ins may be limited to the main program invoking the chief function of the plug-in with some options, and waiting for return from the plug-in.

Let’s look at the licensing relationship between a non-GPL main program, and plug-ins released under the GPL.

No special requirements

As above, if the main program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs.  So, the license for the plug-ins makes no requirements for the main program.

Sticky

As above, where the main program dynamically links the plug-ins, and the main program and plug-ins make function calls to each other and share data structures, the treatment is as a single program.  This single program would be treated as an extension of both the main program and the plug-ins.

So, that combination of the GPL-covered plug-in with the non-GPL main program would violate the GPL.  A possible workaround is to add an exception to the plug-in’s license, which would then miss strict GPL but could still support Open Source, giving permission to link the plug-in with the non-GPL main program.

We can also continue review of a borderline case as further above about the GPL main program, in this context of a non-GPL main program and a GPL-covered plug-in.  Similarly, the non-GPL main program dynamically linking with GPL plug-ins favors a more connected aspect under GPL.  Communication between the non-GPL main program and the GPL plug-ins being limited to invoking the chief function of the GPL plug-in with some options and waiting for the GPL plug-in to return, favors more autonomy for the non-GPL main program out from under the GPL.

Patch

As a guide on patch aspects, I refer to chapter eleven from a book given to me by the host in thanks for my talk in August.  For our discussion, let’s consider a patch received from a third party that serves to fix a bug in a computer program.  The question posed:  is the patch eligible for copyright protection?

Length of the Patch

Support of the author of the patch’s copyright protection may be viewed as proportional to increasing lines of code, perhaps measured in increments of ten.  Seen in the opposite direction, brevity of the patch disfavors independent copyright protection for the author of the patch.

Quality of the Patch

Code elegance and/or explanatory commenting lend support to copyright protection for the author of the patch.  Mechanicalness (i.e., lack of ingenuity) of the patch disfavors independent copyright protection for the author of the patch.

Implication

Where a patch author sends the patch to a software project manager out of the blue, a limited implied right may exist from the fact of that submission.  The recipient may have an implied right to apply the patch to the project sources.  In the Open Source context, the analysis of licensing for downstream publication and distribution of the main program and patch may proceed as we already discussed above, speaking about the relationship between a main program and plug-ins.

Text Copyright © 2008 Bob Brill

JoomlaChicago Software Community Group, SocialDevCamp Chicago