Thinking About Open Source, Part One

Jan 11, 2016 • Jeff Strauss

Over the last few years, I have traveled around to many conferences and user groups, speaking on various aspects of open source licensing and consumption. I imagine that I will continue to do so, here and there. I enjoy sharing this knowledge, and am energized by many of the discussions that come out of my sessions. As I start to give other talks, and the recent open source ones become less prevalent, I hope we can keep the conversation going by having a forum for discussion here.

So… as the New Year begins, welcome to the first in my upcoming series of posts all about open source.

OPEN SOURCE SERIES

What is Open Source?

The abstract for my popular talk, The Impact of Leveraging Open Source, reads in part:

Open source tools. We all use them. But what does "open source" truly mean? What are our rights and limitations as open source consumers to use, modify, and redistribute these tools?

I think that there is a great deal of misconception about the core definition of Open Source software. Many young, new developers—and perhaps experienced devs, as well—associate the term "open" with the idea of "free" stuff. If you are just getting started, or trying to build your own side project, or just are strapped for cash generally (and who isn't), then "free" sure sounds exciting!

On the other end of the spectrum, developer leads and project managers in big business settings have, historically, largely run away from Open Source, screaming. At one time or another, they heard horror stories about a project that completely fell apart because it incorporated an open library and either failed to comply with the licensing terms, or else triggered an obligation on the part of the business to open source their proprietary end-product. Bosses screaming; jobs lost; fire and brimstone; the works.

Both of these perceptions may be true—some of the time.Neither has anything to do with the definition of a piece of software as being open source.

It so happens that many different distributions of Linux are readily available for download, free of cost. Red Hat also offers Red Hat Enterprise Linux, at a fairly hefty annual sum, and plenty of businesses happily pay for it. Both are "open source," but one comes packaged with automatic updates and other helpful support services.

If your commercial enterprise is trying to release a proprietary, closed-source image editor, you probably should not fork it from GIMP. On the other hand, back in November 2014, Microsoft open-sourced the .NET Core Framework and Runtime under the MIT License(more on that in a future post), and countless companies release closed-source products based upon .NET every single day.

As with so many things in life, one size does not fit all situations. So… what are the core factors that define a piece of software as open source?

The Open Source Initiative and Licensing

When it comes to defining open source software, the standard-bearer for nearly twenty years has been the Open Source Initiative. This non-profit organization declares themselves (rightfully) to be the "stewards of the Open Source Definition."

Okay, sounds fancy. What that really means to me and you is that OSI reviews and certifies whether a given license, through that license's standard text, comforms to the requirements for Open Source software. When we say that a piece of software is "Open Source" with a capital O.S., we mean that its source code is made available for consumption under a license approved by OSI.

Approved Open Source licenses vary greatly in their scope, length, and content, but at a minimum, they should all comply with the following requirements.

Free Distribution

Here is the "FREE" that we discussed before. "A-ha!" you say, "But you said that open source software did not have to be free." People often conflate two separate meanings of the term. As I often say in my talks on this subject:

With Open Source, we mean "free" as in Free Speech, not Free Beer

Everyone loves cost-free beer, and who doesn't love cost-free software? But that's not what we mean when we talk about Free Software. Rather, the intent is that Open Source is just as it sounds. The underlying source code is freely available. Moreover, the license must not restrict the consumer from giving the source code to others and cannot demand royalties from downstream consumers for future use. This leads to another important requirement.

Source Code Inclusion

It probably goes without saying, but Open Source software licenses require that distribution includes source code. For that matter, it is important to realize that compiled, binary software cannot, by definition be Open Source. It is the underlying source, through its distribution, that is licensed under an OSI-approved license. The code must be easy to obtain, at little to no cost, without obfuscation.

Derived Works

Open Source licenses will never prohibit the modification of the source code, nor the distribution of any derived works arising from those modifications. There are actually a couple loaded terms in that last sentence: "distribution" and "derived works" both can mean slightly different things depending upon the context.

In future posts, I will look at both of these concepts in more detail. But for now, it will suffice to say that any Open Source license will permit you to modify its covered code and redistribute the results. The extent of your own code that is deemed part of the "derived work," and the means through which you may be required to license those derivatives, is at the heart of what differentiates many OSI-approved license from one another.

Techhnology and Software Restrictions

One requirement for Open Source that is less obvious is that a license may not restrict consumers' rights based upon the presence of (or use with) any particular technology. That means the Open Source license distributed with the software cannot be conditioned upon:

Use alongside any other specific software or environment;

Distribution on a specific medium; or

Reuse in connection with any specific platform or technology.

The purpose of these requirements, generally, is to ensure that consumers and distributors of software remain free to make the choices about their software and systems that best suit their needs.

Anti-Discrimination

Properly licensed Open Source cannot discriminate against any group of people or purpose. Stated another way, there can be no restrictions that exclude anybody from using and benefitting from the software; and there can be no limits that prevent the software from being used in the pursuit of any given endeavor—whether or not the original author approves of that endeavor.

The FAQ page on the OSI site actually poses the question of whether "evil people" can be prevented from using open software. The answer, of course, is no. The purpose of preventing any kind of discrimination is to ensure the maximum amount of participation in the open source community. Ideas are meant to be shared, no matter what those ideas may be.

In an old slide deck, I used to show a picture of Voldemort grabbing Harry Potter. It was good for a quick laugh. But the point was to illustarte that even if somebody as evil as Voledmort wanted to use open source software to produce registry to systematically eliminate all Muggles, nothing in the Open Source license can disallow this.

Important Caveat:Just because the license is silent on issues of purpose—evil or otherwise—this does not excuse you or anyone else from abiding by all of the laws where you live. Unlawful activities are still going to get you into trouble. Here, we are simply discussing the terms and conditions of use under the Open Soure license. Nothing more; nothing less.

What's Next?

Now we at least have a better idea of what it means to be "Open Source" software.

In future posts in this series, I intend to contrast so-called "copyleft" licenses from the other "permissive" licenses under the Open Source umbrella. I will post a discussion of what constitutes distribution of software in the first place, as well as a review of the differences between copyright, trademark, and patent. And, of course, I also plan to discuss some details of various popular licenses. Write me if there are any you've come across that you'd like to hear more about.

Disclaimer

If you have seen my talks in the past, you will have heard me say this countless times. But as always, remember, "I may be a lawyer, but I am not your lawyer." Arana Software LLC is not a law firm and does not engage, in any context or jurisdiction, in the practice of law. These blog posts are for infomational purposes only and should never be construed as legal advice. If you think you, your company, or your work requires specific advice with respect to any particular issue or problem, you should contact (or retain) an attorney who represents you and understands your needs. My ramblings on this blog are nothing more than a guide for some things you may wish to discuss with your own counsel.