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!_
Very glad you moved to MIT license. It creates the least problems for using firmware code. There is no issues with merging with more restrictively licensed code and does not limit usage at all. Thanks.
Oh, here is another license you might like: DBAD License
Hah, that's a great one! Very useful for my personal projects. Thanks for sharing!
How does this all work when most of the code that gets posted for Arduino is really firmware which in my opinion hardware. I have always seen this be a very interesting conversation in industry because the firmware is required for the hardware to operate at the basic level for projects that use them.
Really it is a matter of whether or not you can copy the firmware as it is, or whether you have to go digging in the datasheet to find the information needed and write your own firmware. Also, if people are posting the Arduino code it is usually to share. I'm not sure I've ever seen Arduino code published somewhere where you can't use it. Really this is true of most code. Also most of the "firmware" you see will read data and then output it, but a project is rarely that simple. You usually need to read the data and then do something with it so it tends to be be merged into your code. But this is one of the reasons most Arduino code and all our code tends to be under such liberal licenses. We want you to be able to use it in the way that works best for you.
Oh I understand that. It was more tongue and cheek because firmware, which I consider to be hardware, not software, is not covered under the hardware license?
You state in the post that "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)" However that's just one of the two key requirements of "ShareAlike." If you just want attribution, that's the Creative Commons Attribution license (https://creativecommons.org/licenses/by/4.0/). The share alike provision also requires that "If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original." It's a copyleft license, whereas the attribution license (and the MIT license) do NOT require that the user share any changes back to the community under the same terms.
Well, it's your code - there's nothing stopping you from offering it under multiple licenses. Beerware or WTFPL for the hackers, and MIT for the corporate suits.
Beerware should be a licence that sits under all open hardware licences. Paying it forward is the way to go. We're all here on the shoulders of giants and should at least acknowledge those whose shoulders we're standing on. For me open source licencing is like permission to copy the smart kids and it means I can see further.
I've always like Beerware for my code/scripts I've written over the years and give to people. Back in college and when I graduated, I didn't care what people did with my code as long as they "pay it forward" with beerware.
I am a firm believer of karma and paying it forward. You don't owe me anything (unless you wan to give me something because you want to), but I just you to help others like I helped you.
I was actually writing code the other day and decided to throw a quick Beerware license up there. Well as a result of a typo Beefware was born. Since I'm not a huge fan of beer, but do like steak and burgers my preferred license is now Beefware. But I agree, it is nice to just write code and let people use it how they like, if one day someone buys me a burger or beer I won't say no though.
I like this as an alternative for Beerware. Does that mean vegetarians get "Tofuware" ? >_>
How about Beetware?
Careful, somebody might think it is an acronym: ToFU Ware.
Name it something we all like? Pizzaware or Cookieware? Need gluten-free? There is a pizza or cookie for that. Hate your veggies...you are in luck, there are plenty of options for you. If someone comes on here and says they don't like pizza or cookies...well there is no hope for a new name. :P
I think this could be on to something: What is something we all like? hmmmm...
If someone chooses to provide some support to Sparkfun's OSI, they can which helps fund more projects like these!
I think in generic terms it's known as Donationware
There are others, but we may fear to swim in these waters:
I'm very glad SparkFun is switching licenses. Beerware sounds cool and all, but it actually causes quite a bit of problems. For example, if you write a beerware license and I fork that license and modify it and somebody else uses it, do they owe two beers? If I give you a beer once but then find your code useful again, do I have to give you another beer? It's not clear how derivatives are to be handled.
The user supplied libraries are what makes the Arduino community tick--it makes it much easier to use/incorporate that library you worked on if its an OSI approved license.
Anyway, thanks SparkFun and all the open source software contributors out there. Let's have one last beer celebrating the move to an official OSI license :p