Open source licensing needs to grow up already

Open source has won -- as a cauldron for innovation as well as a frictionless means of software distribution. So why are we still messing with obscure licensing minutiae?

Open source licensing needs to grow up already

Despite apparent indifference from the GitHub crowd and more than 25 years of familiarity with the ins and outs of open source, we still have to be bothered by the nuances of open source licensing. It's like we hit middle age but still have to worry about pubescent acne.

It's really, really lame.

The thought struck me while reading Dries Buytaert's exploration of the ideal client-side framework to pair with Drupal, the platform he invented. After wading through the technical merits of EmberJS, AngularJS, and React, Buytaert concludes: "The legal concerns with React and Angular make me believe Ember might be our best bet."

We can do better than that.

Open source through the ages

I first got involved in open source in earnest in 2000, working for an embedded Linux vendor. I collaborated closely with our legal team, which was kept extremely busy by the fear, uncertainty, and doubt raised by the GNU GPL (General Public License) in particular and open source licensing in general.

It wasn't until enterprise-safe IBM declared its billion-dollar support for GPL-licensed Linux that my company got to focus on selling Linux-based mobile solutions, rather than therapy for GPL-stressed attorneys. Over time, we've become progressively more laid-back about open-source licensing, to the point that last year I declared we now live in a "post-open source world."

If only.

Not so free to choose

After all, open source luminary Buytaert is hemmed in by licensing as he tries to choose the best JavaScript framework for Drupal. This must be frustrating given the broad popularity of AngularJS and the truly game-changing nature of React Native.

However excited a Drupal developer might be about either, however, they must first confront the concerns that Buytaert raises:

Angular 2's Apache 2.0 licensing is incompatible with Drupal's own GPLv2 license. While Drupal's PHP code and JavaScript code run in isolated processes, it appears that an Apache 2.0-licensed project can't be jointly distributed within an umbrella project that uses a GPLv2 license.

He continues:

React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement.

We're more than 25 years into open source, and we're still having to muck around in licensing minutiae. Lame, lame, lame.

The future of truly open source

I know much of the blame for the continued confusion around free and open source licensing comes down to different, strongly held opinions about whose freedom matters most: the creator of code or the downstream adopter of that code.

Free software licenses like the GPL fixate on the freedom of the software itself to be unencumbered by proprietary constraints. Open source licenses like Apache, for their part, focus on freedom for the developer who downloads and uses the originating code.

These divergent paths aren't likely to be resolved anytime soon.

But they should be. Although organizations like the Free Software Foundation and Open Source Initiative (disclosure: I am an emeritus board member) have lost some of their relevance in recent years, they'd immediately regain it by working together to remove obstacles to adoption, starting with the licensing discordance between Apache and GPL code.

Both have done great work over the last few years, educating would-be adopters on the implications of their licenses. But we don't live in a world where GPL code will always be linked with GPL code, or BSD/Apache-licensed code will always link with like-minded licenses.

We live in a world where open source code has won, yet we continue to have to answer silly questions about open source licensing. In 2016, we need this to stop. The OSI and FSF can help.


Copyright © 2016 IDG Communications, Inc.

How to choose a low-code development platform