17 July 2010 ~ 3 Comments

Forcing plugin developers to adhere to the GPL


The war of words over whether or not a plugin constitutes a derivative work of the parent GPL’d program has heated up again over here and here.

I don’t want to start another debate on the same topic. What I do want to do is come up with a way to guarantee that plugins adhere to the GPL by forcing them to do so with the architecture of the plugin system.

One idea that I had was to somehow force plugins to copy code from the parent program into the plugin itself in order for it to work. On the simplest level, this could be something like a driver type of file that the parent program checks for the existence of, and which contains base classes or something similar that must be extended in order for the plugin to properly hook into the main program.

I have not thought this through completely, so please post your feedback or your own ideas.

Tags: ,

3 Responses to “Forcing plugin developers to adhere to the GPL”

  1. Mike Schinkel 17 July 2010 at 4:49 pm Permalink

    FWIW, I had exactly the same thought as a way to resolve this issue. I was thinking about themes but it would (should) apply to plugins too.

  2. saulgoode 18 July 2010 at 7:14 am Permalink

    One of the problems that needs to be overcome is that it has become somewhat of an institution in the software world that exposing an API amounts to a de facto invitation for third parties to interface with the program, with the preconception that such interfacing should not result in an infringing derivative work. This certainly makes sense for closed source programs or frameworks — why would you even publish an API unless you expected third parties to code to it?

    Closed source systems also have a ready way of controlling use of their APIs through separately licensing terms for SDKs (software development kits) which are often little more than some header files and wrappers around functions within the main framework. With the open source nature of Free Software, all APIs are exposed and this seems to have resulted in the presumption by some people that interfacing through those APIs should, likewise to the closed source case, be free from concerns of infringement. Personally, I don’t agree with this presumption, but there are several decades of momentum behind that viewpoint and it is uncertain how any particular court would ultimately rule if the issue came to trial.

    Given this, one of the best ways I can think of for a Free Software developer to highlight that they consider their API “private” (and its use covered by the GPL’s reciprocity terms) is to explicitly provide a “public” API (which can be used without triggering the GPL’s derived works coverage). This is effectively what the Linux developers have done with their “normal system calls” exception and the GPL_ONLY symbol kernel tainting. It is also what is implicitly suggested by the GPL’s FAQ when speaks of ‘forking’ and ‘exec’ not triggering derived work issues.

    So what I am saying is nothing new, though I think that projects which care about this issue should forgo the technical jargon and realize that the audience that ultimately will matter is the judges and juries which decide infringement cases.

    Imagine how much more clear it would be to stand before a judge and, rather than explaining the nuances of dynamic run-time loading or language-specific class inheritances, saying, “My program allows the fonts and colors to be changed with a configuration file, it provides a D-Bus interface so that it can be used by other programs, and it includes a LUA interpreter so that some operations can be scripted; however, I consider any interfacing to my code beyond these methods to be protected under copyright law”.

    • Marshall 18 July 2010 at 8:08 am Permalink


      Thank you for the very thorough comment on the issue!

      I had not heard of the GPL_ONLY method that Linux implements. I am going to look into that and see if there is a way to apply the same or similar strategy to a scripted language like PHP/Python/Ruby etc.

      I think there are two types of plugins. Applications that can run standalone and are augmenting the features of the parent program, and applications that are useless without the parent program.

      The former could write an adapter plugin that would be GPL, while the original program would remain “safe” from GPL. The latter would be GPL, because the entire reason it was created was to extend the parent program’s usefulness.