Git and the art of Licensing Maintenance

Matthew Mullenweg at Automattic recently called out Wix for a GNU General Public License (GPL) violation of an editor used by WordPress in a Wix mobile application.

Wix maintain a repository on GitHub that they assert contains all their changes - something that alone does not comply with the GNU GPL, which requires that the complete source for an application that is published to be made available to the recipient on request (under the terms of the GPL) if that application contains code that was itself released under the GPL.

The GNU GPL is not to be confused with the GNU Lesser General Public License (GNU LGPL) which does provide provision for the inclusion of linking to libraries without requiring the source for the rest of an application to be released under a similar licence.

Dion Almaer did a good write up of the situation and talks about how it may be muddied by describing it as a wrapper for another open source project, ZZRichTextEditor, which was released under the MIT Licence.

Wix do appear to have violated the GPL (and they wouldn’t be the first company) but it’s not clear Automattic haven’t maintained the licence appropriately either. There are lessons we can learn from this.

Looking at the repo history

A few months later, in July 2014 the licence was deliberately changed to the MIT License — not just the content of the licence changed, but so did the mention of the licence in the README and the copyright attribution, which now read “Copyright © 2014 Neil Stoker”.

Nearly a year later it was changed back to GPL Version 2, the copyright attribution and the MIT Licence were gone. The change was clearly deliberate and explicit but, as was the case earlier, the commit logs don’t explain the reason for the change.

Can you change the licence for a project?

If you wish to accept contributions from others for a GPL project while maintaining the ability to control how your project is licence in future you should clearly state terms which contributors need to agree to which grant you permission to do so.

Some companies do only accept contributions under terms that grant them exclusive rights over licencing and attribution although it’s also typical for organisations that publish dual licence software to just not accept external contributions which avoids the complication and limits their exposure to liability.

In this case it seems most, if not all, of the 13 contributors to the repo work for Automattic and they are in practice the sole maintainers.

This, however, does not grant them permission to discard the terms of any licence or copyright notice that may have come with external code that has been included in their project — something that may not be immediately obvious from the commit history alone, especially when files from one project are directly included in another.

The changes in attribution and to the licence were not made alongside changes to the codebase, so it’s hard to tell what code changes, if any, they might related to and would require looking at the substance of preceding and following commits to try and discern if they were of any relevance or of the licence change was just a personal or policy decision.

Why did the licence and copyright notice change?

The git commit summary is just fine but the lack of detail provides no context for why the change has occured.

This is something that is a problem day in day out at organisations, especially whenever changes are reverted or behaviour of something is changed — whether they are changes to the codebase, tests, library versions, setup or install instructions or, as in this case, licensing.

If developers reading this post take one thing away from it, remembering to explain the why in commit messages would be a good thing.

Maintaining licensing and copyright information

You can add your own notice and indicate that portions remain copyright of the origional maintainer. Whether you can change the licence itself depends on the term of the previous licence.

If you include a small library or method that has it’s own licence and copyright notice, you might find it’s pragmatic just to include that in the source for the library itself.

In fact, the GNU Savannah project used to insist the licence for projects they hosted was declared in the header of every source file. That’s a bit extreme but there is always the @licence tag if you are using something like AutoDoc.

Likewise, using comment tags to maintaining a list of authors who’ve worked on classes and libraries can be extremely useful — source control doesn’t always give you the full picture, especially if you’ve been working together on something at the same desk or over IRC or Slack.

Use the right licence and check your copyright attribution

A quick search of GitHub suggests a couple of possibilities for who Neil Stoker might refer to but he isn’t the maintainer of the repo, it doesn’t seem like he works for Automattic and he’s not the author of the ZZRichTextEditor either.

Maybe it’s someone I don’t know, maybe it’s just an error. I suggest this as a possibility as it’s a mistake (such as casued by accidental dragging a file into a repo) .

When looking for a licence file to add to a project it’s often easiest just to copy one over that we have from an existing project that is released under the licence we want to use (whether that’s an old project of our own, a work project, or someone elses project we are hacking on) without noticing that the licence includes a copyright attribution.

Copying and pasting from other projects also brings other problems with it, such as using licences that have been replaced with newer versions to address issues in their older versions or missing additions, removals or special conditions or copyright notices attached.

It’s best to check you have the most recent appropriate version of the licence and that you understand any differences, even if they are small. For example, if you are using the MIT or BSD licences, you may wish to consider the Internet Systems Consortium Licence for future projects.

Ensure everyone undersands licensing and copyright attribution

Attribution matters legally but is also useful when you find you want to track down where a library or interesting code snippet comes from (like a function from StackOverflow post).

It can provide insight in the problem that was trying to be solved at the time and context for a better solution if it turns out the code needs to be refactored, or later removed for compliance reasons.

Don’t think that people won’t notice when you get it wrong

In a seemingly nefarious move the cURL binary had been curiously renamed “AOL_Broadband_Installer.exe” as if to hide it’s identity. I’d only recently joined the team so, having stumbled on the blog post about it I got in touch with Daniel to let him know I’d look into it.

The well meaning colleague and lead developer responsible for mastering the CD’s explained the rather inspired (and perfectly reasonable) explanation for the file name and that the licence was mostly an oversight.

It hadn’t really occurred to him that including a freely avalible binary meant that he was also bound by the terms of a licence and was also born out of a desire to keep the contents of the CD’s are free of clutter as possible so that people (in this case, AOL UK members) could more easily navigate the contents of the CD and it was clear what they should click on.

This isn’t a strange assumption when you think that plenty of other “freely available” software for Windows doesn’t require a licence be bundled with it when you use it (as attribution is baked in to the file) and large Windows applications often include third party executables and DLL’s.

We were able to address the issue in this case by including appropriate licencing and copyright attribution information on the CD’s in all future releases and Daniel was very gracious about it.

Understanding licence compatibility

There are also problems with developers and organisations not fully understanding the difference between related licences – such as the Affero General Public License (AGPL) vs GPL vs LGPL – and how using code from projects that use them impacts their own projects.

In some cases, licences can even irreconcilably conflict. The Free Software Foundation often provide clarification on this.

In fact, according to the Free Software Foundation (and apparently Apple) the terms of the Apple App Store are incompatible with the GNU GPL, specifically section 6 of the GPLv2 — making it relevant in Automattic/Wix case.

This suggests, although it seems unlikely unless someone were to prompt the issue, that Apple could even decide to pull the Wix application themselves, unless and until Wix remove any GLPv2 licensed software from their application.

Update: Some of the information in this post was originally left as a comment on the original blog entry by Matthew Mullenweg. The comment was still being withheld at the time I published this article, but has since been made visible.

PS: Sorry about making AOL CD’s.

Software for news and media and civic tech. Cat herder. Director at Glitch Digital.

Software for news and media and civic tech. Cat herder. Director at Glitch Digital.