Open Discussion: Best Practice for Mislabeled Open Source Projects?


In looking around for examples of great open source hardware projects, we came across an unexpected number of projects and products labeled as open source hardware that, upon closer inspection, actually turn out not to meet the definition. Often, they’re using an inappropriate license— typically a “non-commercial license,” which is not only unenforceable but explicitly incompatible with open source values. Sometimes, they haven’t released the design files. Sometimes, a person has apparently misused the term “open source” to mean “closed and proprietary.” And sometimes you might see the open hardware logo used without any substance to back it up.

But what (if anything) can or should be done about it? We’d like to solicit your input as to the best ways to approach this problem.  Perhaps there are not any easy answers.

As a baseline, we think that it’s important to address the problem, and to do so earlier rather than later. To mislabel a product for sale as open source hardware may constitute false advertising, illegal in the US under state and federal law. In noncommercial projects where nothing is for sale, misusing the terms may help to set precedent that can damage the community’s understanding of open source. For instance, if enough people see non-commercial licenses on things labeled as be open source, they may assume that it is acceptable.

If you happen to know someone behind the project, you might consider contacting them directly to start a dialog about what it means for something to be “open source.”  Or, you could (hint hint hint) send them a link to this article, letting them know that you found it interesting!

But, what if you don’t have any personal connections to the people involved? It’s certainly not as easy. Sometimes you can initiate a dialog with a company, perhaps by asking about their design files or licenses. At the other end of the spectrum, people sometimes bring up options like public shaming. In our view, shaming is harmful to the open source community, and should be considered a last resort akin to violence. Rather, we as a community need to work towards positive ways to nudge people toward doing the right thing.

Please let us know what you think: what should you do when you come across a project mislabeled as open source hardware?

18 thoughts on “Open Discussion: Best Practice for Mislabeled Open Source Projects?

  1. Prepare a letter and/or email that can be sent to the offending party that contains simple bullet points of the standards they need to meet to use the term open source with their product. They may be unaware or think that because they use material from others, that is all that is required to call their product open source where far more is required. Indicate the sender is willing to work with them to meet these requirements but should they continue to incorrectly use the logo, the open source developers may be required to take action.
    Leave the actions taken open as the nature of the actions to take will depend on the nature of the violation. Post the notice where other developers can obtain it when needed.
    I am not qualified to write this notice because I am not fully aware of all that is involved in open source and you won’t catch me using the logo unless I learn far more about the process.

  2. What Dena said above sounds reasonable. My guess is you have three main types of violators: small projects that are mostly ignorant, the “non-commercial” crowd, and deceptive users trying to make a quick buck. The last group probably nothing will stop, but the first two might be greatly reduced by a polite offer to help. A lot of small projects (one or two people) often don’t update websites as often as is needed–a lot of work to be done, and then have, for example, the files for version 1 posted but are selling v2. The non-commercial crowd might need to be pointed in another direction, perhaps one of the creative commons licenses, that better reflects what they do.

  3. Can you say more about the details of the projects that were using the words, licenses and/or logo incorrectly without veering into public shaming? It would be helpful in the discussion if we knew, for example, what kind of mistake is most common, or who is most likely to make a mistake.

  4. Essentially, my thoughts mirror Dena’s post, above.

    I would contact the ‘offending’ company/group/person with an email that begins something like “I believe you may have inadvertently misused the ‘Open Source’ ethos.” (I’d have to do something better than that, though). The email would go on to explain HOW I think they’ve transgressed, and include links to the appropriate terms and conditions, as well as to the governing body/ies. It would then go on to state that I had contacted those bodies with my concerns.

    Above all, I would be polite, saying and suggesting that the perceived transgression must have been inadvertent.

    If I turn out to be wrong (because, let’s face it, I’ve never read the terms and conditions), I would send another email, with an apology.

    I also think that the ‘official’ Open Source Logo should contain a link to the terms and conditions – so any appearance without that link would be cause for concern.

  5. It seems to me that this is the sort of thing trademark is meant to protect against; specifically, OSHWA ought to have trademarked the logo (maybe it still can?) and then offered it licensed under the terms that it is only used for products and projects which meet OHW standards, which I believe would then provide a means of legal recourse so that we can protect consumers and engineers and Makers who want actual Open Hardware.

    But IANAL.

    1. That’s along the lines I was thinking. The open source project could probably do with some sort of managed certification program, something like the Energy Star program for consumer electronics or the 80 Plus programs for PC powersupplies. Designers submit their products to the organization in charge of the logo program, and if they pass they receive authorization to use the mark. Who knows if OSHWA can, or is even interested in, doing something like that though.

  6. IMHO, calling something open source hardware doesn’t require anybody’s permission. Nor does it require the specific use of anybody’s license or guidelines.

    Now, if someone is violating the terms of use for the OSHWA logo then maybe the OSHWA should take it up with the offending party.

    But, OSHWA doesn’t own the term Open Source nor can it singularly define what it is. So, I am not sure there is anything you or anybody else could or should do.

    1. OSHWA does not own, nor claim ownership of the term “open source.” That term has been defined by the Open Source Initiative, which has stewarding the definition as one of its key purposes. You can read more about it here:

      OSHWA is an educational institution. It does not own (or claim to own) the term “open source hardware,” nor did it create (or claim to create) the open source hardware definition. OSHWA does have educating people about the definition as one of its key purposes.

      Also, it is worth noting that OSHWA’s logo (visible at the top of their page here: ) is not the same as the open source hardware mark. If someone were using OSHWA’s logo inappropriately, I’m sure that OSHWA would step in to address the situation.

  7. All too often, open source advocates (both purely software and regarding hardware/firmware) have initiated dialogue that’s hurtful, accusatory, threatening, or strikes a legal/ligitous tone. Even when such communication is factually, logically and legally perfect, the net effect can turn out to be an adversarial relationship that’s utterly unproductive. Sometimes the results are worse than if no such communication had ever occurred.

    Specifically regarding “what should you do when you come across a project mislabeled”, I would argue the very best thing anyone could do is begin a 3-day to 1 week cooling down and fact collecting period. Immediately communicating with *anyone*, even other open source advocates, is almost certainly not the best course of action. Writing an angry message, even to a receptive audience (eg, leading to the public shaming stuff), might feel good, but it’s almost certain to do more harm than good.

    A slow, deliberate and well thought out plan is really the best way to have any chance of a positive outcome. That cooling down and fact collecting period should involve not just looking at licenses and files, but learning who the real people are, who makes the actual decisions, and what their motivations really are.

    These matters are difficult. Like any technical matter, a well thought out plan executed carefully has a much better chance of success. But these matters are unlike technical projects, where you can try over and over again, where persistence pays off. With humans, a first impression can forever set the tone of your interaction, and it can even color all future communication other unrelated parties may have on the same subject.

    Ultimately, your communication will consist of words. Choose them wisely.

    1. “Ultimately, your communication will consist of words. Choose them wisely.”

      How true indeed. Yours are certainly some of the most wisely chosen that I have read on the subject.

    2. I figure as well that carrying on an interrogative interaction bypasses why things happened in the first place. People are usually good, and are very typically human in their actions.

      I can fully see somebody going ‘oops, totally forgot to add that’ or getting tied up with legal in their corporation over licensing.

      As for solutions, it would help if this were fixed at the start. Possibly a ‘help me make my project open source hardware website’, or a sort of ‘Open Source Hardware Checklist’ to use before publishing in a simple and easily consumable format (perhaps something in a poster format?)

    3. IME, if you complain politely, you will get a polite response be ignored. If you complain rudely, you may get a rude response, but still be ignored.

      Of course, the people who are subject to complaints (maybe Paul is one?) would prefer the former.

      Usually when people choose an NC license and call their project “open” or “open source”, they are doing so deliberately and it is not a mistake.

  8. I should start first by saying that the comments here are my own view, and not a position by any other organization. These are definitely not the views of TAPR, of which I am a Director – an organization that published one of the first Open Hardware Licenses, as well as an almost identical Non-Commercial Open Hardware License. I have been a member of the Linux community since the Minix days [with my email found in the minix email list from around the time Linus released Linux], and have been a member of the Ham Radio community for about the same length of time.

    Firstly, the use of the use of the Open Hardware License has strict rules that MUST be followed including the user being obliged to permit commercial use of their design.

    When it comes to limits on commercial exploitation, it is my view that the person who owns the IP has the right to release this IP how they see fit. And this includes the right to release it with conditions that others may not commercially exploit the IP, either forever, or for a time.

    When Netscape originally Open Sourced their software, they did so by allowing people to see the code and change it, but not to use it commercially against them. This was the original definition of Open Source. It is only since then have people decided that Open Source has no limits. I am a supporter of the Original definition. It was only in the months after this original usage of Open Source was it decided my many people that commercial exploitation should not be able to be limited.

    The importance of being able to Open Source hardware with non-commercial limits is probably more important than with software. With software the economic losses for having IP used is generally limited to the time that the programmers have put in.

    With Open Source hardware, the developers occasionally wish to exploit the designs in order to offer them to a community. In this case they make a commitment to producing a design at a significant commercial risk. The cost of these designs can exceed $500 per unit, with hundreds of units to be produced. The risk that this imposes on those producing the device, particularly if it is on a cost basis is significant. Being able to place limitations on the commercial exploitation allows the risk to be managed.

    Whilst TAPR has the OHL (Open Hardware License) and the NCL (Non-Commercial Hardware License), the organization has decided that the NCL has not been as beneficial as hoped and recommends that the OHL is used instead. Having said that, I am a firm believer in the NCL, which has all the aspects of the Open Hardware License with the exception that it is non-commercial.

    Darryl Smith, BE, VK2TDS
    Sydney, Australia

  9. Great article Lenore! I’m working on a piece about open hardware right now and this helps get me thinking.

    Do you have a few open hardware licenses that you generally recommend for people getting started with open hardware?

  10. I have made mistakes when picking licenses.

    I’m not a pro in intellectual property law but I’ve made a hobby of it, reading as much as I can. And still, it’s hard. There are dozens of Open Source licenses, and dozens more permissive licenses that are not Open Source approved. Some OS licenses have more in common with the non-OS permissive licenses than with each other. Until recently there were a lot of words written but not much plain language to help outsiders differentiate. (Even now, when researching licenses you’re equally likely to hit a flame war as a knowledgeable legal evaluation.)

    So it’s hard to pick a license, especially one that does everything you want. And for some projects you can’t pick just one. Copyright law applies to code, but a different set of IP laws apply to hardware. So you often need to pick two, and they’re never exactly the same in terms of permission.

    Also I like to experiment.

    So I’ve made mistakes when picking licenses. I’ve said things were Open Source when they werent.

    And people have taken issue with my mistakes. I’ve had perfect strangers insult and threaten me on public forums. That wasn’t a very good way to get my attention. (It wasn’t until a friend pointed me to the flames that I even knew about it.) And it was a lousy way to get me to pay attention to the issues. (My reaction when strangers insult me is to ignore them, not spend lots of time reexamining my decisions.)

    On the other end of the spectrum: One day I got an email from someone at Creative Commons. I didn’t know her, she was just as much a stranger as the person who called me names. She had seen one of my projects and suggested that maybe I could make a better decision about a CC license on a project. She explained why I was probably making a bad choice and linked to more thorough information in plain English. She was right. I had made a bad decision. Her approach was super effective, and I changed the license on that project. She has my sincere thanks.

    Part of the fallout from these events (and others) that is I usually pick a simple and non-restrictive license for things (MIT license is my current fave). But what do I do to people who even violate those simple restrictions? First I assume they made a mistake, just like I have. It was hard to pick a good license, it can be hard to be certain you’re in compliance. When I reach out to them a little understanding seems to go a long way. Most violators seem to have made a legitimate mistake.

    The ones who don’t respond, well… Then we’re in the arena of license violations and the next step, if I decide it’s worth it, is to talk to a lawyer. Thats a different discussion, but it’s a pretty high bar, and once you decided to do that, the discussion and result is largely out of your hands.

  11. I am afraid the horse has already bolted, probably 95% of claimed “open source” products I have looked at are using an NC license.

    I have tried emailing people, as politely as I can, but a typical response is “open source means whatever we what it to mean”. Even people using the OSHWA logo specify “non-commercial use only”.

    There are many people like Darryl Smith who believe that a NC restriction for hardware is actually a good thing, even though freedom for commercial use has been part of nearly all Free or Open Source definitions I know of, so there is a fundamental difference of opinion over what OSH should be.

    The fact is companies choose an NC license for commercial reasons : they want exclusive rights to make money. They also choose to call it “open source”, because that is cool and has marketing appeal.

    In the hardware space, the term “open source” has become a pretty meaningless term as it is so widely abused. The only thing that would dissuade them is a legally enforceable trademark, which ironically OSHWA seems unwilling to commit to.

    I think unless an organisation takes a firm and prompt lead like FSF does for GPL, the “open source” concept in hardware is pretty much dead.

    We would need to invent a new term like “Real Open Source” and trademark it, but while so many companies are doing “non-commercial open source”, and the majority of customers don’t care, it may be a rather artificial exercise.

Comments are closed.