Open-source development covers a lot of bases. There's everything from documentation to development that is freely available on the web. It’s rather magical to know that you’ve got access to the code that drives some of the industry’s most widely used platforms like OpenStack, Kubernetes, Docker, and much more.

As a purveyor of some open-source goodness myself, I’ve started to become more aware of the nuances of each of the various open-source licenses. There is much more to these licenses than many of us may realize. It is a legal contract, so it is important to be aware of the differences in each license.

GNU, Apache, MIT, and More, Oh My!

I always say that the greatest lie since “the check is in the mail” is “I’ve read and agree to the terms and conditions.” Joking aside, this is something that we do take for granted as we look to embrace and create products which are crafted under the open source licenses.

GitHub has a page to give some guidance on the addition of a license on the creation of your repository. This is all well and good unless you’re still trying to figure out what the guts of the license are.

There is a link on the page that points out a very cool resource site called Choose a License. As you think about the project you’re open sourcing or look to contribute to an open-source project, these are important things to consider.

Questions that you’ll need to think about may include:

• Is my project representing my employer?

• Does the project indemnify me and my employer from any potential damages?

• Will there be any intellectual property or patent-related content today or in the future?

I wish we didn’t have to ask things about damage and indemnity, but that’s the reality of what we have to be prepared for. If you give something away and it ends up causing a system outage somewhere, we as the creators and publishers are potentially liable.

This is something that everyone who works in open source and software publishing should be aware of. Even your documentation and how-to guides are generally covered under a sort of as-is provision, but it is worthwhile to make sure it is clearly stated.

Open Source Is Fundamentally Good

There is a real sense of community that comes with creating and nurturing open-source projects. There is also much more to the process than just firing the code out onto GitHub and thinking that you’re suddenly the owner of an open-source project. Open code and open-source community projects are very different.

Open-source code along with open-source community collaboration is potentially one of the most powerful ways to accelerate the development of your product, script, idea, or documentation. It’s much better to be able to work together with an open community of folks who want to make products more usable and more feature-rich.

Jono Bacon provided a great guide on some key steps to creating effective collaborative projects through open source that I’ve used as a guideline recently. Jono is a long-time contributor and proponent of open-source communities and has literally written the book on it. I was lucky enough to have Jono on the GC On-Demand podcast to talk about open-source communities and more. It’s a must-listen in my opinion!

Make sure that you take a little time and look at the open-source licensing options that are available to you. There are lots of examples and also lots of folks in the community who would love to help you get started. That is one of the great things about community. We are all in this to help each other get better, every day.