You might wonder: Source for wordpress – it’s already there, right? So what are you asking for hakre?

That’s why I clearly wrote upfront in the ticket that source-code is mostly available – but there are places for which not. Which has been confirmed by others in that ticket quickly.

However, this question made Otto (ottodestruct.com/Otto42), who plays an important role for the wordpress.org site, share a view about licensing worth to quote.

I think this deserves a special mention, not because of incompetencies (we all have them), but because it shows licensing attitude and can help to understand dissent and difficulties:

Firstly, the only binary file I can find any reference to is SWFUpload, and that is MIT Licensed, not GPL. The MIT License has no requirement for providing source code.

As for the GPL, we [the wordpress project] are under no obligation to provide anything at all. [emphasis added] Understand that the people here wrote the code and share a joint ownership of it. The GPL places no obligation whatsoever on the actual copyright holders of the code. They can release it anyway they like. The GPL only applies to licensees of the code in question; the downstream people using and redistributing that code.

There is no requirement for WordPress to release the source code for a single binary file which they did not write and which is not GPL licensed to begin with. [emphasis added] [...]

Otto; 16 Feb; in answer to “Whom to ask for missing wordpress source-code?” (Source)

I could not believe to read these words. To read this from a person who is important for the website dedicated for distributing the package is hurting me as both – a user and a contributor.

That is especially in the context of asking for source. It could have been any user that is asking that question.

I as a developer make use of the GPL to ensure that users of my software will get the freedom they deserve.

Even hours later I have problems to find words, back in October last year I wrote: this deserves a special mention.

Looks like it still stands.

Opinions vary among each other

But more importantly, the question of the ticket still needs to be answered.

I’m confident, that the WordPress project will distance itself from anything close to such statements and instead will offer sources for the packages. As the simple fact to not offer sources has licensing implications.

Another important suggestion still stands: The wordpress team should pro-actively take care of licensing. E.g. by getting some professional legal or otherwise useful consulting or help from outside. Like getting in contact with the SFLC as Matt Mullenweg did when he needed help with theme licensing.

You can find some documentation about known licensing issues on a codex wiki page of mine.

This conversation is still ongoing and started after he published an article on the WordPress development blog about the change in the WordPress licensing and my posting about that.

As a first result, I’m happy to write with the best knowledge of both – the WordPress project and me – that b2/cafelog code is licensed under GPL with no version restrictions.

This might not sound as news as this has always been the licensing terms of the b2/cafelog.

But after I got in contact with Mark it was first not clear to say which position the WordPress project was taking: b2/cafelog being technically licensed under GPL, GPL v2 or GPL v2+.

In emails over the past days we could finally clarify that point and both agreed that b2/cafelog is licensed under the GNU GPL – not version restricted.

This is an important point as WordPress is a successor of b2/cafelog and if there would have been a technical version restriction to version two of the GPL, it would not have been possible that easily to upgrade or convert it to GPL v2+ for now.

Conflicting Looking Code

So what could be said about the cause of the former dissent? Probably this:

The whole code is centrally marked in the package’s readme file being GPL, but one function was causing uncertainty as it was marked as GPL v2.0. If so, this would have technically conflicted with the non version restricted GPL licensing terms of the package.

I always argued based on the licensing terms given, that b2/cafelog and therefore WordPress was licensed under GPL.

The function written by Leonard Lin in 2001 is called balanceTags. The author wrote last year in august, that All code licensed under the GPL (any version) and further on:

I’ve put this up for posterity and also from a request by the WP team to relicense the code as GPL (instead of GPL 2.0).

As Lin continues, he contributed the code to the b2/cafelog project.

As it’s visible, it was always safe to use the code of the balancetags function under the terms of the GPL with no version restrictions.

Résumé

Good to see the dissent could be removed again for b2/cafelog as well. This makes the situation more clear for users of the code and they can have some trust in the licensing terms given by the package. Additionally, I had not wrote in detail about that function so far, so it’s a nice addition to my series.

Hopefully I’ll have some more good news in the upcoming weeks, the discussion has come to a point where it starts to look more promising to me.

(My blogging back those days: WordPress Licensing Issues – Progress (Day 5), the related changeset is [15536], the issue is related to ticket #14685)

WordPress contains libraries only available under the GPL v2 or later. No one cares about the GPL v1 anymore. We are now specifically saying that WordPress is available under the GPL version 2 or (at your option) any later version. This was discussed with the entire core team.

Next to the changeset in the wordpress core package, the text of the of the wordpress.org licensing terms has been changed.

The change done by Mark Jaquith is promoted as “Clarification in Licensing Language”. He explains that in an associated blog post.

In that post he is talking about licensing problems that result from the fact that wordpress has been using GPL version restricted library code (as it is the case for the KSES library which terms have been technically violated) while the package was not version restricted.

The core team wants to solve the issue now by distributing worpdress under GPL v2 or later which is matching the libraries own version specification.

The debate about the GPL version came on topic in August 2010 when I made a change of the GPL version in Februrary more prominent. That time it was a change from GPL to GPL v2 done by Andrew Nacin which got reverted after my report by Mark Jaquith in the end.

The worpdress copyright and licensing terms were subject to change a few times in the past.

Read On: WordPress License Clarified – Weblogs Tool Collection (16 Jan 2011; by James Huff)

Follow Up: CiviCRM and WordPress (28 Jan 2011; by hakre)

* Spell out that the license is GPLv2

Well, even that this is actually giving some license information (the Hello Dolly plugin still remains silent about it’s license), I see some possible implications this change might have.

The Akisment plugin is not developed by the WordPress project but by Automattic, Inc. That just for some information upfront for those who don’t know. It is the only code wordpress ships with, that is not part of the project’s source code repository.

The more important part is, that even it is not developed within the project, it gets automatically bundeled into each wordpress software package. Either you get it manually from wordpress.org or via the auto-update. Because of the incorporation, the license change went into the wordpress package and finally out with wordpress 3.0.2 on November 30 2010.

The problem is, that WordPress itself does not limit the package to a specific GPL version, and so didn’t the Akismet plugin before that change. There was some dispute about the version of the GPL licensing, which had been resolved by not naming the GPL version number by the project.

WordPress 3.0.2, a mandatory security update for all previous WordPress versions, did not announce such a change in licensing.

Previously in the Hello Dolly Plugin code copyright issue WordPress core developers have argued, that plugins, as being part of wordpress, are under the same license as wordpress. Hello Dolly next to Akismet is a plugin with the special state to ship with wordpress by default.

I didn’t made up my mind about this issue a lot as it’s new years day (and to be honest, I didn’t wanted to go into the topic that fast again), but from the little I can see, it looks like this should be clarified so not to put more constraints to the licensing issues that are already visible. If the project puts code into the project (or let’s it get put), it should ensure that this is not calling for problems.

If the wordpress project that bundles this plugin has questions regarding software licensing and how to prevent such problems, I’m happy if I can be of help to improve the situation. As I just did with helping finding a solution for the WordPress GPL Violation in kses.php.

Additionally I’d like to understand why there was actually a need for the Akismet developers to introduce that change and what they think which kind of implications this has or has not with the wordpress package. Having more information at hand might help to find a solution that is pleasing everyone.

Happy new Year.

Update: I now checked the wordpress license regarding incorporating otherwise licensed works and verified that 3.0.2 was the first release in version conflict. Reported in Ticket #16100.

Update 2: In reaction to the report, Joseph Scott from Automattic has changed the licensing of the plugin to GPL v2+ and has reinstated usage rights for the older WordPress packages. However, the new licensing will only become visible when the next version is going to be released.

Update 3: Akismet today made the new release with the GPL v2+ licensing.

Previous: Kses, GPL, Copyright, Licensing and Disclaimer
Next: WordPress changes GPL license text again
Series: WordPress Licensing Issues

The current wordpress security release made me look into kses.php today. But my review ended before going over the first 10 lines already.

Guess what I ran over? Jup, another wordpress GPL license violation. How did I find it? It popped into my eyes that no licensing information was given. As it is an external library file, this made me curious as normally external files have those. I checked it against the original sources. And sure, it has legal comments on top of the file:

<?php

# kses 0.2.1 - HTML/XHTML filter that only allows some elements and attributes
# Copyright (C) 2002, 2003  Ulf Harnhammar
#
# This program is free software and open source software; you can redistribute
# it and/or modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
# more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA  or visit
# http://www.gnu.org/licenses/gpl.html

As you can see, the file is released under the terms of the GNU GPL. But if you look into the file in your wordpress directory, it tells some other story. This is the beginning of the kses.php file in wordpress:

<?php
/**
 * HTML/XHTML filter that only allows some elements and attributes
 *
 * Added wp_ prefix to avoid conflicts with existing kses users
 *
 * @version 0.2.2
 * @copyright (C) 2002, 2003, 2005
 * @author Ulf Harnhammar <metaur@users.sourceforge.net>
 *
 * @package External
 * @subpackage KSES

As you can see, the original legal statements were removed. Only some copyright related information has been preserved in PHPDoc comments which are not fitting anything useful when it comes to copyright. They can help for automated analysis and that’s it.

How about not giving the legal notices the way it is (not) done in kses.php in wordpress?

It is no secret that WordPress Core Committers are against having legal comments in files (Via). But that does not mean that the GNU GPL is ducking away when copyright notices and license statements are tainted. Infact, the license is pretty clear about those legal comments. Let’s actually read the license, I quote from version 2 here:

1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

So if you want to copy GPLed code, you must retain the important legal information that you normally find at the very top of each file in form of a PHP comment. The License wording is pretty clear. If you don’t go conform, you don’t have the right to copy.

And that is even for verbatim copying only. The developer of WordPress.org did not only copy the code, Matt Mullenweg as he pulled the code in, was in fact creating a derivate of kses. WordPress is a derivate of kses. You can compare that with the plugin situation: wordpress extends from kses as it uses the functions of that file within other files.

Next to creating a new work based on kses, multiple developers have modified the code and extended it a bit over the years. Fixed stuff, added functions and all that. Everything we like in free software development. The interchange and the work in a community. Normally you expect the rights to use, copy, modify and to redistribute modified versions of a software that is available under GPL. But these rights come with conditions so to protect the freedom. Let’s take a look into the license again:

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above [...].

That means, that for modifying the code and to copy it and redistribute the modifications, the terms of Section 1 above need to be fulfilled as well. So all the rights we normally expect from a GPLed software are not granted if you remove the copyright statements, the licensing information or the disclaimer. And that’s really useful, otherwise the software’s users won’t know about their rights. But the knowledge is important to preserve the freedom of use.

Consequences

So now after it’s clear that removing such is a serious licensing issue, what does this mean? The GNU GPL v2 license text is dealing with it in §4:

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

The GPL has protection build-in: In case the conditions are not met the rights to copy, modify, sublicense or distribute the program are void. They automatically terminate. This means, that the software still is licensed under GPL, but the GPL is not granting any rights. Instead, the copyright holder is back in full power. The user, here wordpress.org, has lost all rights by attempting to sublicense the file within their own software package.

What does this mean for all users who downloaded the software? The violation of the GPL for this case dates back to christmas 2003 that’s as far away as one alpha version of WordPress 1.0. Not a nice christmas present, right? Well it just means, as wordpress.org didn’t have any rights to redistribute kses, the download is legally spoken problematic. As you can not gain any rights from that piece of software any longer, you would literally need to build your own software from properly licensed GPLed sources.

As you can imagine these cases can be pretty hard to deal with. The best thing is to get in contact with the original copyright holder and politely ask if he or she is willing to re-instantiate rights again and under which circumstances. This is necessary as the rights are automatically terminated. So not contacting the copyright holder but putting the legal comments back in does not solve the problem. WordPress.org would have still lost the right to make use of the code.

Gladly in this case, Ulf Härnhammar, the orginal author of kses has offered to allow the use again if certain conditions are met. A friend notified him about the case:

I grant WordPress the right to continue to use the kses library under GPL v2 or later, if you put back the Copyright and Disclaimer information at the top of the file.

Now that’s a statement that made me upload some patches. So the only thing left is actually wordpress comitters to apply them and do a release to give this year some happy ending.

Ticket #16039: Copyright Problem: Original Copyright Statement, Licensing Information and Disclaimer removed from kses.php

Previous: WordPress, Copyright, Hello Dolly Lyrics, the GNU GPL and I
Next: Akismet Introduces GPL Version to WordPress
Series: WordPress Licensing Issues

Image Credits: The Cardsharps, ~1594, by Michelangelo Merisi da Caravaggio

I think it’s about time that I name why write about the issue:

As you can see, there are valuable collective and personal interests that I share with the issue and other members of the community.

But there are different approaches which tend to look irreconcilable as well.

Chip Bennett is fully right. I’m passionate.

But we only get one step further with this matter, if we deal with disagreement.

Happy Holidays

Previous: WordPress Licensing Issues – Plugins are GPL, Right?
Next: Kses, GPL, Copyright, Licensing and Disclaimer
Series: WordPress Licensing Issues

If you thought that the wordpress package you can download from wordpress.org is re-distributable under GPL, then you’re thinking wrong. Why do I say so?

Thanks to a ticket opened by novasource, it came to my attention, that the Hello Dolly (WordPress Plugin) contains copyrighted material which is highly likely not available under nor compatible with the GPL. The Ticket is #15769. And that’s causing real headaches, because it is a very special plugin: It is always bundled with wordpress.

GPL has Protection Against Incompatible Code Built-In

So what is the problem if some plugin contains code that is not available under or compatible with the GPL?

To get a software conform with the GPL, add-ons (e.g. plugins) not written by the user need to be distributed under the GNU General Public License as well. Otherwise, and that’s by nature of the GPL, the rights of the GPL license of the main code automatically terminate for the whole work. Users who have already copied the software package under the terms of the GPL, can make use of the rights of the GPL only, if they are in full compliance (refer to §4 in GPL v2).

To give a practical example: You have downloaded a wordpress package from wordpress.org over the last years. Either manually the zip file or by using the auto-update. You didn’t know that what you downloaded was restricted and violating the GPL because it was announced as being GPL licensed and you had trust in that statement on the homepage. If the hello dolly plugin is actually restricted and therefore not GNU GPL compliant, this would destroy the GPL compliance of the whole wordpress package.

As the usage-rights under the GPL terminated, you most probably made a download without having the legal rights to do so. That’s possible because wordpress itself is a fork of b2cafelog which was released under GPL and because it contains copyrighted work from hundreds of developers that license their code to wordpress.org under the terms of the GPL.

Thanks to novasource it is now more publicly known that the Hello Dolly Plugin probably violates the GPL.

(This might not be the full truth. While removing the problematic part seems to be a good idea, you might as well need to contact the original copyright holders of the software and negotiate with them what you must do to be able to license and re-distribute the software under GPL. See 5.2 Termination in [1])

Enter Meta

So far for the legal licensing implications this can have. IANAL, but that are merely the bare facts and any lawyer you can consult should be able to give you proper legal directions about downloading software from wordpress.org. Ask for one that actually knows a bit about the GPL (next to copyright).

Next to this basic stuff, there is the meta-level.

Can you imagine a project in which such an obvious potential license violation and copyright implication got unnoticed and undiscussed for such a long time? We’re talking about more than 7 years that have passed since the problematic code is part of the wordpress package. In publicly view- and available source code.

This fact just speaks for it’s own.

Licensing issues are not really taken care of as long as it’s the wordpress core. Core developers often defend themselfes against such a statement to prevent correcting changes as they write “everything” is already in order. I can only tell from my own experiences that each time something license related pops up, you needed to push a lot to get things starting with an unknown end. This Hello Dolly case seems to be no exception.

But different is, that it has the best ingredients: It’s a plugin and the author is Matt Mullenweg himself. Which is the owner of the wordpress.org domain. The plugin is exceptionally distributed with the worpdress software package from that domain. So the author is offering the package (incl. the plugin). And next to that the Hello Dolly plugin is a single plugin available in the wordpress.org plugin repository with a set of rules on their own. For example plugins must be compatible to the GPL.

Matt Mullenweg licensing wise was more concentrating on plugins and themes in the past then with the core code. So great to have a plugin of his own as an example now. In the best sense, a “Eat your own dog-food” situation.

It’s great to see how such a possibly best imaginable licensing case just turned up.

Reflections

So for me the most interesting rhetoric question is: Is the project dealing with the same strictness regarding the GPL and plugins when subject is a plugin of a former core developer?

And the most interesting legal question for me is: Did Matt Mullenweg as the author of the plugin acquired rights to redistribute those Hello Dolly Lyrics under the terms of the GPL seven years ago?

Links

• Ticket: Ticket #11538: Unbundle Hello Dolly – Report about the copyright problem.
• Ticket: Ticket #15769: WordPress ships with copyrighted “Hello Dolly” lyrics which could potentially terminate the GNU GPL of the package
• List: Licensing and Copyright Issues with the Hello Dolly Plugin ([wp-hackers] mailing list)
• Downstream Ticket: Bug #607240: wordpress: Copyrighted song lyrics included in the source code (Debian)
• Downstream Ticket: Bug #692252: Copyrighted song lyrics included in the source code (Ubuntu)
• News: WordPress Accused Of Copyright Infringement For Its Famed ‘Hello Dolly’ Sample Plugin (by Mike Masnick; 17 Dec 2010)
• News: Is Hello Dolly A Copyright Infringing Plug-in? (by Jeff Chandler; 20 Dec 2010)
• Copyright: Hello Dolly & 3 other titles; notification (under 17 USC 508) (faqs.org / copyright)
• Info: About Hello Dolly (in WordPress for Dummies page 213)
• Info: Hello, Dolly! (song) (wikipedia)
• Poll: Goodbye Dolly? (Take the poll!) (by Jeff Starr; 28 Jul 2009)

Previous: WordPress Licensing Issues – On Showing License
Next: WordPress, Copyright, Hello Dolly Lyrics, the GNU GPL and I
Series: WordPress Licensing Issues

Image Credits: Jüngling von einer Eidechse gebissen ca. 1593 by Caravaggio

But it looks like that there is code of second class in WordPress which does not deserve to spread the word about or to get protection by it’s license. That is the code in WordPress that is under GPL’s little sister, the LGPL license. Asking to put the license text into the package, I was confronted with absurd and abstruse arguments over the last days. Stuff like:

• “License Files are bloat”
• “Components from elsewhere are not required to have copies of the license”
• “License Files irritate Users”
• “License Files are not needed because there is a link”
• “License Files are not needed at all because the license is so popular”

That was not by a snotty little scammer who wants to cheat customers, that was by a respected WordPress regular: Otto. Otto is really acting stupid when it comes to licensing, this deserves a special mention.

But it’s not only Otto who has some questionable attitude on free software licensing. There is as well Nacin. I was not surprised he jumped on the bandwagon for the bloat and the irritation argument – if there is some stupid argument that looks like it’s doing for his interests, he takes it, regardless how cheap it is. But he also noted some other detail where WordPress codebase has licensing/copyright issues with. And because there are more issues which will not get fixed (by his opinion), this LGPL issue is not to be fixed as well. About which issues was Nacin talking here? This needs some explanation:

The GPL How-To

The folks who made the LGPL and the GPL License, the Free Software Foundation, did not only create licenses that are pretty well aiming for the freedom of the software we share. They also provide additional information on how to apply the licenses to software, a.k.a. the GPL How-To, so that the freedom is properly enforced. A kind of guide how to deal with the licenses. For such things maybe: legal protection, probably with an eye on the international differences for the freedom of the software. Generally recommendations you should consider when you’re interested in free software. That’s done best early (as most things), but at least when your package has got a certain age and grade of distribution you should take a look in there. Even if you’re not using the GPL this might be a useful read for you.

You might now think that WordPress as it is using the GNU’s licenses is actually making use of these recommendations, right? Not really. Even the codebase has a 7+ years history, it feels quite young when you touch the legal part of it. And there are a multitude of recommendations in that How-To that are not yet done with the WordPress codebase. This is mostly Copyright related which looks like a pretty weak point in WordPress but that’s another topic amongst other topics. This post is about showing the license as my motivation is to improve the situation for everybody’s good.

Make an Educated Guess.

So what happens when you confront core developers with one of the recommendations: put the license file inside the package? – Make an educated guess.

Naturally they neglect that because those are recommendations “only”, so a “should” is not a “must”. This sort of mindless argumentation might be suitable for a boolean logic thinking programmer that has problems to properly read PHP statements, but does it fit on a larger scale? I strongly doubt. I mean, do we need to declare war on the code’s license for the sake of the difference between a should and a must? Undoubtedly not! We should protect and enforce the freedom of that code that ships with WordPress. Including the one that is under LGPL.

And one part of that is to ship the license with the package. Something I thought that would never be questioned in a FOSS project. WordPress steps out again – but in the wrong direction.

Anyway, to question having a license in the software package was not something new by Otto or Nacin. It is an opinion among more of the core developers that specifically license texts can be replaced with URLs to some third party website that most often even do not contain any concrete license text are enough to fulfill licensing requirements. That came first to my attention in Ticket #14703 which was about the BSD license.

The WordPress BSD Usage Rights Dilemma

The BSD License explicitly grants usage rights if the copyright statement, the license text and the disclaimer is shipping with the code. Was the license text and the disclaimer passed along with the code? Make an educated guess again. It somehow “naturally” was not. That “naturally” for a wordpress lead developer, that it was with any doubts for him to have a URL instead of the license. You think I’m kidding? Not at all, read yourself what Ryan Boren proposed: “The file [...] links to the license [...] clauses are met.”.

That was a bit of a shock. The BSD license is very short and very simple one. It clearly states, that you need to put the text into the software otherwise you loose rights to use the software. Does that mean a lead developer needs to consider to do so? Hell no! “clauses are met”. What happened?

The original author didn’t conform with his own BSD – the needed texts were not in the file (some friends and visitors could not even find any copy of the library licensed under BSD at all all over the internet). The author missed to put the license in the file. This might be his mistake, but it’s also the mistake of a user to not check if all conditions of the license are met. Gladly, the copyright holder Incutio Ltd. released an updated version with the BSD license then. This file got committed into trunk and the discussion at least for that ticket was over – with having the license in the package – at least for that library as BSD often has a modification of each license text (take this BSD text if you want to prevent that for your software).

How to Show License? – Retain it!

But WordPress is a project with zombies. Because there was such a confrontation about the topic of whether or not licenses needed to be part of the package and if so, if URLs are enough to provide the license I started to get in touch with other people of whom I thought they should actually know better. I mean persons who not only have some opinion but who know about what their are talking. The result was pretty clear:

Generally you need to include the license. This is to make sure that people getting the code know their rights.

I think this is a pretty good approach and should be the least common denominator.

And what does the LGPL itself states in specific?

And you must show them these terms so they know their rights.

I mean that’s all perfectly clear and obvious. Maybe some folks had just forgotten to take their medication or had sort of a bad day

Previous: Relicensing of IXR – The Incutio XML-RPC Library (Day 15)
Next: WordPress Licensing Issues – Plugins are GPL, Right?
Series: WordPress Licensing Issues

The License of the file in wordpress has been questioned in the recent WordPress GPL, licensing and copyright related issues covered partially on my blog.

According to Incutio Ltd., the company behind the XML-RPC Library, it was previously licensed under the non-GPL-compatible original Artistic License.

The now available alternatively licensed code makes it possible to end some of the licensing problems with the XML-RPC code in WordPress.

Update: New available information made me shorten this article. There is a chance that using the code was ok under Modified BSD which would help a lot for the past releases.

The related ticket is #14703.

Read On: WordPress Licensing Issues – On Showing License
Previous: WordPress Licensing Issues NOOP (Day 8)
Series: WordPress Licensing Issues

Day eight was mainly reflecting and running loops. I had a long and great discussion with friends in the evening not only about licensing in wordpress but in other free software projects as well that was very insightful. That poses a lot of new questions as well, I hope I can get the grip on those for the days to come.

Btw, there is Software Freedom Day around the corner.

– hakre

Read On: Relicensing of IXR – The Incutio XML-RPC Library (Day 15)
Previous: WordPress Licensing Issues – Summary (Week 1)
Series: WordPress Licensing Issues

WordPress might look a bit as a collection of bad practice examples. Let’s see what we’ve seen so far in the first seven days:

1. A plain copyright violation. A potential result are 12+ million illegal distributions of WP 3.0.x by wordpress.org (based on the projects own numbers).
2. Incompatible licensed code within the code-base. This is since longer time and in multiple places.
3. Violation of Third-Party-Licensing-Terms. Licensing Terms of third party code has been violated. This can make the modification and redistribution of that code illegal. Since years.
4. Missing Copyright and Licensing statements for core files. This can endanger the whole status of the application because it is not evident under which licenses a file falls. Normally those are considered as Non-Free. This is especially the case with the next point.
5. A missing clear Code Submission Policy. The committing developer has no orientation about the licensing of any provided patch. The whole project can be attacked because of this.

IANAL, I am a developer so my legal expertise is limited. Also I’m involved with the wordpress project so I have my own interests here (Disclosure: I contributed significant code to WordPress).

So I’ve called for professional help for the ongoing process to cover the bases and verify the wordpress licensing situation. That is needed to clarify questions that are not easy to answer (for me). Also I’m from Europe and copyright law differs to the US which adds some more complexity.

I’ve chosen to contact the Software Freedom Law Center in the US and the Legal Task Force in Europe. Both are connected to the Free Software movement of which I’m a supporter since years.

Consequences

The situation is grave. Which actions can the project take to turn the mess into something worth to distribute again?

For the moment I suggest the following immediate steps:

1. Remove of the last known GPLv2 references from code (incl. misleading text from Add-On update/install messages)
2. Revert the change of “Copyright” into “Licensing” in readme.html
3. Release of WordPress 3.0.2 because of the licensing issues

That’s not fully covering the bases, I know. But it would help to end the copyright infringement we are currently facing in the 3.0.x distributions. And it would provide the needed traction that is missing on the open tickets regarding the known licensing issues.

I’ve contacted wordpress.org days ago to inform them about the copyright issue in 3.0.x and made them aware that they are still distributing tainted packages. I got no feedback so far. So there is probably a problem for them to take care.

After that the other points follow on the agenda. This means an ongoing check of the code. And for many points there is need for discussions between developers because we have a mixed, collaborative work.

That is a lot of work in front of us. It would be great to see your support for free software and wordpress here.

Outlook

First contacts to the free software people have been established. That is clarifying a lot of questions already in the early stages and it is a source of valuable information and tools. I report this information back to the wordpress development community: Via this Blog, Bug-tracker, Mailing-list and Wiki.

I’ve seen some developers arguing: We did it this way for years, we can not fix this. I can only say: Probably, but if you don’t start with it, you’ve already lost.

I wish to see more support from within the projects community because I think this is an important topic. I know that these are complicated questions, nothing easy to solve. But with a will, there is always a way. I know that this is especially hard for those who all the time thought everything is in order. For those I’m most certainly the person who is bringing the bad news. But this is not about loosing something but to achieve and win grounds again.

Everybody who is using wordpress for business (that’s from using it to run the own company’s site, to build sites for customers on top of it up to running a blogging webservice like wordpress.com) should think twice of not to take care about the issues we are facing.

And everybody else who is taking care about free software because for the ones own and the users freedom and not only for free as in free beer should take care as well.

I wish we could see Matt showing up in both camps.

– hakre

Read On: WordPress Licensing Issues – NOOP (Day 8)
Previous: WordPress Licensing Issues – Submitting Code (Day 6)
Series: WordPress Licensing Issues

Such a policy should inform a willing code contributor upfront about the constraints if she/he adds some sourcecode, software or other material(s).

WordPress does not have such a policy right now, it’s missing in every aspect. A user can just sign up for wordpress trac and start uploading code. This might be code he/she is not allowed to redistribute and WordPress is not either then. This is a serious issue. Before writing those lines I’ve checked not only the code submitting process but all linked documentation documents in codex. None of them contains a single word about licensing, about what happens when code is given, the constraints. Even WordPress’ License, the GPL, is not a topic there.

That’s really a big problem, because after code has made it in, it’s very hard to find out for every contribution if the needed rights were given or not. Just think a moment about that.

So let’s take a look how that could be done. A simple real life example. A very easy and well known variant is the text / edit submission form in wikipeadia, before any submit you can read a clear submission policy that states everything important incl. the license:

[...] You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL. [...]

So it’s clear with which intention and under which conditions contributions were given. For software projects this can be more complicated, especially if this grows into something big. This is about Legal Matters. This goes that far (and beyond) that some projects require their contributors to sign agreeements prior to let them submit their code.

That would be far away from what we have since years in wordpress.org. A first start would be that a contributor can actually read about the license first.

If you know of other good examples or have suggestions, feel free to leave some comments.

– hakre

Update: I thought it would be of use to ask for for comments in the wp-hackers mailinglist as well and did post there: On Submitting Code – WordPress Hackers mailinglist

Read On: WordPress Licensing Issues – Summary (Week 1)
Previous: WordPress Licensing Issues – Progress (Day 5)
Series: WordPress Licensing Issues

Despite the fact, that when confronted with the topic that wordpress is GPL and not GPL v2, the first reaction by lead developers was, that there ain’t no licensing issues and all bases are covered. I’m and others are opposing to that attitude. We see licensing issues in the wordpress code. And other core contributors see them as well.

So where is/to progress?

#1 Apply the GPL right – or GPL v what?

That’s maybe the biggest topic because it’s documented that well known persons of the project have been neglecting the facts and were educating wrongly. This is not the post to drop names and quote, like finger-pointing-style, let’s just take it for the moment as a departure into the topic.

A popular belief was, that WordPress would be licensed under GPL v2 only. As we’ve seen the week, this is not correct. The moment this plain fact needed to be accepted even by those project core members who didn’t think so, there was an immediate reaction to say, yes, it is, but. A but like this one:

As long as we have a mix of “GPL” code and “GPL v2″ code and “GPL v2 or later” code, the only license that applies to every part of WordPress is version 2, as it is the only one that fits all three of the licenses.

Source: Mark Jaquith, WordPress Lead Developer

What in Marks words sounds like a description of a complicated but valid licensing situation, is infact a plain confession of a highly problematic dealing with licensing in the project. You can’t add code into wordpress that does not go conform with it’s license. That would restrain the freedom of the software.

But the spirit of the GPL is that no-one can take back your freedoms. That’s the banner under which all core contributors added their code: Free Software. Adding GPLv2 (ironically) is a blocker to our wordpress-users freedoms. So this code should never have been added.

But it’s worth to question that statement from another perspective as well. Yesterday I started with this question: Is it so, that there is GPL v2 and GPL v2 or later code in the codebase? And if so, how came it in? So I started to look for that bespoken code of which Mark said it would prevent proper wordpress licensing:

List of GPL v2-ly licensed code as of 29 Aug 2010

1. /xmlrpc.php – GPL v2

I made an ordered list, so counting is easier: 1 (one). I must admit I did expect a much longer and complicated list (there was a second one, changed this week because of my report: [15536]). But it ain’t – good so. This looks easier to be fixed then first thought.

Best part of this single point is, that the GPL v2 tagging of /xmlrpc.php was introduced by error:

As this was already file documentation and it is easy to check in the revisions of the file how this comment went in. The changeset showed tagging was just added but not for something in specific. Like well, it has no tag let’s add one and play around if GPL v2 fits. That was a ticket about taking care for all externals (so to help with licensing), xmlrpc.php is not an external file, so it might have just been forgotten in there. I’ve already filed a ticket to remove this again (#14727 – @license tag removal in xmlrpc.php). I think this can be fixed easily.

So as far as I’m aware of things, there has been a good progress the last days about the copyright and the related GPL issue. Sure some things are still missing, but I can see a direction where this is heading to.

#2 IXR XML-RPC Class

That’s a harder one. Are we breaking license? Has the license be tainted? Why is it tagged as BSD when other sources say it’s Artistic? There are a lot of open questions I have which needed to be answered one by one.

But on that area there is not much progress at all (Ticket: #14703 – Match Redistribution and use conditions for The Incutio XML-RPC Library). That’s maybe because it’s more complicated, so there is more action necessary to progress.

#3 Overall Care-Taking

While looking for license stuff, I run over those informative license PHPdoc tags that can help to keep things in order. They could benefit from a touch-up so I just provided a patch, that might be interesting for other who are currently checking the bases: #14726 – PHPDoc @license Tag Review.

We have a full new week in front of us and I’ll now start with some outdoor activity making up my mind on how to make this a good week for everybodies software freedom in the wordpress project.

– hakre

Read On: WordPress Licensing Issues – Submitting Code (Day 6)
Previous: WordPress Licensing Issues – Why I care (Day 4)
Series: WordPress Licensing Issues

It’s pretty simple. As it has been already explained on other sites, everything you interconnect PHP with the WordPress core software package is creating a so called derivate. I simplify this so to better hit the point: You just have made your own software.

The wordpress package says that WordPress is licensed under the GPL. And with GPL it’s fine for you because you get Free Software and you are allowed to create new programs out of it.

The Free Software Foundation (FSF) has created that license to spread free software all over the planet. Their current motto is: “Working together for Free Software”. There are the so called Four Freedoms in free software:

1. The freedom to run the program, for any purpose.
2. The freedom to study how the program works, and change it to make it do what you wish. Access to the source code is a precondition for this.
3. The freedom to redistribute copies so you can help your neighbor.
4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Next to the FSF in north america, there are also sister foundations, the Free Software Foundation Latin America (FSFLA), than there is the Free Software Foundation of India (FSFI) and last but not least in Europe there is the Free Software Foundation Europe (FSFE).

So these folks have done a lot to take care about free software. And this is ongoing. As written, free software makes possible that you can so easily create themes, plugins, get your blog pimped until the server burns down because there is tooo much to extend, rewrite and mesh-up. You enjoy your low hosting fees? That’s because the hoster do not need to spend your money for operating system licensing. Free software makes your software to open up to the sky.

But what happens when – let’s say by error – the WordPress packages license gets broken? Maybe due to licensing or copyright issues as lately, software-patents or trademarks? What happens with your software then?

Well, then you loose a lot of your Freedom. The software becomes restricted in it’s use. Basically you’re doomed. Ouch! You have created a sofware you had not the right to do so for. Isn’t that mean? This feels like proprietary software then. Am I still allowed to run my site? Good question, this depends how far the break of the license goes, normally you loose anything because of the GPL: For that part of the software that has been GPL previously you loose usage rights until you have retained full compability. This implies the right to run the program.

I don’t want to fear you (this is about licensing, nobody has been physically hurt yet because of the last days), but strictly spoken you did something that is not considered legal per-se.

If you really want to go on with your software, but you can’t because of licensing problems, that sucks. Let’s say you can not pass your great stuff over to a friend or you already did and you said he can use it but now he can’t. That’s really negative.

Let’s recap. If the WordPress licensing is broken, we’re all doomed. Even the first freedom, the right to run the program for any purpose, is revoked. This means you need to shut your site down. So in case this happens – and it did, as we learned three days ago – it is important to correct any mistake so that every wordpress user can recover from that. One way would be to release an update that takes care and after applying it, the sky is bright again.

So now you might understand why I care. I do programming for friends with plugin and themes. All derivates of wordpress, so I’m better safe than sorry. That’s why.

And one reason I haven’t told you right now: My friends and I we all work together for Free Software. The Free as in Freedom. We visit conferences, talk with schools about how to get better software in there, support those who do not have that much to share. And much more like educating the rest of us, hacking and having fun.

That’s why I care.

If you have WordPress 3.0.0 or 3.0.1 installed on your blog, your rights have been revoked to make use of the software. This is because of a licensing problem in the software packages that are hosted on wordpress.org. It does not matter wether you have downloaded it manually or aquired via auto-update. I have informed WordPress.org by it’s Webmaster Matt Mullenweg about the issue already. As it’s weekend now and things might not change fast, I share the info on how to “fix” it:

• If you are running the development version and you have updated in the last two days, than you’re ok.
• If not, open the file readme.html and remove “v2″ near the end, the one behind GPL (yeah, sadly).

That should help for the moment but I have the strong feeling that the next updates are not 2 characters only.

– hakre

Read On: WordPress Licensing Issues – Progress (Day 5)
Previous: WordPress Licensing Issues – the third day
Series: WordPress Licensing Issues

Licensing issues only seem to be interesting in the beginning. You get comments by core developers that they care and all the like. But when the real work starts, you’re pretty much alone and need to shift mountains before something get’s traction.

I know that I have support by other fellow free software developers and users out there even if it’s hard to formulate the right approach directly from the beginning. It’s about finding a way to go through together. And licensing is an issue that’s not easy to take in many directions. If you confront yourself with it, you might end up with more questions then you have answers. But it’s worth it.

Asking for shipping the BSD license with the wordpress package (as we do with the GPL license text) seemed to somehow cross a line in the sand. It’s neglected by the project (core in specific, other devs are actually providing own ideas). I absolutely do not understand why this is a problem. We have BSD licensed code in the package (at least right now we think we have). And for the sake of the users safeness, why not provide what the license asks for – the license text and disclaimer? Here, this is an example BSD license that is not within the code while worpdress is including and extending the Incutio XML-RPC Library:

IXR - The Incutio XML-RPC Library 

Copyright (c) 2002-2005, Incutio Ltd. 
All rights reserved. 

Redistribution and use in source and binary forms, with or without  
modification, are permitted provided that the following conditions are met: 

  - Redistributions of source code must retain the above copyright notice,  
    this list of conditions and the following disclaimer. 
  - Redistributions in binary form must reproduce the above copyright  
    notice, this list of conditions and the following disclaimer in the  
    documentation and/or other materials provided with the distribution. 
  - Neither the name of the Incutio Ltd. nor the names of its contributors  
    may be used to endorse or promote products derived from this software  
    without specific prior written permission. 
  
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS  
 IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,  
 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR  
 PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR  
 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,  
 EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,  
 PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR  
 PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY  
 OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT  
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE  
 USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

Read yourself, I can not help but for me it says, that it requires that the license ships with the software. Not that I’m a fan of the BSD license (Disclosure: I normally use GPL), but if a coder has released his stuff under that license, why not to comply with it? When using his code, why not pay respect for his license choice? Why to hide the license from users? To save some bytes? If you have an idea, please let me know. I just don’t see it.

Ryan Boren, another wordpress lead developer said it’s enough to place a link in there that is pointing to a how to write your BSD license-website. I’m not that sure if linking that really matches the BSD license requirements – to say at least.

And I’m not sure as well if the the original author provided the software in such a form that makes it available under the BSD while being able to match requirements by the BSD. Sounds curious? Right, what I just mean is that someones says: This is licensed under License XY but writes his copyright statement in a way that it breaks the license requirements of XY. Copyright prohibits to change the copyright notice (we had that topic the first day already), so this just creates a situation in which we have someone who says : yes it’s licensed under XY but you can never make use of what XY offers, so to say, that the copyright statement will prevent usage and redistribution of a software w/o saying it word by word but just by the license and copyright mechanics / tests. That’s somehow a special legal case I must admit, but while doing research today I’ve read many legal papers and you do not want to know which scenarios those lawyers are playing. That is a simpler one.

No wonder I have the feeling that the current doing is insecure rightly spoken. That and from what I can see in many, many, many other projects I’ve been looking up over the day, they all ship the with license(s) as if there is no other option to it. It’s not questioned at all. No idea what makes wordpress so special that those developers think they can stand out of the mass.

I have decided that I let this IXR BSD license issue in wordpress looked over by a free software organisation. I’d like to get clarification for myself as an active wordpress user/contributing developer as well as for anybody who is using the software. I’m also considering to contact the SFLC as I know that Matt Mullenweg as head of the wordpress foundation accepts their expertise. The steps/questions are literally simple:

1. Show that there is a link to a BSD-License-Template.
2. Ask if linking to a license text on a third party server fullfills retainment requirements of the BSD license in general
3. And ask if linking to that template fullfills retainment requirements in specific.

Basically those are the interesting questions, also for some other FLOSS projects maybe.

From what Ive experienced today, nearly anybody else just seems to be clear to provide license texts with their packages. I mean we’re talking about some hundred bytes and that’s it, so naturally this is not a problem for packages these days. But now I’d like to know, which implication the last six years had. Don’t you? Hopefully there is someone who at least knows something about BSD and licensing. Any recommendations and feedback is highly appreciated.

The other still big part that needs some attention are the other incompatible licences that according to lead Developer Mark Jaquith are in the code. You might remember the “wordpress is GPL, but errh, we introduced some code later on that is not compatible”-like statement from the last days.

But there is no need to rush, one day more or less does not count right now.

– hakre

Read On: WordPress Licensing Issues – Why I care (Day 4)
Previous: WordPress Licensing Issues – the second 24 hours
Series: WordPress Licensing Issues

A member of the WordPress team did revert the changes in trunk [15533] and the 3.0 branch [15534] (#14685). This is a step in the right direction.

But still there seem to be misconceptions about licensing. As this change in the codebase is only for development versions, software containing the unauthorized changes are still on the wordpress.org server. Affected Versions are 3.0 and 3.0.1. My suggestion to bump the version to 3.0.2 so to ensure that users with unauthorized copies can make their home feel good again, is not an option for core lead developer Mark Jaquith:

No. I applied it to 3.0 and trunk. It’ll go out with the next release from each of those branches. The package files are historical, and I don’t feel the need to whitewash them.

Just to ensure obligations are met is considered whitewashing? Interesting concept to deal with infringements for a fan of Free and Open Source Software . But that’s probably a very personal opinion of and not a statement by a wordpress lead developer, so looking for better ways to communicate.

Anyway, Mark made some other insightful comment I’d like to share. That has been made with the revert, and he talks about the licensing dilemma:

Later, some code was introduced that was licensed under the GPL version 2 (i.e. “only”). Some code was introduced that was licensed under the GPL version 2 or any later version. So while WordPress as a whole cannot currently be redistributed under the GPL versions 1 or 3, that does not change the fact that the code that does not have a version-specific GPL applied to it can be presumed to be released under the GPL, generally (any version).

That’s a pretty “interesting” statement. Up to the revert we have learned what the license of wordpress is: a non-version-restricted GPL. That’s why the revert has been made to the wordpress license text. And immediately after that Mark tries to explain why the license should not be valid for the whole work? If I read stuff like that I do not wonder much why licensing issues are not entirely taken care of properly in the project.

But that statement bears another interesting point, the admittance that parts of the code aren’t properly cross-checked for eligibility and license compability. I mean, you can’t release a GPL v2 code with wordpress even wordpress developers themselves have learned now. That just does not work. But Mark argues it can. So I started to look into the codebase for some of those places where a potential License mismatch might appear.

To give license

I was pretty surprised to see code in one file that was not only not licensed under GPL but under BSD. That IXR – The Inutio XML-RPC Library got my attention and I started to learn more about it and it’s license. The name “Artistic License” run over my screen. And then the BSD. According to some Wikipedia link I followed a table showed that BSD was incompatible to GPL. I might have been a bit too fast for the moment to immediatly open a ticket about that issue then (#14703), because the BSD license named in wordpress code is a modified version which is compatible with the GPL. That gladly would solve any GPL incompatibility match license wise. That’s good, because otherwise there would have been a licensing issue with wordpress for the last six years.

So after the different license were checked for compatibility, I took a closer look on the BSD license. It grants the right to redistribute when certain conditions are met. If those conditions are not met, the right to redistribute, to use and to modify the code is not granted (“Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met”, excerpt from the modified / 3-clause / “new” BSD license). You might think it already: Those conditions are not met. So there is a problem since six years with licensing code in this project.

I have no clue what this means, if this has implications for those who gave code in that time, and for the users.

Anyway, as this was in trac, there was again a lot of disco disco disco dance (Bonus: Spank Rock Remix feat. Amanda Blank). And it’s getting more harsh. Somehow. Core devs behave extremely cautious in contraire to other users that are starting to throw the same arguments to each other all over again. But that might just have been the time of day. I have full understanding for this, because as the day showed even I have sometimes problems to fiddle with the details and yeah, well, internet discussion.

I hope tomorrow will bring better answers and a brighter outlook for stuff like that. And maybe real changes for users. It’s obvious that trac is not always the right place to quickly find solutions. And I promise that next time when I open a ticket I have triple checked stuff. Even my mistake turned into good today, the ticket serves as the required license and disclaimer texts are still missing. From six month to six years is some change. The clarification on the GPL was infact something great today and it’s something to built on.

Read On: WordPress Licensing Issues – the third day
Previous: Unauthorized changes of WordPress licensing – the first 24 hours
Series: WordPress Licensing Issues

Circa 24 hours ago it came to my attention that the wordpress codebase was silently re-licensed some months ago (before l88 / GPL -/- after l105 / GPLv2). The copyright related licensing statement has been changed on February 28th 2010 for no apparent reason and prior notice. The way this change has been made – as far as I can say after 24 hours – was an unauthorized change.

In detail the change seems little (two characters added, namely v2), but this small modification makes a big difference according the wordpress license. It’s a copy of the GNU General Public License in it’s second version that ships with the project and with that license, naming or not naming the version number of the GPL by the program makes a difference. That’s the case here.

Users may now fear that their usage of the software becomes restricted and limited compared to the long-time provided and known licensing terms. Please take note, that this is not a problem of the GPL, it’s a problem of how the wordpress project handles copyright and licensing in general. Visibly by not taking care properly. The GPL in the end is the part that is protecting the freedom of wordpress users.

Since the software’s beginning more than seven years ago, developers had been given their code with the old terms. The free software then got distributed with those terms to users worldwide.

symptomattic

The moment I became aware of the unauthorized change, I opened a ticket asking for an immediate revert. I can not make that revert on my own, that’s why I need to contact other developers so that they take care of the job. It is ticket #14685 – Copyright Notice Tainted.

The first 24 hours now passed w/o practical action by the wordpress project. After some Pavlovian response by the committing developer and then the usual chit-chat and word-flipping games (oh hakre you’re wrong, this is not about copyright, this is about licensing – making commits only to underline arguments comes with a high price btw: [15529]), it looked like at least one core developer became aware of the potential dimension this small change implies.

He sent signals out, that he would take care to communicate and discuss the issue with other core developers and contributers. That was ca. 12 hours after the initial report. But no communication has happened since then from those developers who have enough power in the project to execute the demanded correction.

Nobody would be hurt by just reverting. So obviously this looks like a proper first action to me (and others). But there seems to be a lot for core project members to discuss instead.

This is a very unpleasant and unsatisfying situation for me as wordpress developer and user.

co-pi-me

Now served on a silver plate is a copyright issue in the worpdress core code since the 28th of February 2010 (trunk), an unauthorized change of the software’s licensing terms done by a single developer. The copyright owners of wordpress have never expressed the wish for such a change nor have they been notified about it. Practically this means that all publicly available wordpress 3.0.x software packages and installations are tainted by that unauthorized change.

I’m still in the hope that the project reacts now and reverts the erroneous changes promptly, fixes the available packages und uses the auto-update feature to help wordpress users to recover.

After the revert there is need in the project to carefully analyze what went wrong and how to improve the situation. This change made me aware as wordpress author, that there are important things to take care now. Know your rights.

Free as in Freedom. In the end of this story the GPL will safe us.

– hakre

Read On: WordPress Licensing Issues – the second 24 hours
Series: WordPress Licensing Issues