WordPress Licensing Issues – the second 24 hours

After the first 24 hours I became aware of the unauthorized changes of WordPress licensing, the day started with some positive movement.

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

About these ads
This entry was posted in Pressed, Wordpress Licensing and tagged , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

11 Responses to WordPress Licensing Issues – the second 24 hours

    • mtekk says:

      I was going to say something more on the lines of “Duck and cover”, but anyways.

      It looks like the real issue here is that the author of IXR did not include the standard license headers/comments in his code. This is more of a SNAFU than the previous issue with declaring the GPL version (not to get picky, but isn’t every source file supposed to have the GNU GPL declaration at the beginning of it?). Yes, currently, for a license to be valid you need more than a hyperlink/URL for it in the source file. What should be done is the original author should be contacted to remedy the situation (this happens to be his fault, not WordPress’).

      The version of IXR included with WordPress is not the same as the version available from the original author (version wise it is newer). It also looks like someone changed the license to the modified BSD from the Artistic license. Both 1.6 and 1.7.1(beta) are under the artisitc license, WordPress seems to be the only place to find 1.7.0 (beta) and it is under a conflicting license. Like I said, it seems to be a SNAFU.

      • hakre says:

        SNAFU, yeah. Symptomattic.

        Ryan wrote that he had clarified with Simon Willison, the original author, that the code is licensed under “New BSD”. I asked for details on that correspondence because I have problems to contact Simon directly to find out more.

        I have a 1.7 version that is licensed under the non GPL-Compliant “Artistic License”. AIK it’s not possible to change the license on the same version of the file. For example to drop the “Artistic License” and to replace it with “New BSD”.

        Assuming that and because both files – not the external v1.7 one nor the wordpress v1.7 one – do not mention a Dual-License, something is really broken IMHO. The deeper I look into this, the more serious the situation looks licensing wise.

        • mtekk says:

          Well, the original author, Simon Willison, as long as he holds the copyright to all of the code it the file, can release it under what ever license he wants. He can do this even under the same version number, which he probably did but there is not public record of this happening so it looks like someone at WordPress did the unauthorized license change.

          • hakre says:

            Yeah might be, Ryan is not replying. I poked him again today, no response regarding a clarification.

            Next to that I read something about when there is dual license stuff, it needs to pass all licenses, it must be visible under which licenses, so none is taken away. The user in the end can drop whichever one he wants but if you pass the code on in source form (as we do), then you need to pass the full licensing. Something like that. But that might be only if the original author names all the licenses.

            And that’s again something we don’t know as well.

  1. Pingback: Wordpress licensing issues – the third day | hakre on wordpress

  2. Pingback: Wordpress Licensing Issues – Why I care (Day 4) | hakre on wordpress

  3. Elpie says:

    The problems with WordPress licensing go right back to b2. b2, as a whole, was issued under the GNU/GPL but didn’t state a version. It included some files that stated, “GPL version 2 or later”. The first release of WordPress used much of the same wording, right down to the README saying the license was GPL and only linking to the license. That version of WordPress also included files with incompatible licenses.

    Simon Willison can change his code to any license he wants to, at any time. However, any such change is not retrospective so whatever his code was licensed as when it was included in WordPress is the license that applies – unless he gives permission to WordPress to change it. The modified New BSD license is compatible with the GPL so if that is what xmlrpc is then there isn’t any problem. I can’t see anything indicating he’s ever released it under the modified BSD license though. If it’s under the old Artistic License then it’s not compatible with the GPL and shouldn’t be included.

    Edd Dumbill’s original xmlrpc (that was originally used in WordPress) used the modified BSD license so I hope someone isn’t just getting confused.

    I’ve always wondered what would happen if someone wrote a plugin or added code to the core under GPL3. Even though WordPress doesn’t specify a GPL version, GPL2 and GPL3 are not compatible licenses and can’t be used together.

    • Mark Jaquith says:

      I’ve always wondered what would happen if someone wrote a plugin or added code to the core under GPL3. Even though WordPress doesn’t specify a GPL version, GPL2 and GPL3 are not compatible licenses and can’t be used together.

      We’d ask them to license it as “GPL” (any version) or any other license that would allow us to combine it with GPLv2+ code. At some point, there may be enough libraries that are only available under the GPLv3 or higher, and WordPress may need to upgrade. We’ll cross that bridge when we come to it. The work I’ve been doing on clarifying or relicensing GPLv2-only code has been to make that a possibility, in case we need it in the future.

  4. Mark Jaquith says:

    @hakre:

    Just to ensure obligations are met is considered whitewashing?

    Unless I misread, you suggested updating the already released packages. The packages were released. Retroactively changing them doesn’t change how they were released. This is what I meant when I referred to “whitewashing.”

    As for pushing out a new version, the length that the current release package sits with a GPLv2 license doesn’t matter. Whether 3.0.2 is released today, in a month, or never, it doesn’t have any bearing on this situation. The clock stopped when I removed those two characters. I don’t think it is appropriate to push out a new version just to hasten the closure of anyone who was concerned by that two character alteration.

    As a general update, I got a piece of GPLv2-only code to be relicensed by its author as “GPL” (any version). A GPLv2-only license was applied to the xmlrpc.php file by someone who didn’t have much to do with writing it, and I believe that to be a mistake. Once I talk with the major authors of the file, I can get that tag removed. That should be the last of any code fragments that were explicitly (or mistakenly) marked as GPLv2-only.

    Ryan is asking about IXR, but its author is on vacation, so that will likely take several weeks to be resolved. I’m fairly certain that it was the GPL-compatible 3-clause BSD that was meant to be applied (as linked), or that in any case, the author will be willing to explicitly license it in a way that makes it absolutely clear that WordPress can integrate it under the terms of the GPL (any version).

    All of these things are fairly minor points. Certainly nothing to warrant the level of alarm you’ve given it.

    I’ve come to the conclusion that you are ultimately wrong that distributing WordPress as GPLv2 was an “unauthorized change.” It is more accurate to say that it could have had unintended consequences. If it were allowed to persist, it could have theoretically restricted our ability (or anyone’s ability) to distribute WordPress under the terms of the GPL version 3 or any future version beyond that. I’m glad that you caught that relatively early. I want to make sure that we don’t box ourselves into version 2 of the GPL. If all the best libraries move to GPLv3 or LGPLv3, we may want the ability to upgrade at some point in the future (you have to upgrade to the GPLv3 or “GPLv3 or later” to integrate GPLv3 code).

    The core team is continuing to work on this, including considering getting Trac contributors to affirm that the code they share is shared under the GPL (any version), and possibly making our licensing statement in WordPress more explicit and standardized. I rolled it back to how it was (i.e. just “GPL”) because that was the safest move while figuring all this out and getting clarification where licensing terms might have been less than crystal clear.

    If you’d like to talk about this privately, the best way it to hit me up in Skype text chat. My username is “markjaquith.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s