Metaprogramming and the GPL
The prospect of metaprogramming tools raises threats and opportunities for OSS. The biggest threat is that they could be used (legally or not) to strip copyright from OSS. On the plus side, innovation in the next version of the GPL could solve the patent morass by adding a "patent shredder" to "copyleft". I propose the introduction of a "Greater GPL" in GPL Version 3 to address these issues.
What if a computer could understand source code well enough to author new programs? What are the intellectual property right implications? While many are skeptical of such a prospect (and rightfully so), and more than a few even (foolishly) reject the possibility outright, it remains the dream of programmers young and old. Efforts in this arena goes by various names. Metaprogramming is generally applicable, as is Artificial Intelligence. I call my pet project PUP (the Program Understanding Program). And while little demonstrable progress has been made in the decades I've been contemplating this problem, the abundance of raw material pouring forth from the OSS community and the raw power escalating by Moore's Law continues to fuel the palpable sense of a breakthrough coming RSN.
Let me offer a reason why you should consider this possibility as a person concerned with OSS licenses. Suppose there existed a program that could transform source code into another source form and that you could not determine whether the resulting work was produced by mechanical translation. Even with current technology, someone wishing to circumvent a copyright license can use an obfuscator to make determining whether a work has been copied quite difficult (the human-meaningful text strings being the typical tip-off). But with a "transformer" that worked on a semantic level rather than just syntactically, I assert that such determination could be made impossible (or at least inconclusive). In fact, since copyright protects the expression and not the meaning of a text, such "transformation" might be legal even in cases where you know that the copyrighted material provided input to the creation of the new program. Regardless of the legality (and IANAL), the fact that the derivation is unprovable by comparison makes prosecution moot and not the slightest deterrence to the unscrupulous.
What can we do about this nefarious "copyright stripping"? Well, nothing directly that I can see, but indirectly there is. If we can provide sufficient incentive to lure metaprogramming tool developers into licensing their works under the GPL then the virtuous circle of OSS grows stronger yet, and the bad guys will continue to be a marginal concern (as they are now). So this finally gets us around to my idea which arose a few years ago as I thought about whether I would open source PUP (in the eventuality that I reduced it to practice) and connected that with the long simmering software patent problem. Talk of a new version of the GPL has finally spurred me to action (months after I heard about it naturally).
The Greater GPL
So imagine we've written a program that can read programs and that can author both new and derivative works, and that we want to use an OSS license. While great joy would naturally result from such a boon, a veritable Pandora's Box of intellectual property right complications also opens up. Rather than exposit on all the various imaginary scenarios, let me suggest a sword for this Gordian Knot. Use a copyright license for this wonderful tool which requires that all the software it generates be licensed as OSS.
One of the (big) strands in that knot of course is whether those with copyright on the software that the metaprogramming tool read would have (or assert that they have) copyright on the works that it generates. Rather than get into the cases where they do or don't, let's just limit our concern to works licensed under the GPL. Clearly such use is compatible with the GPL, and as an inverse of the Lesser GPL, it is the Greater GPL.
An essential key for this to work is that the GPL be revised to introduce this third type of license and allow GPL works to be relicensed as GGPL (which covers whatever happens to code that the tool reads). Additional language is needed to address what constitutes the tool's output and thus what work is then GPL (which goes along with the focus on refining what constitutes "distribution" in GPL Version 3). And while I've been focusing on software, documentation is also part of the picture, so some consideration may be needed there too (of course then you'll be wanting to factor in what to do with non-GPL OSS licenses, compatible and otherwise). This problem is so fun it makes my inner lawyer all giddy (although IANAL).
But Wait! There's More! A funny thing happens with GGPL tools. Because the GPL requires that programs distributed under the GPL be freely licensed with regard to patents, patent holders must decide to freely license the relevant patents in order to use the tool with protected code. You say companies with big patent portfolios will never use a tool with this sort of "patent shredding" license? Let me tell you a story about a boy named Richard and an idea called "copyleft". It all started twenty years ago...
Posted: Sun - January 23, 2005 at 07:09 PM | |