GPL enforcement – definitive answer?

rg4w
(@rg4w)

10 years, 4 months ago

I apologize in advance for bringing up yet another thread on the GPL question, but it seems somewhat unresolved so I’m hoping to find a definitive answer here:

The WP team has made clear their preference that all themes and plugins be governed under the GPL, on the grounds that linking to an API constitutes a derivative work.

Yet we see non-free software on Linux which use Linux APIs, as just one example of a contrary interpretation.

In researching this issue, I’ve not been able to turn up a definitive case in which the courts have ruled that the sort of linking done between a theme or a plugin and WP itself constitutes a “derivative work”.

Indeed, the Posner ruling in Oracle v Google would seem to suggest (at least to this layman) that APIs are not protected by copyright.

If there is a case where the court has decided in favor of WP’s interpretation of linking being protectable under copyright rules, any URLs to the court records would be appreciated.

Such an outcome, however, would have significant consequences for developers of commercial themes and plugins: anyone could set up a site redistributing those at any or no cost, thereby removing the original developer from the revenue stream. Does such a site exist already?

It may also call into question the legal status of any non-free software running on Linux.

If on the other hand there is no court ruling favoring WP’s interpretation of linking, the door remains open for plugins and themes distributed under proprietary licenses, which has its own downsides to the community in muddying the waters with regard to what’s allowable and what’s not.

A little background on my interest may be helpful:

I’m asking this because I publish a proprietary software for which many of my customers have requested a WP plugin. I’m keen to satisfy their requests, but am reluctant to do so under the GPL with this particular product because its current proprietary license works well for its business model.

I also contribute to some FOSS projects, and help organize a part of our local Linux expo, so I’m very supportive of the GPL for projects where it’s a good fit.

While my interest stems from one specific use case with my product, rather than explore possible options for handling that one case (linking to more permissive GPL-compatible intermediary files seems to be a common gambit), in the interest of the community as a whole it seems more helpful to seek an answer the broader question of whether linking is protectable under copyright rules.

Any guidance on this issue would be appreciated. I’m sure many others would also find it refreshing to have more clarity on this.

Viewing 12 replies - 1 through 12 (of 12 total)

catacaustic
(@catacaustic)

10 years, 4 months ago

anyone could set up a site redistributing those at any or no cost, thereby removing the original developer from the revenue stream

Yes, that is possible, and legal. For an example, check out how Woo Commerce came about by forking Jigo Store. The GPL allows this, evne though your own personal ethics may cast some doubt in on if it’s a good idea or not.

Honestly, unless you talk to a lawyer that knows their way around copyright and licencing, any advice that you get on here is pretty much conjecture and cannot be taken to be anywhere near legal or binding.

Thread Starter rg4w
(@rg4w)

10 years, 4 months ago

Honestly, unless you talk to a lawyer that knows their way around copyright and licencing, any advice that you get on here is pretty much conjecture and cannot be taken to be anywhere near legal or binding.

Understood. I was hoping for a link to something from WP,org’s counsel. Ending conjecture would seem to be in the interest of the entire community.

catacaustic
(@catacaustic)

10 years, 4 months ago

http://wordpress.org/about/license/

That’s about the best that you’ll get, and I’m sure that you’ve seen that one before. That does spell out what WordPress thinks about it, and lets you read the details of the licence. Maybe a mod can give some more ideas, but I doubt that you’re going to get a definative ansewr for your particular case as that’s particular to you, and is something that a real legal counsel would need to look at.

Moderator Samuel Wood (Otto)
(@otto42)

WordPress.org Admin

10 years, 4 months ago

The WP team has made clear their preference that all themes and plugins be governed under the GPL, on the grounds that linking to an API constitutes a derivative work.

No, WordPress plugins and themes directly use the WordPress codebase and make direct function calls into that code. They do not use an “API”.

Realistically, a lot of the documentation we use is misusing the term “API”. What WordPress docs and devs often call APIs are really just related sets of functions and/or classes in the core code. Plugins and themes are directly loaded in the same way WordPress’s own code is loaded.

Moderator Samuel Wood (Otto)
(@otto42)

WordPress.org Admin

10 years, 4 months ago

I’m asking this because I publish a proprietary software for which many of my customers have requested a WP plugin. I’m keen to satisfy their requests, but am reluctant to do so under the GPL with this particular product because its current proprietary license works well for its business model.

If your product is separate from WordPress, then it cannot be a derivative work. The plugin that interconnects the two might be, but it doesn’t necessarily transfer any licensing requirements onto your own separate work. Plugins to connect two different systems exist and as long as that plugin is GPL, we’re good. Your software can be whatever it wants to be.

Chip Bennett
(@chipbennett)

10 years, 4 months ago

The current stance of the WordPress Foundation (WPF) stems from a letter written by FSF counsel, and not on any precedent case law. I believe you are correct, that the question of WordPress API usage versus actual code incorporation has not been challenged, much less settled, in court. In fact, from my own research, I agree with you.

That said: whether you choose to develop a Plugin distributed under a proprietary license is one that only you can make, based upon your own counsel and that of your attorney. The potential risks you would incur include both a potential legal challenge from WPF, and certain exclusion from the WordPress “community” (an ephemeral term, but certainly including the WordPress project; the WPORG website, Plugin/Theme directories, and support forums; and WordCamps). Whether those risks are sufficiently countered by any rewards is a decision that only you can make.

My personal opinion is that you have the right to weigh that risk and reward, and make the decision – but at the same time, the WPF and WordPress community have the right to make policy decisions regarding whom will be included in that community based on licensing.

I don’t personally like the policy, because I believe it is based on a faulty legal interpretation unsupported by precedent case law; and I believe that business owners should retain the freedom to use the business model that best suits them. No business model works in every circumstance, including a GPL-based business model.

But I’m in the fortunate position of it not mattering for me personally. I don’t have any pre-existing code or business models that might be impacted by moving to GPL. I’m happy to distribute any code I write under GPL, regardless of the correct legal interpretation of a derivative work, because it’s all written as a contribution.

That said: even in your case, there may be workarounds. Is your application such that you can set up an API or SaaS solution, where the WordPress Plugin merely acts as an API client wrapper?

Thread Starter rg4w
(@rg4w)

10 years, 4 months ago

Thank you all for your input thus far.

Samuel Wood (Otto) wrote:

No, WordPress plugins and themes directly use the WordPress codebase and make direct function calls into that code. They do not use an “API”.

Realistically, a lot of the documentation we use is misusing the term “API”. What WordPress docs and devs often call APIs are really just related sets of functions and/or classes in the core code. Plugins and themes are directly loaded in the same way WordPress’s own code is loaded.

This sounds very much like an application programming interface. How does it differ from the way applications make use of functions in an OS?

Forgive my naivete, but I have no experience writing WP plugins yet.

Thread Starter rg4w
(@rg4w)

10 years, 4 months ago

Thanks again to everyone who’s contributed here, esp. Chip Bennett (I actually read all of the comments at the post you linked to – very interesting discussion).

After further reading around the Web I’ve come to see a possibility for clarifying WP’s License page which may put this issue to rest:

It seems it’s a common practice among theme devs and some plugin devs to use WP example code as a starting point for their work. In such cases, it’s not so much the names of WP functions being called that are the issue as the actual code blocks that use those functions which were originally written by the WP team.

In such cases, obviously any use of other people’s GPL code inherits the rights and responsibilities of the GPL, so no question there.

However, if a plugin is written entirely from scratch, so that it includes no code from WP per se but merely calls API functions that are defined in WP, then the situation is very much like applications written for Linux, which make calls to the kernel but do not include kernel code.

The most common interpretation of making function calls in the FOSS world holds that merely calling APIs does not constitute “derivative work”, and if the WP License page were augmented to clarify that this issue may well go away.

If instead the official stance of WP’s counsel were that even just making function calls to the API constitutes “derivative work”, much of the FOSS community, and chiefly desktop Linux, may find itself at risk:

Desktop Linux is a viable option in part because of the support of third parties who write proprietary code for the platform. Regardless of whatever preference we may have for truly free-as-in-freedom code, we accept that the support of companies like AMD, IBM, Intel, NVidia, Google, Valve, and others helps provide a healthy ecosystem of drivers and applications that range from enjoyable to essential.

Even on the server, Linux sometimes benefits from proprietary code, such as some Oracle database drivers.

If a court were to favor the position that merely using an API constitutes “derivative work”, many third parties not in a position to license their code under the GPL would be forced to abandon Linux.

There may also be a corollary issue affecting FOSS apps on Mac and Windows, in which questions are raised about whether GPL’d apps can be compiled with API calls to non-free OSes without invalidating their own GPL license, as they would no longer be seen as comprised of completely free code.

Given their clearly-stated preference for truly free code I’m assuming that everyone on the WP and Drupal teams use Linux, and I’m also among the many millions who rely on Linux in our businesses. So with this uncommonly broad interpretation of API use as “derivative work”, whether or not we pursue development of WP plugins I and millions of others still very much have a horse in this race.

So in short, I believe it may be useful for GPL-governed projects to reach a common interpretation of whether API use constitues “derivative work”, and for the sake of a useful GNU Linux I would favor an interpretation that they do not.

If the WP and Drupal teams were to amend their license pages to draw a clear line between including GPL’d example code (which would inherit GPL responsibilities) and merely making API calls within original code (which would not), the benefits would be many:

– WP and Drupal third-party devs would have clarity about which types of use would require GPL licensing.

– WP and Drupal end-users could select third-party components with confidence that they either reflect their preference for truly-free code, or at least are not just one lawsuit away from having a favorite proprietary plugin pulled out from under them.

– WP and Drupal’s apparent position with regard to API use would no longer pose a threat to the Linux community, bringing a greater consistency to GPL interpretation across nearly all FOSS projects.

Of course all of this is predicated on my understanding that it’s the API use that is the central issue here. If that understanding is incorrect I would appreciate any clarification on what the central issue actually is.

Thanks in advance for considering this.

Moderator bcworkz
(@bcworkz)

10 years, 4 months ago

Samuel Wood (Otto) wrote:

No, WordPress plugins and themes directly use the WordPress codebase and make direct function calls into that code. They do not use an “API”.

Realistically, a lot of the documentation we use is misusing the term “API”. What WordPress docs and devs often call APIs are really just related sets of functions and/or classes in the core code. Plugins and themes are directly loaded in the same way WordPress’s own code is loaded.

This sounds very much like an application programming interface. How does it differ from the way applications make use of functions in an OS?

The fundamental difference is “Plugins and themes are directly loaded in the same way WordPress’s own code is loaded.” An application is loaded and executed by a user. The application makes API calls into the OS. In the case of WordPress, the user, by way of a HTTP request, loads and executes WordPress code, not plugin or theme code. WordPress in turn loads and executes the plugin and theme code, not the user. Plugin and theme code may or may not in turn make function calls into the WordPress code base. This is very much unlike an API. APIs do not make calls to your code.

Plugin and theme code from the perspective of the PHP parser is the at same level as any other WordPress code. Typically, API code is at least conceptually at a different level than the code calling it, even if at the processor level there is no difference.

Themes and plugins are much more like extensions of WordPress code. WordPress is not acting like an API to the primary application. It is the primary application. Calling it an API is not a valid analogy even though the term appears (inappropriately) in documentation. The publishing of extension code is more likely to be considered a derivative work than code making use of an API.

I personally do not consider plugin or theme extensions derivative work, but it does not matter what I think. I have no official standing and do not speak for anyone but myself. I don’t see any problem with a GPL licensed extension interfacing with proprietary code, probably through an API no less! The plugin extension is useless without the proprietary component, yet it remains functional as far as it goes. Much like a browser with no Internet connection is fully functional but rather useless.

Chip Bennett
(@chipbennett)

10 years, 4 months ago

Plugin and theme code from the perspective of the PHP parser is the at same level as any other WordPress code. Typically, API code is at least conceptually at a different level than the code calling it, even if at the processor level there is no difference.

Precedent case law makes a distinction between derivative code, which requires actual code incorporation, and dependent code, which would be the case here. Code linking/combination happens by the user, at the time of execution by the PHP parser, and under any case law I have been able to find, does not constitute incorporation of code from one into the other, and therefore does not cause the dependent work to be derivative.

What the GPL defines as a derivative work and what FSF defines as a derivative work are entirely irrelevant, if those definitions contradict what the Copyright Act and precedent case law define as a derivative work. That is the case here: precedent case law clearly states that a derivative work requires actual code incorporation, and further clearly states that mere function calls do not constitute actual code incorporation – though if anyone can find any case law to refute Galoob v Nintendo, Sega v Accolade, and Sony v Connectix, I would gladly consider it.

Chip Bennett
(@chipbennett)

10 years, 4 months ago

don’t see any problem with a GPL licensed extension interfacing with proprietary code, probably through an API no less! The plugin extension is useless without the proprietary component, yet it remains functional as far as it goes.

Yes! I believe this is the same point Otto made previously, and the same thing I suggested above: create a GPL-distributed WordPress Plugin, that interfaces with the proprietary code through an exposed API.

Thread Starter rg4w
(@rg4w)

10 years, 4 months ago

Where in the text of the GPL 2.0 license is the definition that distinguishes between how PHP files comingle code in memory and how applications and the Linux kernel comingle code in memory?