Tag: Software licenses

WordPress plugins and themes do not have to be GPL since the court ruled that APIs are not copyrightable

preface:

  1. I don’t like GPL, I think that for most places that it is being used at, especially in wordpress, the BSD license would have served as well and would have removed the illusion that just by selecting a restrictive license your code becomes less prune for IP theft.
  2. Matt Mullenweg created a great product and succeeded to maintain a great community around it. So far his insistence on GPL everywhere haven’t really hurt either of them and maybe actually strengthened them.

It seems like once a year there is some form of debate about wordpress, GPL and whether people might develop software related to wordpress which does not use a GPL compatible license. This time it is about whether people selling themes/plugins under split license (one for code and another for styling) should participate in wordcamps.

Maybe it is time to take one step back and ask again whether themes and plugins have to be GPL compatible.

The legal base for the claim is this legal opinion from James Vasile of the Software Freedom Law Center. There are two things to notice

  • By law a lawyer have to help his client to present the best legal case for his objective. If I had the money I could find 10 lawyers which will contradict every second word in that post.
  • After many bold claims the last paragraph backtracks from it all

    Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.

But the most important thing to know about lawyers opinions is that they are always not much better then a guess and only the court can actually decide what is the correct legal interpretation of a legal situation. Lawyers can “guess” much better when there are precedences, but there where no court cases revolving around the nature of derivative work similar to wordpress plugins and themes that I know of (and I’m sure the lawyer would have cited them if he was aware of any).

Well, in may 2012 there was a ruling about a similar issue, whether API is copyrightable.In the legal battle between Oracle and Google about the use of java derivative in the android OS. Oracle claimed that just because Google implemented the same API that java has, without a license from Oracle, it infringed on its copyright. This claim was dismissed in court, but it has more to it then that, and according to the report the judge had set a limit to when a derivative work do not inherit the license of its origin.

Ninety-seven percent of the source code in the API packages is different; it’s only the three percent that overlaps that formed the heart of Oracle’s copyright claim. That three percent included packages, methods, and class names. But those declarations—like starting a function with package java.lang—can only be used in certain ways. “In order to declare a particular functionality, the language demands that the method declaration take a particular form

Therefore claiming that just because some lines of code are similar in all themes to the GPLed themes provided as part of the wordpress distribution as Mark Jaquith says

If that argument doesn’t convince you, then note that the vast majority of themes derive from the original WordPress core themes. How they load different PHP subfiles, loop through posts, and get and interact with WordPress data is all covered by the original WordPress core themes, which are explicitly GPL

Doesn’t hold water unless there is some different way to use the wordpress API, which there isn’t. Big part of the PHP code in many themes is identical because there is either no other way to perform a specific functionality, or it is the best practice.

In my opinion the wordpress foundation (or wordpress.org or whoever is talking for wordpress) might have a right cause, but they win the fights because they have bigger sticks, and not because the law is on their side.

CodeCanyon rejected my plugin because it was too simple…

Preface: I have no problem with CodeCanyon, or being rejected. The guys running CodeCanyon know much better then me how to run their business, and if they rejected my plugin they probably thought it will not sell, at least not in the amount worth their trouble.

I submitted my simple google authorship and avatar plugin to CodeCanyon to test if it is possible to make money from developing and selling general purpose wordpress plugins. Hoping that with proper coding and documentation I might be able to get some more money every month without having to talk/convince/argue with clients which is the most stressful part of being freelancer.

The plugin was designed to be simple (as the name implies 😉 ) in two ways

  • For the user – simple to use, as I want to reduce the amount of time I might need to spend in answering questions about how to use it
  • For me – simple to code and maintain as it was a test in which I didn’t want to commit too much time because I had no idea what will be the return on the time investment.

Of course simple is too often confused with trivial, and this plugin wasn’t totally trivial as I had to create a proxy server for it to be able to easily access data by using google API.

I estimate that it took me 5 days to write the plugin including research, coding, QA and documentation. I charge at least 50$ per hour for freelance work and assuming I worked 8 hours a day my time investment into creating the plugin was worth about 2k$. Even before starting coding, when I just decided on the scope of the plugin I knew there was little chance that I will sell enough of it to return the development effort.

The rejection letter suggested that I will add more meat to the plugin. For me it was wrong in two ways

  • The google API I used, accessed publicly available information from the user’s google profile and therefor required only “read” permission which I assume users will be more likely to give. The plugin already utilized any aspect of the specific API and there is just nothing else that can be done with it. Adding functionality from other APIs is possible but then I will most likely end up with two functionality, each deserving a plugin by itself, forced to live in one plugin just to make it sellable
  • I already invested 2k$ worth of my time into this, and I’m totally not convinced that if I invest another 2k$ I will have a better chance of earning 4k$ in reasonable time. I lost ( a little imaginary) 2k$, no point in being in the position of losing 4k$.

The thing is that I might do much better by releasing the plugin under the GPL license into the wordpress plugin repository. Since the documentation can be bare bones and I am not required to support the plugin if I don’t want to, the development cost is lower and I might get better money from donations or requests for modification (realistically neither will happen but no one guaranties minimum amount of sells in codecanyon as well). In the minimum it will increase my reputation as a wordpress developer.