Open-sourcing is fun; licensing is hard.
A common question we get here at SparkFun falls along the lines of, “Can I use your hardware files for X?” or, “Is it cool to use your code in Y?” These are often also accompanied by the classic, “Did you know so-and-so is using your files for Z?! What are you going to do about it?!” The simple answer to all of these is to check out our licenses. Of course, if you’re not a lawyer and don’t understand the legal mumbo-jumbo, or not familiar with the licenses we use, this can be intimidating. It becomes even more confusing when you realize that we use two different licenses - one for our software/firmware, and one for our open-source hardware.
So with all the confusion and fear, what are some of the reasons people license their work?
Figuring out what type of license to use is a deep rabbit hole that’s easy to get lost in. For example, take a look at the GNU.org license list - I lost count at 40 different licenses, and that was just in the GPL-Compatible Free Software License section. That's just for software! Then there are different licenses for documentation, hardware, databases, copyright versus copyleft - it’s a lot to wade through.
There are plenty of folks out there trying to make licensing easier, and will even walk you through choosing a license for your project. GNU has their suggestions; InMojo has theirs; Choose A License walks you through it one question at a time; Creative Commons will walk you through choosing one of their variations; the list goes on. The Open Source Hardware Association is also currently collecting feedback on a certification system for open hardware that will hopefully make the licensing terms of each project clearer, and hopefully will create more good models of properly licensed projects.
You can even make your own license if you’re feeling brave/foolish (and no, despite what Google may suggest, this license maker isn’t going to help protect your electronics project or code).
These of course are all just starting points for thinking about licensing. If you intend for your licensed material to be a boiler plate for others' projects, you need to consider the pros and cons of each license as your code/design files proliferate in the wild.
While we can’t tell you what license is best for your project, we are trying to make it easier to understand how you can use our materials. Our hardware falls under the Creative Commons Share-Alike1 (meaning you can use our files as long as you maintain attribution to us for the original idea), our images are licensed under Creative Commons Attribution-Non Commerical ShareAlike (no commercial use here, sorry), and our firmware we license under...well, a lot of things.
We haven’t had a consistent standard of licensing our code over the years as a company. Some of this is due to the fact that we’ve based our code off of others’, thus requiring us to pass along their licenses with our updates. Some of it is due to the engineers having a good, bad, or mediocre day, and choosing a license based on that. In recent years, we’ve tried to stick with Beerware. Unfortunately, this doesn’t satisfy licensing requirements for some of our customers, and isn’t considered SFW for all of our customers either. For those looking for explicit legal terms, Beerware also doesn't provide that.
We argued about switching to different licenses such as Hamware (just like Beerware, only ham based - the vegetarians of the group weren’t fans), the WTFPL (NOT SAFE FOR WORK!), Creative Commons, GNU…see above on the difficulty of licensing.
We have come to the conclusion however that the MIT License still grants our users the ability to do what they choose with our code, but in more legal sounding terms that will work for proper licensing requirements. Moving forward, we are going to be licensing our example code under this1.
We’re also working on getting our documentation and licensing more standardized across all of our code and files (check out all of our new GitHub repos that we have been adding!), so hopefully this helps you, our customers, with modifying, hacking, and otherwise using our code and board files. If you ever catch us slacking, feel free to open a pull request or issue on GitHub, or reach out over one of our many feedback channels and let us know.
1_These all come with the clarifier ‘usually'. We do a lot of collaborations, we act as a distributor for many products, and there are no guarantees that the licenses will be the same from product to product. Please always read the fine print on the documentation. If you ever have questions, ask!_