The Dirt on Open Source Licensing

I’m a big fan of podcasts, and listen to a wide variety of them regularly. So much so that it isn’t uncommon for me to have a couple months worth of backlog sitting on my phone and iPad (synced via PocketCasts) waiting to be listened to.

So it was only this morning that I listened to an episode of The Dirt from back in December 2014: Open Source pt. 2: Licensing Matters with Gabe Levine.  This was the 2nd in a (so far) three part series on Open Source from a podcast I usually really enjoy, put out by an agency (Fresh Tilled Soil) for whom I have tremendous respect. It was on a topic (open source licenses) about which I think most web designers, front-end developers, and web developers need significantly better education and understanding. It included as a guest a lawyer (Gabe Levine) whose twitter bio describes him as a “New Media Lawyer Extraordinaire” and who was described by The Dirt post as a “super lawyer.”

That’s why I was so disappointed.

Beyond muttering to myself on my morning walk, I just have to respond to some of the major issues I had with the podcast. (No comments allowed on the blog where the podcast is posted, so I’ll write here and tweet to the podcast).

1. The obligations of the GPL are triggered by distribution

The group discussed the differences between different licenses and the fact that GitHub does not require a license be selected for a project, but does now encourage it (see Github on licensing).

What no one mentioned was the helpful choosealicense.com site GitHub launched to help people choose, which does a very simple and clear job explaining the differences between popular licenses. (Simplified, but generally accurate).

The discussion turned to the GPL and its “copyleft” cause, which says that if you distribute changes you make to a project licensed under the GPL, or if you distribute a project that is a derivative of a project licensed under the GPL, you must make your software available (to those to whom you distribute it) under the GPL as well. This means you pass on the same four freedoms you enjoyed from the upstream project upon which you are  building.

One of the podcast hosts (Tim?) asked, in essence, what if I build a site on a GPL platform like Drupal? Am I obligated to share all of my code under the GPL?  Gabe answered no, but implied that was because the code Tim would have written in that case would not be considered a derivative. No one even mentioned the concept of distribution at all. 

The reality is, you can take a project licensed under the GPL, modify it, make derivatives of it, make it run 300% faster, add features, extend the core, and run it on your own servers as often as you wish. As long as you are not distributing the code to anyone (offering it for download or shipping CDs), distribution has not been triggered.

Google reportedly makes many modifications to linux distributions to improve efficiency in their data centers – and is under no obligation to share that back.

Acquia had for some time has a project called Drupal Gardens, which enables users to set up free Drupal sites in a SaaS model – like WordPress.com – and was under no obligation to open source that project, though it was quite clearly derivative of Drupal.

Automattic, in addition to WordPress.com, offers WordPress.com VIP hosting, and has created various bits of software to make that platform run efficiently – as have many other managed WordPress hosts – and they are under no obligation to release those platforms.

For companies who are building their website on a platform that is GPL licensed, they are not distributing that software. It is very common, in building a WordPress powered site, to develop custom plugins or complex themes, which are at least partially “derivative” of the core software. (Some parts of themes might not be derivative, but let’s accept for the sake of argument the generally accepted thinking that the php code in themes and plugins is derivative). Those companies are not obligated to release those plugins or distribute them at all. The issue is only when they do decide to distribute them – in which case they need to make them available to the distributees under the GPL.

To repeat: if you are not distributing your modifications/derivative works, you need not share them with anyone, including the source project. 

If you are building software you intend to distribute, and don’t wish to distribute under the GPL, you should not build on GPL software.

If you are building software you do not intend to distribute, you need not worry about GPL infection. This is why even Microsoft (as strongly anti-GPL as any company I can think of) has no problem hosting WordPress powered sites.

2. The GPL is used by many of the largest and most successful projects

Ok, so maybe in this case I’m being overly sensitive.

The whole discussion was presented in such a way that made GPL licensed software sound like it was only for fringe projects, or was unpopular.

Let’s not forget that all of the most successful open source content management platforms are licensed under the GPL: WordPress, Drupal, Joomla, and so on.

Let’s not forget that Linux itself is licensed under the GPL – and is undoubtedly the most common server operating system on the web.

Let’s not forget that Git is licensed under the GPL (and yet this doesn’t prevent GitHub from being a hosted service based on Git).

I’m not arguing that the MIT license is a bad license, or that people who choose “permissive” licenses over “copyleft” licenses are doing it wrong – but to suggest that the GPL is some kind of fringe case is simply wrong.

3. Creative Commons did not inspire the software licenses; it was inspired by them

Later the conversation turned to Creative Commons, and the license variations Creative Commons offers, which are designed (thus the “Creative” in the name) to allow creators of creative works (photography, art, illustration, music, writing, etc) to define the ways in which they want their work shared. (Or the conditions under which such sharing is explicitly allowed by the copyright owner).

Gabe (I believe – I could have the voices assigned to the wrong speakers) suggests that perhaps Creative Commons was first, and inspired the software licenses.

That’s like suggesting that perhaps horse-drawn carriages were inspired by the early automotive marketing industry.

Creative Commons was formed in 2001, and released their first license in 2002. The inspiration flowed exactly the other way: “Creative Commons developed its licenses – inspired in part by the . . . GPL.”

The Free Software Foundation was organized as a 501(c)(3) in 1985, and the notion of using the license the FSF had created as a General Public License appears in 1988 or 1989.  The GPL v2 was released in 1991.

4. Dual licensing is common

The notion of dual licensing also came up near the end of the discussion, and it seemed a wholly novel idea – that a piece of software would be available under multiple licenses.

This is not uncommon. MySQL itself has long been available via GPL or via a commercial license which enabled you to build it into products that would be distributed without triggering the GPL distribution clause.

Even commercial software is regularly dual licensed. You can get Microsoft Word or Adobe Photoshop or Apple Keynote retail as an individual, or via an OEM license, or as a corporate subscriber to a corporate license, or as a student under a student license, etc. Each of these may be the exact same set of bytes but made available under different license regimes and restrictions.

There are complexities for open source projects with respect to dual licensing. The copyright holder needs to agree to licensing changes – so in the absence of a contributor agreement or copyright assignment, an open source project that has taken a number of contributions from many people may be unable to change the license retroactively.

Licensing Matters

Apologies in advance if this whole post feels like a rant. I know the folks at The Dirt are not intending to spread misinformation or scare people about working with open source software, but I think it is really critical that people understand what the GPL does and does not require.

I am not a lawyer, and don’t even play one on the internet. But there are many great resources that can help you understand what the licenses do and do not mean. Here are just a few:

For key projects I’ve worked with, here are there pages on the concept:

 

4 Comments

  1. Thanks for the interesting read.

    Your points for #1 seem to me to be a little too summarized. Systems that generate websites do distribute things – the websites. So any JavaScript, CSS or HTML that is includes content from the website framework may be affected by the copyleft licensing. Which may come directly from the framework, or from copying a plugin/theme from the framework.

    Agree completely on #2, #3 and #4 :)

  2. Thanks Hen.

    While the JavaScript, CSS, and HTML get downloaded to your machine for rendering (and in the case of JavaScript execution), the license is quite clear that this is not distribution: “Mere interaction with a user through a computer network . . . is not conveying”

    On the FAQ about the GPL the FSF says:

    Is “convey” in GPLv3 the same thing as what GPLv2 means by “distribute”?

    Yes, more or less. During the course of enforcing GPLv2, we learned that some jurisdictions used the word “distribute” in their own copyright laws, but gave it different meanings. We invented a new term to make our intent clear and avoid any problems that could be caused by these differences.

  3. John,

    Thank you for your thoughtful response to The Dirt podcast episode on open source licensing. You’ve added to the education and information available to listeners, and that’s a good thing.

    As a starting point, the episode was meant to provide a very basic audio primer to help independent software developers choose between popular open source license options, and to entertain a little while doing so. I think we did a pretty good job of that, even if we failed to mention Github’s choosealicense.com site (which is also a great resource).

    Of course, one can always do better. “Distribution” (or “conveyance” and “propagation” under the GPLv3) is indeed an important concept vis-à-vis the GPL, and we probably should have addressed it, at least briefly.

    I think we were assuming that our listeners were generally going to be distributing their software. I also think any sort of detailed discussion of distribution would’ve put the audience to sleep… or at least put my hosts to sleep.

    While the open source community may have a consensus about what should happen in various potential distribution scenarios, the GPL versions are different, the FAQs are inconsistent, and there is a relative dearth of legal precedent in the area. All of that leads to practical lawyers advising digital agencies and independent developers to consider other licensing schemes.

    If a client were to ask me whether the GPL is a good open source license for a project it is going to be built internally, with no intent to distribute, my answer would likely be to challenge that last assumption. Might there ever be a derivative downloadable application and/or might the client ever want to sell the asset?

    As a relevant aside, believe it or not, I often have to fight for my clients’ right to use any open source software. So, conceding on not incorporating anything governed by a copyleft license is often an acceptable middle ground (as long as it isn’t a Drupal or WordPress project, of course) for my agency and independent developer clients.

    Of course, I love the idea behind FOSS. I wish there weren’t software patents, or at least that there were far fewer of them. I also wish that my clients’ and my work weren’t repeatedly intruded upon by the outdated and unreasonable requirements of the venture capital and BigCo/BigLaw realms.

    So, please keep up the good work.

    Gabe

  4. Thanks Gabe for taking the time to reply – I appreciate it. I truly am a big fan of regular listener to The Dirt and fully support the desire to educate designers and developers more about licensing.

    I guess the point I felt was most important is the one aimed at companies or individuals thinking about developing a site in WordPress or Drupal or another GPL licensed CMS or framework. They should know this (by anyone’s interpretation I’ve ever seen) will not obligate them to distribute the code they develop as part of that site to anyone, nor contribute their custom work for that site back to the project.

    I’ve been in plenty of those conversations with clients who ask us to build a WordPress site or network of sites, but then send us an MSA that prohibits the use of any open source software – so I know that pain too.

    What I see more often is developers jumping into open source projects – making WordPress plugins or Drupal modules – without understanding the existing license governing the platform and community they are joining. If they then go into trying to monetize those plugins/themes without a solid understanding of the license, they are in for an education. (Note: I’m not saying you can’t sell GPL plugins, just that you’d better understand the licensing and the legal implications thereof).

    If you’re building something that is derivative of an existing framework (recognizing there are legal nuances and debates about what is or isn’t a derivative work) you had better be aware of the expectations that comes with – too often people don’t read the license at all (just like the terms of service we all blindly agree to).

    If you’re building something more-or-less standalone, which you intend to distribute, you should absolutely be considering the tradeoff between restrictive and permissive licenses. If you use a permissive license like MIT, that means someone can bundle your library into their product, improve it, and never share those improvements with any outside developers. If you use the GPL, there will be some other projects and clients who can’t incorporate your work as a result. Ultimately it depends on whether what you want is “broadest possible distribution and use” or “as many of the improvements any developer makes shared back to the community as possible.” Of course, many downstream developers do share back to projects even when not obligated to, because they too have an interest in improving the core project.

    Anyway, sorry if the post came off as a rant – and thanks again for 1) taking the time to be on The Dirt in the first place and 2) for replying here.

Comments are closed.