EEVblog Electronics Community Forum

EEVblog => EEVblog Specific => Topic started by: EEVblog on September 09, 2016, 08:02:34 am

Title: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 08:02:34 am
There are a few big problems with Open Source Hardware and usage of the Gear logo. Dave has a new solution!

Download the new logo here:
https://www.eevblog.com/oshw/ (https://www.eevblog.com/oshw/)

https://www.youtube.com/watch?v=5wrSXCBdalc (https://www.youtube.com/watch?v=5wrSXCBdalc)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: neta on September 09, 2016, 09:12:19 am
Hi. Longtime lurker taking on this topic as an excuse to come out.

Big thumbs up!  :-+

The ambiguity of the current OSHW interpretation is actually a cause of concern in a project I'm working in.
There are plans to release the product under the "open hardware" umbrella; the problem we are facing with that, are the constraints that imposed upon the firmware IP as well, which would kinda cripple the revenue model as well.

Releasing an OSHW-compliant board with a crippled open source firmware or a non-OSHW one with a closed-source one, while formally correct, would not really solve any problem.

An OSHW logo with compliancy specification slapped on it: that would actually solve the problem.

CreativeCommons comes to mind. It was actually created to solve a similar problem in the same way as Dave proposes here, and proved to be the best, most flexible open licensing scheme ever: just slap some selectors on it! ;)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: WattSekunde on September 09, 2016, 09:14:29 am
Hi Dave,
very nice and simple Idea. For more simplification I would embed the logo into a qr-code with a link to all the open source data.? Everyone could check with the smartphone if the open source data really is available.

OK, the sample QR is a quick one with the logo a bit to small... now it's better.  ;)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: suku on September 09, 2016, 10:10:35 am
I really like the idea of using a QR code, but doing so you must ensure that there are no vias piercing the logo on the PCB, which can be tricky in my experience...  I'm not sure how big a QR stamp should be to be safe to read with older phones/lower quality cameras...
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 09, 2016, 10:20:17 am
I was also thinking of something that used the teeth of the gear logo - perhaps a colour code - but I do like the simple letter scheme and the alternate letter colour to indicate a level of openness

One suggestion I'd like to offer is for the use of more visible letters - by moving them more towards the centre they can be a bit larger.  Just an idea.


But, yes, more descriptive variants of the gear logo are essential.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 10:34:32 am
Adding a configurable gear logo is an idea I would definitely support. B one suggestion is to add a second character to each of Dave's suggestions. Such as an 's' for source. So you get SS, PS, ....
If this gets too hard to make clear on the silk then perhaps a '*' . Although in that case I would interpret a '*' as "read the fine print" - meaning non source. This leaves Dave's suggestions to mean with source.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 09, 2016, 10:37:12 am
Great idea. I actually started working on a generator, I'll post it on github and share a link here.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: mxmarek on September 09, 2016, 10:53:57 am
Maybe just cut the teeth which are not compliant.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 10:56:33 am
Shouldn't that have been a blab?

Anyway, that's too complicated by far.

1) Idendify and describe the attributes that can be opened.
2) Now you can simply sum the openness. ie. 5/15
3) start with an outline gear and fill from left to right, as in a meter needle, to the openness ratio.
4) annotate with creative commons codes ie. 5/15 CC BY-SA
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 10:57:42 am
Maybe just cut the teeth which are not compliant.
This would be clearer than my suggestion. I've now got a mental image of lots open source kickstarter projects having to use a gear with no teeth. Ha.


Sent from my SM-N930F using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 11:06:23 am
Shouldn't that have been a blab?

Anyway, that's too complicated by far.

1) Idendify and describe the attributes that can be opened.
2) Now you can simply sum the openness. ie. 5/15
3) start with an outline gear and fill from left to right, as in a meter needle, to the openness ratio.
4) annotate with creative commons codes ie. 5/15 CC BY-SA

Would the scoring system have to create a unique number for each combination since there would be more than one attribute combination that could score 5/15?

Use the decimal equivalent of a 5 bit binary number where each bit of the number represents an attribute?

Would prefer toothless gear idea above.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 11:14:39 am
Would the scoring system have to create a unique number for each combination since there would be more than one attribute combination that could score 5/15?

Use the decimal equivalent of a 5 bit binary number where each bit of the number represents an attribute?
Crazy! It doesn't matter on the logo. The logo gives you a simple clue. If you give a shit after that you go and look at their docco.

It's a logo, not a specification. And it's 36mm2. On a silk screen screen printed at 100dpi.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 09, 2016, 11:15:37 am
Rather than toothless, perhaps have them a different colour - otherwise it looses the gear logo 'look'.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:17:40 am
Hi. Longtime lurker taking on this topic as an excuse to come out.

Welcome!

Quote
An OSHW logo with compliancy specification slapped on it: that would actually solve the problem.
CreativeCommons comes to mind. It was actually created to solve a similar problem in the same way as Dave proposes here, and proved to be the best, most flexible open licensing scheme ever: just slap some selectors on it! ;)

Yep, very similar to CC.
Many people are saying the same thing, so it seems to be resonating.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 09, 2016, 11:18:22 am
It's a logo, not a specification. And it's 36mm2. On a silk screen screen printed at 100dpi.

This is perhaps the single most misunderstood aspect of any graphic design - how the result translates into the scale that will be used.  36mm2 is not very big at all.

Even in larger formats, small detail can get lost - and just makes the whole thing more difficult to 'take in'.  The KISS principle must be respected.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 11:21:50 am
Rather than toothless, perhaps have them a different colour - otherwise it looses the gear logo 'look'.
Green = attribute original source available
Amber = attribute source in PDF
Red= attribute not opened.

Making it visual on gear is my preferred option.
It could be argued that using a system  requiring people to look up which attributes created the total score would fail since projects have misused the logo when not opening the design to right level. If people researched the openness before supporting a project then we wouldn't be in this mess.

Making it a direct visual interpretation is still better IMHO.

Edit
How easy is it to have different colour silk on a PCB, would this affect cost due to additional process or is this more like a modern day printing stage that can change colour on the fly?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:21:59 am
I was also thinking of something that used the teeth of the gear logo - perhaps a colour code - but I do like the simple letter scheme and the alternate letter colour to indicate a level of openness

The first time this idea popped into my head it was to use the teeth as either colour coded or missing, or numbered etc (e.g. "levels of openness"). But I ended up with letters that were more descriptive of each hardware requirement.

Quote
One suggestion I'd like to offer is for the use of more visible letters - by moving them more towards the centre they can be a bit larger.  Just an idea.

Underneath the logo would work just as well.
It could be fancy like the Creative Commons one, even an auto generator program that gave you the right logo based on your requirements.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Smokey on September 09, 2016, 11:22:25 am
I'm going to be the kill joy here.... Everyone quit holding hands and singing open source kumbaya...
Who cares.. release something... don't release something.. "open source" .. "open hardware" ..  it's all just buzz words like  "Cooperative synergy".  There is no new "open hardware community" movement pushed forward because of a gear logo and some club guidelines.  More buzz words.  It's the same nerds that have always been here doing the same thing they have always been doing.  Go make your breakout boards and release them to the world and be happy, logo or not.
Dave is on the right track with the corporate ideas regarding releasing stuff.  Get off their back and be grateful you get anything, logo or not.  Anyone that expects a company to always give away all their stuff has never spent their own money developing an actual product.  R and D is an expensive investment.  Tektronix and a bunch of other equipment manufacturers didn't make a big stink about releasing essentially full documentation for their stuff back in the day.  They didn't need to make a "look what I did" logo and spew about it.  They did it because it added value to their products and it would get them more sales.  If you have a product and you think it would add value to release some aspects of the design then do it and move on.  You don't need anyone to dictate what you need to do or how you need to do it.  There doesn't need to be rules.  You don't need to join a club, especially when the club is an arbitrary formless cloud of internet opinion that can and will change their minds at will.
And don't be shocked if you give away your work and someone uses it to make a profit, pirated logo and all.  You had your chance to make money from your ideas, and you should have talked with a real lawyer before assuming that some guys on the internet knew what they were doing when they made their club license.
The only way any of this "open hardware" gear logo stuff adds any value at all is exactly what Dave described with an official, legally binding, fully defined (and not hopefully not asinine), set of rules and regulations with the most important part of it being the ability to actually follow through with the legal defense if there is a violation and enforce it in court.  Without that it's worthless and all the time spent complaining on the internet about improper use of a logo could have been used actually making something useful, starting a company, and making some money.... or give your stuff away... it's up to you. 
The act of sharing your work with others is awesome.  I fully support that as an end in itself.  Sticking on a logo, or having unenforceable rules, or cooperative synergy adds no extra value.

end rant.  Commence the open source kumbaya...
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:23:20 am
Great idea. I actually started working on a generator, I'll post it on github and share a link here.

Sweet!  :-+
Possible to have it generate under the logo as an option?, many people are suggesting that as a better way to go.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:24:28 am
Maybe just cut the teeth which are not compliant.

I originally thought of missing teeth but figured that would corrupt the logo. I think the descriptive letters are a better solution.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:31:20 am
Who cares..

A lot of people do, like it or not.
You don't have to care of course, and that's fine.

Quote
If you have a product and you think it would add value to release some aspects of the design then do it and move on.  You don't need anyone to dictate what you need to do or how you need to do it.  There doesn't need to be rules. 

And that's why I think this new logo works. Get rid of the idealistic everything must be open philosophy and let people just do what they want to do, but at the same time offer a nice logo to easy show what they are doing at a glance. There is value in having a common format like that.
 
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 11:31:22 am
One draw back with the configurable logo is the number of permutations especially when coding original source or PDF for each attribute.

Sent from my SM-N930F using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 11:31:43 am
So, under this logo, simply put the writing

2/7 CC BY-NC

or whatever license you choose.

edit: I lifted the logo from http://www.oshwa.org/open-source-hardware-logo/ (http://www.oshwa.org/open-source-hardware-logo/) without permission.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:35:04 am
Skywodd on twitter has suggested symbols instead of letters.
I like the look of that, but probably a bit big?
https://twitter.com/skywodd/status/774197283747303424
(https://pbs.twimg.com/media/Cr6AFHnWYAACwUN.jpg)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 11:36:14 am
So, under this logo, simply put the writing
2/7 CC BY-NC
or whatever license you choose.
edit: I lifted the logo from http://www.oshwa.org/open-source-hardware-logo/ (http://www.oshwa.org/open-source-hardware-logo/) without permission.

Except that it doesn't tell you what things are being opened.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 11:44:01 am
Except that it doesn't tell you what things are being opened.
Thread got busy quickly.

You are correct. It's on a PCB. There isn't room for specifics. The community defines the things that can be opened; you just tell us how many of them are. If anyone cares any more than that they are well capable of looking it up in your docco.

Keep it simple. It's a logo, not a legal brief.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 09, 2016, 11:46:39 am
This is basically a religious debate about just what "open source" means.

I can't say that I can agree with you.

The original (current) position is either all or nothing - just black and white.  The reality, however, is NOT so clear.  There are many shades of grey.

To exclude these shades from the concept of their being some degree of openness, indicates a lack of appreciation for an organisation/individual that has at least made an effort.  Without such recognition, such contributors are less motivated to offer anything ... and ANYTHING offered will make a difference!

It's a practical step.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 09, 2016, 11:52:35 am
Sweet!  :-+
Possible to have it generate under the logo as an option?, many people are suggesting that as a better way to go.

It's up: https://maciek134.github.io/oshw-logo-gen/ (https://maciek134.github.io/oshw-logo-gen/)

Sure, for now it generates on the logo - I'll add an option to generate under the logo (and probably some styles) after work. Can someone provide an example of how it should look like (under the logo)?

I can also make it generate the icons. I guess it should also be possible to export PNG - I used Ubuntu font since it's similar to Arial Bold and it's Free (you don't get Arial on linux for example), but SVG export means you have to have the font installed on your system.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 11:56:24 am


Except that it doesn't tell you what things are being opened.
Keep it simple. It's a logo, not a legal brief.

For me it's more of a symbol which is supposed to convey a meaning. I always come across a symbol whose meaning I don't know. I always make a mental note to look it up. Never do.

I would like to see the legabillity results before i decide. Even if it failed, I would consider changing the logo to make the configurations clearer and not bother with having to look up openness in a document. Purely because there are people who are as lazy add I am.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 11:58:41 am
Sweet!  :-+
Possible to have it generate under the logo as an option?, many people are suggesting that as a better way to go.

It's up: https://maciek134.github.io/oshw-logo-gen/ (https://maciek134.github.io/oshw-logo-gen/)

Sure, for now it generates on the logo - I'll add an option to generate under the logo (and probably some styles) after work. Can someone provide an example of how it should look like (under the logo)?
That was quick. Looks very clear to me. Good job.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 12:02:49 pm
You are correct. It's on a PCB. There isn't room for specifics.

i was also thinking that the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Also, font size is a problem, so text below the logo is probably the only option here.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 12:07:29 pm
You are correct. It's on a PCB. There isn't room for specifics.

i was also thinking that the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Also, font size is a problem, so text below the logo is probably the only option here.
If legibility is a problem, you don't really need the letters. Is the attributes meaning is assigned to the tooth position then you could just have a circular dot in the tooth to signify the attribute is open. This could be scaled down and still be clear.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 12:08:26 pm
For me it's more of a symbol which is supposed to convey a meaning. I always come across a symbol whose meaning I don't know. I always make a mental note to look it up. Never do.
Then you don't care. Like nearly all people, I'd wager. That's fine. But give me a simple scale over a cryptic code any day.

I would like to see the legabillity results before i decide. Even if it failed, I would consider changing the logo to make the configurations clearer and not bother with having to look up openness in a document. Purely because there are people who are as lazy add I am.
Are you telling me you'll remember what all those letters mean? I've forgotten already. There are many more important things in my life than the specifics of nearly all open hardware projects. My eyes glazed over when Dave demonstrated his idea.

However, his idea does have merit as long as the specific information is in the right place: The website or other docco. Not the logo. The logo's function in this instance is to tell you there is more information available, while giving you a clue about the projects openness.

Go get a board that has a gear logo on the silk. How legible are your letters going to be?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 12:13:52 pm
the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Hmmm.

You're right. So there goes the whole idea really.

I guess it's wise not to include the logo at all if you aren't sure.

You don't have to use the logo to open your designs though.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 12:16:00 pm


For me it's more of a symbol which is supposed to convey a meaning. I always come across a symbol whose meaning I don't know. I always make a mental note to look it up. Never do.
Then you don't care. Like nearly all people, I'd wager. That's fine. But give me a simple scale over a cryptic code any day.

I would like to see the legabillity results before i decide. Even if it failed, I would consider changing the logo to make the configurations clearer and not bother with having to look up openness in a document. Purely because there are people who are as lazy add I am.
Are you telling me you'll remember what all those letters mean? I've forgotten already. There are many more important things in my life than the specifics of nearly all open hardware projects. My eyes glazed over when Dave demonstrated his idea.

If you can design a PCB of sufficient complexity/usefulness that people would appreciate you open sourcing, then I would argue your're intelligent enough to remember the meaning of a few letters or positions (see my last post).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 12:23:29 pm
If you can design a PCB of sufficient complexity/usefulness that people would appreciate you open sourcing, then I would argue your're intelligent enough to remember the meaning of a few letters or positions (see my last post).
It's not for the bloody designer. It's for the consumer. Someone with a passing interest. Anyone with a deep interest already knows what you've bloody open sourced.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 12:25:25 pm
You are correct. It's on a PCB. There isn't room for specifics.

i was also thinking that the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Also, font size is a problem, so text below the logo is probably the only option here.
I suppose the public could copy the documentation before the change and fork from then on. This assumes the documentation is version controlled and accessible (the project website hasn't been deleted). You could keep a clone of the site but it's starting to sound like it wouldn't be with the effort.
Baking it on to the PCB is hard coded :)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 12:29:06 pm
Then you don't care. Like nearly all people, I'd wager. That's fine. But give me a simple scale over a cryptic code any day.

The problem with a scale is that the actual things be opened matter.
You could have a 4/5 scale open project but that 1/5th is the showstopper for you, you need to know what that is.
A scale has far less meaning than letters/icons in this instance.
Just image creative commons using a scale CC-4/5's is meaningless.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 12:29:30 pm
If you can design a PCB of sufficient complexity/usefulness that people would appreciate you open sourcing, then I would argue your're intelligent enough to remember the meaning of a few letters or positions (see my last post).
It's not for the bloody designer. It's for the consumer. Someone with a passing interest. Anyone with a deep interest already knows what you've bloody open sourced.
Sorry I was referring to you saying you forgot the meaning. I assumed the general public with an interest in this topic were intelligent enough and could remember the meaning of a few letters.

I also assumed you were one of these people. (There I go assuming again, making an ass out of you and me). Let me know if I'm wrong, im sure you only said it to make a point.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 12:31:12 pm
It's not for the bloody designer. It's for the consumer. Someone with a passing interest. Anyone with a deep interest already knows what you've bloody open sourced.

Actually, it more for the desings and those technical people in the field than the consumer. Just like the consumer doesn't care about Creative Commons letter codes, similar thing here.
This system allows your peers in the field to see at a glance how open your project is, and I think that's important.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: jolshefsky on September 09, 2016, 12:42:12 pm
I admire your solution, Dave, but even then there are nebulous edges in the specifics. Like you say, the schematic can be anything from a PDF (or PNG, worse yet) all the way to a complete ZIP of the raw design files. And then the raw design files could be for an expensive commercial product ... In other words, every single letter on the logo now encapsulates the same nebular problem that the whole logo does.

And this is the same problem as in any community logo. I usually see it with foods, "Organic" or "Non-GMO" for instance. Even "Made in..." country-of-origin is fairly meaningless since virtually no project has 100% of its raw-material-to-product stream existing in one place: does "made" mean "assembled" or does it mean "designed" or does it mean "all parts sourced in" or does it mean "we have shill companies that front parts from overseas so we can claim it's all local"?

Fortunately since OSHW is a tech-specific issue (assuming nobody is making OSHW furniture off-grid, at least) then one can expect there to be a website. As such, just include a URL on your boards and advertising. From a consumer view, this would mean you'd see a product listed as open source. Go to the URL and see what they offer. If it's not up to your standards, don't buy into it. Or do. Or go complain about it on the Internets.

The logo—from a community value standpoint—would only become worthless if it were slapped on nearly every single product. You'd eventually get to know the companies that are generally "more" open, offering better documentation, and those that are "less".
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 09, 2016, 12:50:24 pm
Actually, it more for the desings and those technical people in the field than the consumer.
OK.

I will just throw this in, and I'll leave you to it:

If you're thinking of designing something you might start by looking for similar open hardware that you can build on. If there aren't design details you move on to the next candidate. This resolves itself in a few minutes for each candidate on its relevant website; you were on the website anyway because you wanted more information about how relevant the candidate was to you.

Where does the logo come in for the technical guy? Maybe you're holding a board and it inspires you. You check the logo to see if you should waste your time on the web looking for info? Seems unlikely to me. More likely you check the web anyway, just to be sure.

The ideologist, however, prefers to buy open hardware, and would like to see at a glance how open it is.

To be fair, I haven't seen any of this raging debate you're talking about, so I actually have no idea who is complaining, or what about, so I shouldn't really have my nose in here.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: neta on September 09, 2016, 01:01:45 pm
I admire your solution, Dave, but even then there are nebulous edges in the specifics.
[...]
The logo—from a community value standpoint—would only become worthless if it were slapped on nearly every single product. You'd eventually get to know the companies that are generally "more" open, offering better documentation, and those that are "less".

You have a point, and I don't personally think a perfect solution can ever be found.

In the open source software land (where things tent be be a little less fuzzy because either you have the source to build something or you don't), OSI has approved nearly 80 licenses, each with slightly differing licensing schemes and areas of coverage.

Now that is a mess that will probably never be solved in simple terms.

Things get invariably more complex as they gain traction; at the moment the one-size-fits-all logo is getting instances where it just isn't "good enough".
I think the point is getting out something that is, without being cumbersome to anyone.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 01:05:33 pm
A designer will eventually do due diligence on any source material; I think what we're discussing is a way to do this quickly and effectively using a method that doesn't rely on information that can change in the future like a project website.
Example
(Can't remember if red pitaya originally said open source  - I checked now and they have cleared this to open source software) I spent a long time looking around their site for the schematics but couldn't find it. There was a discussion on this forum about it where others did the same. This could have been avoided.
Again the website could change its contents or be removed altogether. Having a permanent logo would at least let you copy by reverse engineering if you absolutely had to use that design.

Sent from my SM-N930F using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 01:27:52 pm
Skywodd on twitter has suggested symbols instead of letters.
I like the look of that, but probably a bit big?
https://twitter.com/skywodd/status/774197283747303424
(https://pbs.twimg.com/media/Cr6AFHnWYAACwUN.jpg)
For practical reasons, I would prefer letter over those icons, and -- similar to what skywodd did there -- i would like the letters below the logo (not in/on the teeth of the cogwheel).
Just placing the same and only logo graphic resource and centered below the letters denoting the openness of your project is much easier to realize. Needing some sort of a generator or manually tinkering with the logo graphics to create a specific logo for all places (PCB silkscreen, documentation, etc...) becomes tedious, i am afraid.

Also, there is another advantage in using letters -- you can describe the openness of a project in text form (forum posts, twitter, etc...). Something like "OSHW-SPC", for example. Try this if everyone only knows and uses icons...
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: seanhodgins on September 09, 2016, 01:42:05 pm
How about something like this?

(http://i.imgur.com/SgX14jO.gif)

The teeth represent what is available as far as your source goes.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 01:42:54 pm
I admire your solution, Dave, but even then there are nebulous edges in the specifics. Like you say, the schematic can be anything from a PDF (or PNG, worse yet) all the way to a complete ZIP of the raw design files. And then the raw design files could be for an expensive commercial product ... In other words, every single letter on the logo now encapsulates the same nebular problem that the whole logo does.
With respect to PDF, PNG and other widely used file/document formats, there is nothing nebulous with regard to openness. I get the impression that some confuse convenience with openness there...

Application-specifc file formats could become a restriction to openness if they present a barrier to access the information contained within the file (which is all to often the case, like with commercial software, or with software that is not available on the OS one chose, etc...). However, such issues could be addressed by offering a PDF (or PNG, or other commonly used "standard" file formats) version of schematics and PCB design -- not for the worse, but rather for the better of openness --, and whose presence or absence could be indicated somehow in the proposed OSHW logo...
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 01:44:38 pm
How about something like this?

(http://i.imgur.com/SgX14jO.gif)

The teeth represent what is available as far as your source goes.
Is this circular Braille?  >:D
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 09, 2016, 02:09:29 pm
I was also thinking about outline/solid teeth.  The problem with this is twofold.

First is the position of the tooth will need to be either labelled or it's position having a defined 'value'.  Second is the problem of legibility at smaller scale.

I'm leaning more towards letters under the gear symbol.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Jeff_Birt on September 09, 2016, 02:30:45 pm
How many permutations are there to open source hardware/software? Can you capture even a fraction of that with the small possible number of permutations in a tiny logo? I might build a piece of hardware that has a part that is programmed by some freely available manufacturer specific software which is not open source. So my board is 'open' my firmware is 'open' but the tool needed to program it yourself is freely available nut not 'open'. I suspect the number of possibilities of defining an 'open' HW project are endless.

Given a large amount, or endless, number of possibilities in defining what 'open' means on project 'X' one still has to refer back to the project webpage to find out the details. The exact permutation of the logo still does not provide enough detail, nor could it ever. No matter how you try to fiddle with the logo, or specifications some guys will still throw a fit as it does not suit their own definition of 'open' - funny to me how the real 'open' zealots demand that you agree with them 100% that seems very close minded to me.  :rant:
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 03:12:16 pm
How many permutations are there to open source hardware/software? Can you capture even a fraction of that with the small possible number of permutations in a tiny logo?

Given that:
a) We had nothing before
and
b) No one has mentioned any categories I left out
I'd say the proposed solution with the 7 letters is good enough to build a decent system around.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: gcardinal on September 09, 2016, 03:32:07 pm
(https://www.eevblog.com/forum/blog/eevblog-921-open-source-hardware-problems-solved!/?action=dlattach;attach=254222;image)
How about "80 Plus" ? you could just make a score from 1 to 100 - where you get points for each met criteria - this way people will know how much open source it actually is.

Edit:
Also this could be made into a generator where there is a simple QA form, after completing one you get a permalink to the form and a logo to use.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 09, 2016, 03:38:01 pm


How about "80 Plus" ? you could just make a score from 1 to 100 - where you get points for each met criteria - this way people will know how much open source it actually is.
Dave, It's a bit confusing having two topics about the same subject.
(I think it would be also nice to refer to a few things said in that topic in your video!).

In that topic I already talked about a concept like gcardinal is talking about.
See here: https://www.eevblog.com/forum/oshw/oshwa-open-source-hardware-certification-version-1/msg993439/#msg993439 (https://www.eevblog.com/forum/oshw/oshwa-open-source-hardware-certification-version-1/msg993439/#msg993439)

I think colours etc are not going to work, because it's far to complicated to implement it in hardware (silkscreen for example).
Going from 1 to 100 doesn't make any sense. It's the same step from 1 to 10, which looks a lot cleaner.
In my example I figured out you don't need to go further than 5.
With the '+' it's easier to recognize if a program is even made in full open source software.
to my personal taste, I don't like doing anything with the teeth. It messes up the design a lot.
Doesn't look professional.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 09, 2016, 03:39:09 pm
Using Dave's assignment of tooth attribute, but changing the symbols.
Circle = Original Source
Square = Source in PDF, JPEG ...
Triangle = ?
Empty = Attribute not opened

Not introducing colour due to silkscreen implementation

[Done in MS Paint - so needs fixing]
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Artlav on September 09, 2016, 03:56:49 pm
Dave, i've heard that idea before.
Can't quite remember where.
Have you already mentioned it earlier this year somewhere?

How about something like this?

(http://i.imgur.com/SgX14jO.gif)

I really like that - no font size issues, and no extra confusion since you would have had to look up the letters anyway.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: sambran on September 09, 2016, 04:23:44 pm
I really like the idea, although I think it gets tricky when it comes to firmware. Specifically, what do you do if your source code is open but you rely on non open elements (libraries, RTOSs, compilers etc.) from third parties.

I doubt you can include any more information in the logo but it would be awesome of there was a some sort of template allowing the creators to easily detail how open the project is.   
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: CaptCrash on September 09, 2016, 04:34:42 pm
I don't really understand how this solves the problem of a commercial product having some components of its design opened up.

The decision on how open the commercial product is going to be is unlikely to be made at design time, more likely it's going to be approved for much closer to the date the product is ready for sale/marketing/announcement/release.

Making the level of open source compliance related to a logo on the hardware seems counter productive.
Eg if the logo lists 5 of 7 items as open, then at the last minute the commercial body describes to only release 4 of 7, then they are not going to scrap boards are they.

The identifier idea seems good (especially with logos underneath for internationalisation), but not on hardware silkscreen.  Much better on documentation, web sites etc

Eg use standard OSH logo on hardware as everyone is doing anyway, diffirentiate on electronic media.

This will also encourage commercials to open up more as time goes on, eg starting with 3/7 and moving to 5/7 as they become more comfortable, expand the scope of their open sourced hardware.
Perhaps the addition of qr codes on hardware to simplify finding information or some sort of identifier/web address.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 04:50:01 pm
(https://www.eevblog.com/forum/blog/eevblog-921-open-source-hardware-problems-solved!/?action=dlattach;attach=254222;image)
How about "80 Plus" ? you could just make a score from 1 to 100 - where you get points for each met criteria - this way people will know how much open source it actually is.
Don't take it personal, but this scoring/percentage approach is not going to make things better or easier, i am afraid.  :(

Let's say, we only consider schematics (S), PCB layout (P), BOM (B) and project documentation (D) as the criteria to determine the score.
If all four are provided, then the score would be 100%.
If only 3 of 4 would be provided, it would be 75%.

So, let's go with this... Say, there is a project having a 75% logo. What exactly does this mean? Is the BOM missing, the PCB layout, or the documentation? Completely ambiguous.

Let's tighten the screws a little bit more... There are two projects with 75% each. One is lacking BOM, the other is lacking the documentation. Both having 75% suggests that they both provide an equivalent amount of information/data. But that's not the case. Clearly, the project providing the documentation is providing more valuable information (the BOM could always be derived from the schematics).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 09, 2016, 04:51:15 pm
It solves the problem in a sense that it's not all or nothing anymore.
Which makes a lot of sense to me.
I never get the utopian idea that everything has to be fully open.
Sometimes there are practical reasons for not doing it.

The reasons why I implemented a extra item ('+') is to make even more clear that all elements are open or not.
It's better that people share things (even if software or parts are not open) than nothing at all!

@elgonzo
You could also give a certain aspect (like BOM, schematic etc) a certain number or value.
On the other hand, if people share their original files, you already have the BOM.
What is really important, is the fact that people see if the files are made in a free or open source software program

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 04:57:03 pm
Using Dave's assignment of tooth attribute, but changing the symbols.
Circle = Original Source
Square = Source in PDF, JPEG ...
Triangle = ?
Empty = Attribute not opened

Not introducing colour due to silkscreen implementation

[Done in MS Paint - so needs fixing]
Isn't this a teeny weeny bit too abstract and arbitrary? Who will ever memorize the meaning behind these geometric shapes?  :o
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: gcardinal on September 09, 2016, 05:05:47 pm
...

I think you are jumping a gun here - its not a percentage - but a score or rating.

I really dont want to use a specific example here. But basic idea is to send the message on how much of an open hardware this exact product is.

And here I think base line could be 50 - everything necessary to recreate the project is available.
In order to get next 50 points:
things like exact source files for PCB, complete documentation, enclosure design (if such applies) make up for next 40
and last 10 are for commercial use and possibility to reproduce without alternation with the files provided. This is for projects where you could with information you have order a 100 units the next day.

Another good example is energy rating on houses.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: zapta on September 09, 2016, 05:06:47 pm
A similar approach is used for hazardous materials. In this case it's not just binary but has a level for each category.

(http://www.sonnycovic.com/images/nfpadiamond_1_.gif)

Having this granularity printed on the PCB is not that useful since it can change any time, e.g. by publishing schematics. A generic symbol and a reference to a website with the detailed information would be more useful.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: berwick53 on September 09, 2016, 05:07:50 pm
This video really reminded me of this!

(http://imgs.xkcd.com/comics/standards.png)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 05:14:36 pm
You could also give a certain aspect (like BOM, schematic etc) a certain number or value.
On the other hand, if people share their original files, you already have the BOM.
The whole idea with with percentage-based scoring here is rather pointless. It is a quantitative measure, but not a suitable measure of quality, as my example illustrated. Well, we can argue about my specific example all day long, but that does not change the fact of the matter.

(EDIT: I misunderstood gcardinals post and that the suggestion he made was not about a percentage-based scoring. Please ignore my ill-informed comments with regard to that  :-[ )

However, the way you did it (as described in the forum post you linked) by using numbers as a category (not as a quantitative measure as suggested by gcardinal) makes more sense. (Although i personally very much prefer letter identifiers underneath or beside the logo, your suggestion certainly has merit.)


What is really important, is the fact that people see if the files are made in a free or open source software program
No, that's not really important with regard to OSHW logo. Low barrier to access is more important than pushing OSS (or any other particular software). Hence why it would make more sense to push for (open) standard file formats. It doesn't mean you either have to push OSS or open formats. One can do both (and probably it is necessary and the wisest thing to do), but the emphasis should be in establishing open standard formats -- similar to what PDF has become...
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Romain on September 09, 2016, 05:25:58 pm
Hi,
Great initiative Dave, which I find very good and very clear. That will make Open Hardware more understandable.

I do prefer the letters as well, makes it perfectly understandable.

Guys, don't forget it still doesn't mention what "license" is to be applied on the job, similarly as software (is it GNU, GPL, BSD, ...). The project's website must obviously complete all these informations.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: elgonzo on September 09, 2016, 05:28:59 pm
I think you are jumping a gun here - its not a percentage - but a score or rating.

I really dont want to use a specific example here. But basic idea is to send the message on how much of an open hardware this exact product is.

And here I think base line could be 50 - everything necessary to recreate the project is available.
In order to get next 50 points:
things like exact source files for PCB, complete documentation, enclosure design (if such applies) make up for next 40
and last 10 are for commercial use and possibility to reproduce without alternation with the files provided. This is for projects where you could with information you have order a 100 units the next day.

Another good example is energy rating on houses.
Ahh, okay. Sorry, i misunderstood your post. Was sent on a wrong track when looking at your picture. My bad, and my apologies.

Although, i still have a difficulty to understand the meaning of such aggregate numbers without requiring a long explanation. Imo, it would be much easier and simpler (for both creators and recipients) to have simple letter identifiers denoting the content provided, or to have simple and straightforward categories (as suggested by b_force).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: nctnico on September 09, 2016, 05:30:41 pm
This video really reminded me of this!

(http://imgs.xkcd.com/comics/standards.png)
I agree. I didn't watch the video but the remarks give me the gist of it. On one hand there will always be the purists which to some extend keep things open but also work against progress. What you'll see is that others will come up with open hardware licenses which work in practical situations. CERN for example came up with there own OHWR license: http://www.ohwr.org/projects/cernohl/wiki (http://www.ohwr.org/projects/cernohl/wiki) just like there are several alternatives to GPL and LGPL licensing (every now and then you'll run into MIT and BSD licensed open source software).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 09, 2016, 05:39:28 pm
You could also give a certain aspect (like BOM, schematic etc) a certain number or value.
On the other hand, if people share their original files, you already have the BOM.
The whole idea with with percentage-based scoring here is rather pointless. It is a quantitative measure, but not a suitable measure of quality, as my example illustrated. Well, we can argue about my specific example all day long, but that does not change the fact of the matter.

However, the way you did it (as described in the forum post you linked) by using numbers as a category (not as a quantitative measure as suggested by gcardinal) makes more sense. (Although i personally very much prefer letter identifiers underneath or beside the logo, your suggestion certainly has merit.)


What is really important, is the fact that people see if the files are made in a free or open source software program
No, that's not really important with regard to OSHW logo. Low barrier to access is more important than pushing OSS (or any other particular software). Hence why it would make more sense to push for (open) standard file formats. It doesn't mean you either have to push OSS or open formats. One can do both, but the emphasis should be in establishing open standard formats -- similar to what PDF has become...
I still think it makes more sense to use some sort of percentage, for the simple reason that someone can see easily how 'open' a certain project is.
For that same reason I don't like the idea of letters (in general), because it means I have to look it up and have to figure out for myself how open a project is.
Which by than becomes a subjective measure and therefore leads to more discussion and confusion.
The main reason why I don't like Daves idea at all (besides the fact that it looks very ugly to my personal taste)

But I really do understand your point that it should be very clear what a certain number means.
Therefore I suggested my idea, which is nothing more than a rough start.
Hoping that people would pick it up and we ultimately come to some sort of compromise.

The reason why I was talking about why it's important for people if a certain project is fully open (means made in open source software), has more to do with practical reasons.
For example, people who can only use open source software, can easily search and see if they can use and update certain projects.
Also for the purists, it just gives them a little bit more to be proud of.  ;) ;D

Therefore you don't need such a huge score. You're not gonna use 63 or 87 or 38 for example.
(seriously, how would you practically translate a score of 63 compared to 60?)
Full steps (or maybe half steps) are fine.
That's why I came up with the idea I posted before.
I couldn't think of anything more than what I said in the other post.
It also makes the whole logo much more clear.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 09, 2016, 05:52:50 pm
@up:
Creative Commons went fine with letters, nobody has to check every time what they mean.

If font-size is a problem why not just make the logo bigger on a PCB?

I updated the generator so it looks nicer now, I'm not sure how the letters under the logo should look like, so I'll try a few options and try to pick the best one. Adding an option of "score" in the middle is also pretty easy, but it would have the same problem with font size (or even worse if it was percentage).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 09, 2016, 09:35:58 pm
Dave, i've heard that idea before.
Can't quite remember where.
Have you already mentioned it earlier this year somewhere?

Yes, I mentioned in on the Amp Hour before.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: m98 on September 09, 2016, 10:04:44 pm
So how about splitting it up into the gear logo itself that stays how it is, and then an "openness widget" showing the icons for the different levels.
The logo can then be used on PCB, housing, manuals, compliance labels, while the widget can be applied to the product packaging and other advertisement media like product websites and such.
Title: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: timb on September 09, 2016, 11:03:16 pm
It's not for the bloody designer. It's for the consumer. Someone with a passing interest. Anyone with a deep interest already knows what you've bloody open sourced.

Actually, it more for the desings and those technical people in the field than the consumer. Just like the consumer doesn't care about Creative Commons letter codes, similar thing here.
This system allows your peers in the field to see at a glance how open your project is, and I think that's important.

Why, is it important that it be seen at a glance? It sounds counterintuitive. If you have a keen technical interest in the detail of a design is it really a bridge too far to read the documentation and the license terms? Therein lies the difficulty I have with this proposal. It seem to want to present information at a glance to people who should be sufficiently invested to be willing to make a detailed analysis.

Exactly.

This idea is pointless. First off, it won't scale well when printed on a tiny area of PCB. Secondly, the openness might change *after* boards have been manufactured.

Perhaps what you could do is this: Keep the same gear logo, but add a URL to the bottom, like so: oshw.it/ProjectName

That would take you to a page for that specific project on the OSHW site, where the "Openess" rating would be displayed. Along with links to the schematics, artwork, firmware, the creator's website, etc.

That's easy to print on a board, is controlled by the OSHW organization and allows you easy access to what you need to know.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: VEGETA on September 09, 2016, 11:09:39 pm
I really like putting letters under the logo. I hope the generator supports it.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: imidis on September 09, 2016, 11:15:18 pm
How bout a QR code url link?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 10, 2016, 12:35:26 am
@up:
QR code would be even worse with scaling, unless the url is very short, but that would still take up at least the same space as the logo.

@2x up:
It will in the morning - I'm going to sleep right now (it's 2:35AM my time) ;p
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 10, 2016, 12:36:45 am
Why, is it important that it be seen at a glance?

If you don't know then you aren't one of people who need worry yourself about it.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 10, 2016, 12:39:39 am
This idea is pointless. First off, it won't scale well when printed on a tiny area of PCB. Secondly, the openness might change *after* boards have been manufactured.
Perhaps what you could do is this: Keep the same gear logo, but add a URL to the bottom, like so: oshw.it/ProjectName

Putting it on the PCB is one small part of it, and that is why I suggested just putting the logo on the board precisely because the openness might change later.

Quote
That would take you to a page for that specific project on the OSHW site, where the "Openess" rating would be displayed.

And how would the openness be displayed in a consistent manner? Using the exact same system I have suggested! That's the whole point of it.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 10, 2016, 12:41:27 am
If font-size is a problem why not just make the logo bigger on a PCB?

Just put it under the logo, job done.
It works as plain text too, just lik the Creative commons does
e.g. CC-BY-SA
OSHW-SPMC or whatever
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: pickle9000 on September 10, 2016, 01:51:08 am
the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Hmmm.

You're right. So there goes the whole idea really.

I guess it's wise not to include the logo at all if you aren't sure.

You don't have to use the logo to open your designs though.

Ideally a a short url under the logo (always the same) in which a user could post the status and project links and limitations. Could be a repository like thingyverse (not thingyverse). If an enterprising person or group set a url up it may well be a good way to generate revenue either for the project or the site itself.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 10, 2016, 09:17:34 am
the designers openess might change before release, and if  it's baked onto the PCB that could be troublesome.
Hmmm.

You're right. So there goes the whole idea really.

I guess it's wise not to include the logo at all if you aren't sure.

You don't have to use the logo to open your designs though.

Ideally a a short url under the logo (always the same) in which a user could post the status and project links and limitations. Could be a repository like thingyverse (not thingyverse). If an enterprising person or group set a url up it may well be a good way to generate revenue either for the project or the site itself.

Something like https://www.npmjs.com/ (https://www.npmjs.com/) for OSHW projects?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 10, 2016, 09:31:47 am
It's up: https://maciek134.github.io/oshw-logo-gen/ (https://maciek134.github.io/oshw-logo-gen/)

Sure, for now it generates on the logo - I'll add an option to generate under the logo (and probably some styles) after work. Can someone provide an example of how it should look like (under the logo)?

I think simply have it generate "OSHW-SPFMDBC" in the same Arial Bold font below the logo.
Non-original design files get a lower case character instead of upper case.
Remove the "Open Source Hardware" text.
Would be nice if the auto-generated text would scale in size depending upon the number of option. eg. OSHW-SC is shorter than the full string, so it could be a larger font to compensate?
Text needs to the centered of course.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: suku on September 10, 2016, 10:39:25 am
https://maciek134.github.io/oshw-logo-gen/

I'm sorry but isn't it funny that if I don't select anything to be open, than I end up with the original Open Source Hardware logo which is supposed to mean that everything is open :D
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: donotdespisethesnake on September 10, 2016, 11:13:50 am
Funny, people who have no clue what Open Source is about, trying to "fix" Open Source to make it not Open Source :)

I guess people who talk about "revenue models" will never get it. There is already a whole legal framework to protect revenue models : trademarks, copyrights, patents. The whole point of Open Source is that it is a non-revenue model.

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: nctnico on September 10, 2016, 11:41:48 am
And how would the openness be displayed in a consistent manner? Using the exact same system I have suggested! That's the whole point of it.
The problem is that the license may also change in a way the author does not like it or the project is no longer compliant with the new license. So no matter how you turn things around what is going to count is which license the author wants to adhere to and that information should be somewhere in the project files / project website.

Also I don't think any 'consumer' is served by a logo which tells exactly under which licenses it's sources are released so the whole point of making a lot of fuss about a logo is moot. Nobody cares. After all: is there a GPL symbol on the back of your Android telephone?

The whole point of Open Source is that it is a non-revenue model.
That is not true. For starters there is dual licensing (MySQL for example). Also in many cases the open source part is not part of the core business of a company and can be a collaboration between several parties. Using an open source license for a collaboration is like using an off-the-shelve legal framework saving companies from a lot of headaches (and lawyer expenses).
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: timb on September 10, 2016, 12:29:10 pm
And how would the openness be displayed in a consistent manner? Using the exact same system I have suggested! That's the whole point of it.

Well, since it would be a web page instead of a tiny logo, the openness would be displayed in a verbose manner... Literally, it would actually say on the page: "This project provides Schematics, Gerbers and Firmware for download. Layout files are not provided. 3D Models are not applicable to this project."

Then it would actually provide links to said items. That seems *a lot* more straight forward than trying to remember what a bunch of random letters mean, or which gear tooth means what.

Also, since the OSHW people (or whomever) controls the website that all the projects will be listed at, it also means it can actually be enforced. A logo alone won't do that. It also means you can print the logo/URL on your boards, packaging, etc. and never have to worry about updating it if your compliance changes. It would be a very clean system.

I doubt yours will ever really work or see widespread adoption. (And yes, I know Creative Commons uses a system with various logos, but at least you can usually click on said logo and be taken to a page where it's explained. You don't see CC logos physically printed on boxes or boards!)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 10, 2016, 12:37:52 pm
I still don't like the letter idea because it's only focused on electronics. We are talking about open source HARDWARE. So that can also be something mechanical, like the construction of a bike, a bandsaw or a cnc.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 10, 2016, 12:48:34 pm
It's not for the bloody designer. It's for the consumer. Someone with a passing interest. Anyone with a deep interest already knows what you've bloody open sourced.

Actually, it more for the desings and those technical people in the field than the consumer. Just like the consumer doesn't care about Creative Commons letter codes, similar thing here.
This system allows your peers in the field to see at a glance how open your project is, and I think that's important.

Why, is it important that it be seen at a glance? It sounds counterintuitive. If you have a keen technical interest in the detail of a design is it really a bridge too far to read the documentation and the license terms? Therein lies the difficulty I have with this proposal. It seem to want to present information at a glance to people who should be sufficiently invested to be willing to make a detailed analysis.
I am very sorry, but that is how most people work. Even engineers and scientists.
Why?
Because it saves time, energy,frustration and (sometimes) money.

People don't want something cumbersum that takes to much effort to figure out when not needed.
(that's why people spend a few extra bucks for decent test gear for example)
To me it's also not very professional at all.

I also don't see any reason why we wouldn't be able to come up with something that covers most of it first glance.
It is at least worth the try, if not possible you can always come up with something else.
Doing it the other way around is a very strange way of 'engineering' to me.
First investigate if you can meet the best criterium, of not, go down a step.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 10, 2016, 02:44:01 pm
It's up: https://maciek134.github.io/oshw-logo-gen/ (https://maciek134.github.io/oshw-logo-gen/)

Sure, for now it generates on the logo - I'll add an option to generate under the logo (and probably some styles) after work. Can someone provide an example of how it should look like (under the logo)?

I think simply have it generate "OSHW-SPFMDBC" in the same Arial Bold font below the logo.
Non-original design files get a lower case character instead of upper case.
Remove the "Open Source Hardware" text.
Would be nice if the auto-generated text would scale in size depending upon the number of option. eg. OSHW-SC is shorter than the full string, so it could be a larger font to compensate?
Text needs to the centered of course.
If this was a separate string on the silk layer you could set the font size according to logo scaling. It doesn't need to be part of the logo template. Probably be easier this way instead of having lots of variants.
If the community wanted a new letter for another attribute then you wouldn't need to create lots of permutations.
Also, I'd suggest just having upper case for original source and not have lower case. This way with no letters, the project is still open but with only PDF documents. This meets the requirements of OSHW but won't mislead any one who knows the new system.
It's backwards compatible but allows the new system for new designs.
If this becomes widespread then old projects may want to update the PCB with the new system or risk being thought of as not open according to this new standard.

Sent from my SM-N930F using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: silicon_ghost on September 10, 2016, 03:27:24 pm
I completely disagree with any of the percentagers or other arbitrary "I have 6 of 10 points" methods.  The people that care about OSHW want the details, not percentages.

To the naysayers that it needs to be all or nothing: Look at recycling.  There are DOZENS of recycling codes.  Not all recyclers accept all codes due to cost or difficulty in reprocessing.  If the recycling advocates had said "F this! It is full recycling or nothing and don't put numbers in there!", we'd have NO recycling today. 

Dave's concept is good; You can argue about the details.  The net result would likely be far more participation/openness from commercial outfits if they had more than an all-or-nothing logo.

I do remember the Amp Hour episode where Dave and Chris talked about this.  I thought it was a cool idea then and I think it is still a cool idea now after some months.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: doobedoobedo on September 10, 2016, 03:42:32 pm
Funny, people who have no clue what Open Source is about, trying to "fix" Open Source to make it not Open Source :)

This.

"Hey let's say our product is OSHW, I think we'll get more sales that way"

"But it isn't!"

"Lets redefine what OSHW is then, so we can pretend it sort of is and get more sales from the people we fool"
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 11, 2016, 01:07:07 am
I completely disagree with any of the percentagers or other arbitrary "I have 6 of 10 points" methods.  The people that care about OSHW want the details, not percentages.
Your comment has prompted me to repose my question. (not specifically replying to your post)

That's what I was thinking when I asked this question earlier and was brushed off. "Why, is it important that it be seen at a glance?"

It sounds counterintuitive. If you have a keen technical interest in the detail of a design is it really a bridge too far to read the documentation and the license terms? Therein lies the difficulty I have with this proposal. It seem to want to present information at a glance to people who should be sufficiently invested to be willing to make a detailed analysis.

I was told that because I wasn't "in the know" I needn't concern myself with the question. But just for the sake of discussion I am interested in why it is important to know at a glance whether or not a design is completely or just partially open. 

As Dave said in his video (@9:15) it might be fine to use the original gear symbol on a PCB if it is impractical to use a new more complex one. Then you could use the new standard on the web site. So right there the "at a glance" advantage is diminished and you are now looking at a website. Once you are looking at the website is there still as much need for an "at a glance" logo?

So I went and read the definition here http://www.oshwa.org/definition/ (http://www.oshwa.org/definition/) and here http://freedomdefined.org/OSHW (http://freedomdefined.org/OSHW) And came to the conclusion that if it isn't open it is partially closed. Which means it doesn't have sufficient information to enable duplication and extension. Whilst some information is better than none for many purposes and people  if it is principally provided to support the sale of the product in a similar manner to the documentation of an API or a PDF schematic to show the pin connections of a microcontroller board then I'm  not calling it open anymore.

So if hardware vendors want to provide good documentation then don't call it open hardware.

Use the current gear symbol on truly open hardware and anyone wanting to duplicate it can jolly well read the license terms to ensure they comply fully. Any hardware vendor who wants to get the marketing benefits of appearing to be a little bit open can still do that without using the symbol at all.

Making it easy for vendors to use the open hardware symbol without complying with its original purpose is the real problem. Clever annotations is just accepting that you're trying to stand on shifting sands and you're not on solid ground.

So if it is open use the gear symbol. Otherwise don't. That is my solution to the problem because I believe the real problem is vendors trying to be greedy for the benefits of OSHW without wanting to accept the reponsibilities. I'm not allowing them to cover their arses from community outrage when trying to present partially closed designs as OPEN.


Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 11, 2016, 02:25:39 am
This hard-nosed approach is what is causing the WHOLE concept to struggle with legitimate, practical expression.

It's exactly the same as NOT allowing someone to be recognised as a valuable helper because they aren't Mother Teresa.  Sainthood is no measure of value that can be reasonably applied in the greater world.

As it is, the gear logo is losing ALL credibility because there is no 'middle ground' and there are some that have at least made a legitimate effort.  I'd be happier to give them credit for what they have done, rather than tell them flat out 'NO!!' just because they only scored 9.9 out of 10 (Example used for illustration purposes only.  A numeric rating system is not at all useful.)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 11, 2016, 04:43:39 am
Yes, there will always be disagreement, but a more flexible system will mean the disagreements are more likely to be less extreme.

And while it might rub some people up the wrong way, I do not find the concept of a commercial benefit being necessarily distasteful.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 11, 2016, 06:26:02 am
I completely disagree with any of the percentagers or other arbitrary "I have 6 of 10 points" methods.  The people that care about OSHW want the details, not percentages.

I originally thought of a numbered "level" based system based on the gear teeth. And having missing teeth, or coloured teeth etc as many have suggested now. But the more I thought about ti more I thought how impractical it was, there are just too many permutations that render it useless. On top of that it's not at all obvious what's open and what's not, and that's the entire point of the letter based system.

Imagine if the Creative Commons license said "Level 2" instead of BY-SA. Level 2 doesn't tell you anything.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: amspire on September 11, 2016, 08:14:39 am
I had been thinking about how to mark hardware as open source, but from a different perspective.

The point that makes an open source design useful is that you can copy it and perhaps enhance it as long as you follow the conditions of the license.

However, imagine that company A releases an open source design and you copy it. Company B buys company A and changes the license to a commercial license and also wipes Company A's website totally. It may not be trivial to be able to show you copied only the open source design or even that the open source license existed at all. As pointed out, the OS gear symbol has no absolute legal meaning as far as licenses go. Having an electronic copy of Company A's license is not much proof as anyone can make a fake license file.

If open source designers made an Open Source document package including files and licenses, made a SHA1 or SHA256 hash of the document package and then print the hash (or part of it) on the board or case moulding, then as long as you had Company's product plus the file that matched the hash, you can prove that the file package and license you have was the one issued by Company A for the exact product you have. No-one else could make a file with changed information with the same hash.

It does mean finding space on a board or case moulding for the Hash number. A printed label is not good enough as anyone can add a label. A full SHA1 hash would be 40 Hex characters. Not sure how much you can truncate the hash to a shorter length and still have it secure. If the hash number is put on a copper layer with a very small font, it may be something you could fit on many boards.

The hash would also make it very easy to search for the OS file pack as any one storing the file would include the hash number on the website. There make be repositories that store OS files along with the hash.

Hope that makes some sense.

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Tabs on September 11, 2016, 09:42:30 am
I had been thinking about how to mark hardware as open source, but from a different perspective.

The point that makes an open source design useful is that you can copy it and perhaps enhance it as long as you follow the conditions of the license.

However, imagine that company A releases an open source design and you copy it. Company B buys company A and changes the license to a commercial license and also wipes Company A's website totally. It may not be trivial to be able to show you copied only the open source design or even that the open source license existed at all. As pointed out, the OS gear symbol has no absolute legal meaning as far as licenses go. Having an electronic copy of Company A's license is not much proof as anyone can make a fake license file.

If open source designers made an Open Source document package including files and licenses, made a SHA1 or SHA256 hash of the document package and then printed the hash (or part of it) on the board or case moulding, then as long as you had Company's product plus the file that matched the hash, you can prove that the file package and license you have was the one issued by Company A for the exact product you have. No-one else could make a file with changed information with the same hash.

It does mean finding space on a board or case moulding for the Hash number. A printed label is not good enough as anyone can add a label. A full SHA1 hash would be 40 Hex characters. Not sure how much you can truncate the hash to a shorter length and still have it secure. If the hash number is put on a copper layer with a very small font, it may be something you could fit on many boards.

The hash would also make it very easy to search for the OS file pack as any one storing the file would include the hash number on the website. There make be repositories that store OS files along with the hash.

Hope that makes some sense.
While this is an novel contribution to the discussion and does bring a valid point, there's a big flaw in this idea.
If the hash is on the board then the documentation must be fixed. How many times have you written a 100% accurate document, schematic, software?
What about adding more detail to an existing document; ones that do don't result in a physical change to the PCB.
The hash would no longer match.

I would suggest that as part of open sourcing a product and it's associated cad/doc files you are required to publish it on something public like github.
Anyone wanting to do derivative works should fork/clone the project and start their changes.
Doesn't have to be github, just trying to get the concept across.

Sent from my SM-N930F using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: doobedoobedo on September 11, 2016, 11:59:45 am
This hard-nosed approach is what is causing the WHOLE concept to struggle with legitimate, practical expression.

It's exactly the same as NOT allowing someone to be recognised as a valuable helper because they aren't Mother Teresa.  Sainthood is no measure of value that can be reasonably applied in the greater world.

As it is, the gear logo is losing ALL credibility because there is no 'middle ground' and there are some that have at least made a legitimate effort.  I'd be happier to give them credit for what they have done, rather than tell them flat out 'NO!!' just because they only scored 9.9 out of 10 (Example used for illustration purposes only.  A numeric rating system is not at all useful.)
Those who make a legitimate effort should indeed be rewarded, but unless they comply with the OSHW definition it can't be with the OSHW logo. They need a completely different logo for 'enhanced documentation', they can't just steal or subvert the OSHW logo.

This is how I see someone using the OSHW logo who doesn't stick to their side of the agreement which would allow them to use it:
(https://www.eevblog.com/forum/blog/eevblog-921-open-source-hardware-problems-solved!/?action=dlattach;attach=254730)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 11, 2016, 01:04:31 pm
The whole idea with a number, is that it's more a general level.
Like I said before (and so far nobody replied to it), now with letters it only suits electronics, which I think is far to limited and completely useless.
With numbers/a scale you can refer to a certain level and therefore it's usable in other fields.

And I am sorry, but science is all about 'first glance'. We all try to put things in numbers that are understandable.
THD, PSSR, CMRR, max load, tolerance, the use of standard deviation, 'RMS' voltage/power, peak voltage/power are all 'first glance numbers'.
Nobody reads the whole document to understand certain conclusions, you first skim over results and numbers to see if it's usable.
That's exactly what this is about. People wanna skim OSHW projects if they are usable.
If I need to go into detail every single little time, no thank you, to much of an hassle!  :--

I seriously don't understand the most inconvenient most time consuming approach.  :o  :-//

About copying and changing licenses. Well that's always the risk.
But if you state clearly in your original design that the design can only be used, modified and copied under the same license and may never be transformed into a commercial license (like amspire said), that should be covered.
Yes, people can still infringe that, but that's no different that with patents (which happens all the time btw)
Hexidecimal hashes or anything else are not gonna help in this. It's clear were a design came from.
Ones again, that's no difference than products with a patent.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 11, 2016, 02:23:07 pm
The whole idea with a number, is that it's more a general level.
Like I said before (and so far nobody replied to it), now with letters it only suits electronics, which I think is far to limited and completely useless.
With numbers/a scale you can refer to a certain level and therefore it's usable in other fields.
And I am sorry, but science is all about 'first glance'. We all try to put things in numbers that are understandable.
THD, PSSR, CMRR, max load, tolerance, the use of standard deviation, 'RMS' voltage/power, peak voltage/power are all 'first glance numbers'.
Nobody reads the whole document to understand certain conclusions, you first skim over results and numbers to see if it's usable.
That's exactly what this is about. People wanna skim OSHW projects if they are usable.

Exactly, and that is precisely what my system allows that a number or level based system does not.
Try using a level based system with say the Creative Commons, it doesn't work. Why? Because one of the things missing could be a show-stopper for you.
For example, if you are after an OSHW design you can use commercially, and a project was "level 4 out of 5" or whatever, what does that mean? It doesn't convey any useful information to you.
With 7 different items i have proposed relating to a hardware design (and I haven't heard anyone say it's too many or too few yet) the permutations are just too many in order to have a usable level based numbering system.
In fact, it already has that, just count up the number of gears (or letters) that are used. 4 letters = 4/7 "openness" if you really want.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 11, 2016, 02:27:14 pm
Those who make a legitimate effort should indeed be rewarded, but unless they comply with the OSHW definition it can't be with the OSHW logo. They need a completely different logo for 'enhanced documentation', they can't just steal or subvert the OSHW logo.

But you don't seem to realise that the problem already exists!
It's gotten so bad that the OSHW association has had to effectively abandon the OSHW logo because it was becoming meaningless because everyone was misusing it, so they went and trademarked their own new symbol.
I say let them do that and lets sort of the problem with the existing OSHW symbol by using my proposal.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 11, 2016, 02:43:50 pm
The whole idea with a number, is that it's more a general level.
Like I said before (and so far nobody replied to it), now with letters it only suits electronics, which I think is far to limited and completely useless.
With numbers/a scale you can refer to a certain level and therefore it's usable in other fields.
And I am sorry, but science is all about 'first glance'. We all try to put things in numbers that are understandable.
THD, PSSR, CMRR, max load, tolerance, the use of standard deviation, 'RMS' voltage/power, peak voltage/power are all 'first glance numbers'.
Nobody reads the whole document to understand certain conclusions, you first skim over results and numbers to see if it's usable.
That's exactly what this is about. People wanna skim OSHW projects if they are usable.

Exactly, and that is precisely what my system allows that a number or level based system does not.
Try using a level based system with say the Creative Commons, it doesn't work. Why? Because one of the things missing could be a show-stopper for you.
For example, if you are after an OSHW design you can use commercially, and a project was "level 4 out of 5" or whatever, what does that mean? It doesn't convey any useful information to you.
With 7 different items i have proposed relating to a hardware design (and I haven't heard anyone say it's too many or too few yet) the permutations are just too many in order to have a usable level based numbering system.
In fact, it already has that, just count up the number of gears (or letters) that are used. 4 letters = 4/7 "openness" if you really want.
Ok, but how do you apply letters to something like mechanics and not only electronics?
What if electronics, mechanics AND aesthetics are involved?


I still prefer to see how open a certain project is. Like what i suggested in my post in the other topic.
With a good system that directly covers the content, and therefore it does the same (plus more!) than just using letters.
You automatically know with a certain rating is about and if it's usable and what is usable.
Scores and numbers can being put in perspective, letters not.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: doobedoobedo on September 11, 2016, 05:03:03 pm
Those who make a legitimate effort should indeed be rewarded, but unless they comply with the OSHW definition it can't be with the OSHW logo. They need a completely different logo for 'enhanced documentation', they can't just steal or subvert the OSHW logo.

But you don't seem to realise that the problem already exists!
It's gotten so bad that the OSHW association has had to effectively abandon the OSHW logo because it was becoming meaningless because everyone was misusing it, so they went and trademarked their own new symbol.
I say let them do that and lets sort of the problem with the existing OSHW symbol by using my proposal.

I'm well aware the problem already exists, otherwise the topic wouldn't have come up.

However I believe it's naive to think that companies or individuals who are prepared to steal a logo they're not entitled to would respond positively to legitimisation of the theft, by giving them a plethora of other logos to use. This situation arose because the OSHW association don't have the money to defend their logo, and unless that changes the less scrupulous will continue to use whatever they think will make them the most money.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 11, 2016, 06:51:20 pm
Those people wouldn't have the money to defend their logo anyway, OSHW or not.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: poorchava on September 11, 2016, 07:23:43 pm
Nobody gives a damn about open source hardware or software, or the licenses coming along with those. People will take the design files and do as they please with no regard to license. If you don't have resources to pursue this in court,  you may have all the copyright in the world -  nobody gives a shit unless you have resources to defend it. That how the world works...

Sent from my HTC One M8s using Tapatalk

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: matthewbadeau on September 11, 2016, 11:03:03 pm
Hi All,
Sorry about the newbie mistake. I actually had made another forum post with my own logo generator but I would prefer to move all of that discussion to this thread. Here's a link to my take on the logo generator: https://matthewbadeau.github.io/OSHW-Logo-Autogen/ (https://matthewbadeau.github.io/OSHW-Logo-Autogen/)

The old thread: https://www.eevblog.com/forum/chat/oshw-logo-generator/ (https://www.eevblog.com/forum/chat/oshw-logo-generator/)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 03:02:14 am
Ok, but how do you apply letters to something like mechanics and not only electronics?

There is an M in the proposal for a reason, it stands for Mechanical.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 03:03:37 am
I'm well aware the problem already exists, otherwise the topic wouldn't have come up.

Ok, so what's your solution to the problem?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 12, 2016, 05:00:59 am
Ok, but how do you apply letters to something like mechanics and not only electronics?

There is an M in the proposal for a reason, it stands for Mechanical.
Just a M is not enough of course.
Most mechincal projects have a lot of steps, blueprints, drawings etc.
Some projects also contain even software.
(in my opinion firmware for ucontroller for example)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 05:23:37 am
Ok, but how do you apply letters to something like mechanics and not only electronics?
There is an M in the proposal for a reason, it stands for Mechanical.
Just a M is not enough of course.

It's good enough.
I've had no other people say my suggested categories aren't enough.

What's your suggestion? How many more letters do you want?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 12, 2016, 07:58:53 am
So just by the fact that other people don't say anything about it, means it's good enough???
That's a new way of working to me.
(don't think my boss and clients would apreciate that approach)

I'm thinking of suggestions, but the least I can tell you that for now a lot of people will be stuck.
The reason why I am pointing it out, is because it's an issue.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: doobedoobedo on September 12, 2016, 10:28:47 am
I'm well aware the problem already exists, otherwise the topic wouldn't have come up.

Ok, so what's your solution to the problem?

I'm not so sure there is one.

You're approaching the problem as an engineer, which is no bad thing, but the people who have misappropriated the logo aren't acting as engineers, they're acting as marketers. Whatever you do they can't be trusted to stick to rules if they see gain from breaking them without consequences.

Maybe I'm just too cynical.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 10:48:29 am
I'm not so sure there is one.

The OSHW association disagree, as would most closely involved in the OSHW industry.

Quote
You're approaching the problem as an engineer, which is no bad thing, but the people who have misappropriated the logo aren't acting as engineers, they're acting as marketers. Whatever you do they can't be trusted to stick to rules if they see gain from breaking them without consequences.
Maybe I'm just too cynical.

Yep. You are assuming that all people who use the logo inappropriately are doing so for marketing reasons. This is demonstrably untrue.
And even for those that are, my solution provides a better way for the to so so legitimately.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 10:53:12 am
So just by the fact that other people don't say anything about it, means it's good enough???
That's a new way of working to me.
(don't think my boss and clients would apreciate that approach)

That's how these essentially crowd sourced and crowd legitimised ideas generally work.
If my categories were wildly wrong (either too many, too few, or inappropriate) then believe me, people would be jumping up and down about it.
So obviously my categories are close enough to be workable.

Quote
I'm thinking of suggestions, but the least I can tell you that for now a lot of people will be stuck.
The reason why I am pointing it out, is because it's an issue.

Then please explain in detail.
Who is going to be stuck?
Why isn't anyone else pointing out the same problem you think there is?
Even if some people are "stuck", no matter how many more categories you make, you won't be able to cover every possible scenario. It's going to be diminishing returns.

There are hundreds of people telling me my font is wrong etc, it need to look this way and that way etc, or the entire concept is wrong/won't work etc, but I currently count only one person who has said the categories don't cut the mustard.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 12, 2016, 11:36:31 am
Hi All,
Sorry about the newbie mistake. I actually had made another forum post with my own logo generator but I would prefer to move all of that discussion to this thread. Here's a link to my take on the logo generator: https://matthewbadeau.github.io/OSHW-Logo-Autogen/ (https://matthewbadeau.github.io/OSHW-Logo-Autogen/)

The old thread: https://www.eevblog.com/forum/chat/oshw-logo-generator/ (https://www.eevblog.com/forum/chat/oshw-logo-generator/)

Remove parts of my code from oshwlogo.js or switch the license to GNU GPLv3 (the one I used).

I was a bit overwhelmed at work, I'll try to publish a new version today with text under logo option.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 12, 2016, 12:34:42 pm
There are hundreds of people telling me my font is wrong etc, it need to look this way and that way etc, or the entire concept is wrong/won't work etc

 :palm:

Unfortunately, that is always going to happen.  I've even thrown in a couple of thoughts ... but I realise they aren't really worth jumping up on a soapbox.

I support what Dave has presented.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: matthewbadeau on September 12, 2016, 02:11:38 pm
Hi All,
Sorry about the newbie mistake. I actually had made another forum post with my own logo generator but I would prefer to move all of that discussion to this thread. Here's a link to my take on the logo generator: https://matthewbadeau.github.io/OSHW-Logo-Autogen/ (https://matthewbadeau.github.io/OSHW-Logo-Autogen/)

The old thread: https://www.eevblog.com/forum/chat/oshw-logo-generator/ (https://www.eevblog.com/forum/chat/oshw-logo-generator/)

Remove parts of my code from oshwlogo.js or switch the license to GNU GPLv3 (the one I used).

I was a bit overwhelmed at work, I'll try to publish a new version today with text under logo option.

Which parts? I didn't use your code actually, I used parts of https://github.com/derrickpelletier/react-download-svg (https://github.com/derrickpelletier/react-download-svg) which is MIT licensed.
I didn't even notice that you had posted your version until the day after you were complete. I was kind of dumb and didn't actually see this thread until I had posted my generator code up  :-[

If you're seeing parts of your code in mine, which branch on github are you looking at? If it's the gh-pages branch, that code is minified and autogenerated. If it's the master branch then you'll see that I didn't copy any of your code, even the font's different.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 12, 2016, 02:26:01 pm
... truly OSHW ...

Therein lies the root of the current problem.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: kmel on September 12, 2016, 09:40:00 pm
why using another font, like Arial Black? OSHW already picked a font.
(https://www.eevblog.com/forum/blog/eevblog-921-open-source-hardware-problems-solved!/?action=dlattach;attach=255150)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 11:02:51 pm
... truly OSHW ...
Therein lies the root of the current problem.

Indeed.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 12, 2016, 11:11:01 pm
The OSHW association say they may do this in the future:
(http://i.imgur.com/hX2Kvt3.png)

http://www.oshwa.org/forums/topic/2-do-you-prefer-a-single-definition-of-openness-or-a-spectrum-of-options/ (http://www.oshwa.org/forums/topic/2-do-you-prefer-a-single-definition-of-openness-or-a-spectrum-of-options/)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 13, 2016, 12:11:09 am
why using another font, like Arial Black? OSHW already picked a font.
Cool.

What does the German one look like?

And what was "F" again?
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: apelly on September 13, 2016, 03:15:22 am
:)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 13, 2016, 03:21:23 pm
So just by the fact that other people don't say anything about it, means it's good enough???
That's a new way of working to me.
(don't think my boss and clients would apreciate that approach)

That's how these essentially crowd sourced and crowd legitimised ideas generally work.
If my categories were wildly wrong (either too many, too few, or inappropriate) then believe me, people would be jumping up and down about it.
So obviously my categories are close enough to be workable.

Quote
I'm thinking of suggestions, but the least I can tell you that for now a lot of people will be stuck.
The reason why I am pointing it out, is because it's an issue.

Then please explain in detail.
Who is going to be stuck?
Why isn't anyone else pointing out the same problem you think there is?
Even if some people are "stuck", no matter how many more categories you make, you won't be able to cover every possible scenario. It's going to be diminishing returns.

There are hundreds of people telling me my font is wrong etc, it need to look this way and that way etc, or the entire concept is wrong/won't work etc, but I currently count only one person who has said the categories don't cut the mustard.
I already gave multiple examples in the other topic. (would be nice if you could share that link/topic in the first post btw)
But just to give another example. Let's assume I am developing a bench power supply.
Including chassis, buttons, display, the whole thing.

So this project includes:
- Software (for interface, gui display, measurements)
- Electronics
- Mechanics (thermal mechanics, airflow, heatsink, fan, design chassis etc)
- Esthetics (the way the GUI looks like, logos, menu structure, design of the case etc).

First software, can be closed source or open source, and being made with open source tools or not, can have closed source plugins.
Second, electronics. Parts of the board can be shared, or completely. Can be drawn and in made in closed source or open source. BOM may be shared or not.
Third, mechanics. Maybe these files are made in Solid Works, thermal analyses is done in Mathlab or everything is done in CoCreate. BOM can be shared or not. Maybe CNC files are needed etc.
Last, esthetics. Design can be made in open source software or something like illustrator. Design files are maybe not shared or only shared for printing/showing or what's needed for CNC.

Conclusion, with the letters we are having now, there is absolutely no way I can use it at all!
So therefore it's extremely limited and in my opinion just not usable.
Especially if a project has a combination of open source and non-open source tools and programs.
Maybe someone can explain to me which letter I need to use if electronics BOM is shared, mechanics is not, and esthetics partly.
Plus firmware is shared, made in open source software, but contain closed source plugins.
Esthetics, which is part of the firmware, is not shared. So people can't change the menu structure and symbols.
Schematics of the electronics are shared, but the 'schematics' (= building instructions) of the case isn't.

The list goes on.

I am sorry, but for me it's just way to vague to put it all into 'CAD/Mechanical files'. A lot of things are interconnected.
Same for bill of materials or design documents.
Besides, it is very easy to mix up capital letters with small letters.

(BTW, in the logo generator the 'bottom of logo' option isn't completely working.


Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 13, 2016, 03:52:11 pm

Conclusion, with the letters we are having now, there is absolutely no way I can use it at all!
So therefore it's extremely limited and in my opinion just not usable.


So what do you think of the current situation, then?


I wouldn't be too worried about the suggested letters seeming to be limited ... they offer a far finer resolution.  There just has to be an adjustment in thinking, to allocate the project aspects being represented to the appropriate category letter.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Smokey on September 14, 2016, 03:27:32 am
hmm.. a whole 12 people posted comments on the oshwa forum...

At least one got it right....

http://www.oshwa.org/forums/topic/2-do-you-prefer-a-single-definition-of-openness-or-a-spectrum-of-options/#post-1974 (http://www.oshwa.org/forums/topic/2-do-you-prefer-a-single-definition-of-openness-or-a-spectrum-of-options/#post-1974)
makegeneve:
"I’ve been working in international standardisation for 20 years. There is no forum that I know of where they successfully had a convergent discussion on a definition of open. Don’t waste your/our time."
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 14, 2016, 07:35:44 am

Conclusion, with the letters we are having now, there is absolutely no way I can use it at all!
So therefore it's extremely limited and in my opinion just not usable.


So what do you think of the current situation, then?


I wouldn't be too worried about the suggested letters seeming to be limited ... they offer a far finer resolution.  There just has to be an adjustment in thinking, to allocate the project aspects being represented to the appropriate category letter.
In my opinion we have to focus much wider.
I have the feel that a lot of people work and think to much from their own little island.

What frustrates me big time, is just the current position and thoughts from the 'official' OSHW community/forum/website.
Which goes in exactly the wrong direction (talking about paid memberships and a fee to get a license, sorry but than you just don't get the point at all!)

I personally also don't care about the details now. If the symbol is blue, green, transparent. Hack even an hash, letters or numbers are just minor details.
What I am trying to do is to move the discussion to a more global level, were we can make a better general idea of the whole concept, but not limited to electronics only.

Because now people will get stuck, like in my examples.

I believe if we focus more on just the definitions with examples and explanations, a good logo design will pop out by itself.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 14, 2016, 11:22:34 am
But just to give another example. Let's assume I am developing a bench power supply.
Including chassis, buttons, display, the whole thing.
So this project includes:
- Software (for interface, gui display, measurements)
- Electronics
- Mechanics (thermal mechanics, airflow, heatsink, fan, design chassis etc)

These 3 are already covered with the F, S, P, and M symbols. I don't see your point here.

Quote
- Esthetics (the way the GUI looks like, logos, menu structure, design of the case etc).

Aesthetics have never been covered with any license. The only way to protect the look and feel of your product is to get a Trademark and/or patents.
This is an entirely different thing to
Nobody worries about protecting aesthetics in OSHW. It's not even in the current definition nor any open hardware related licences. Well, ok, you're the first to worry about it.

Quote
First software, can be closed source or open source, and being made with open source tools or not, can have closed source plugins.
Second, electronics. Parts of the board can be shared, or completely. Can be drawn and in made in closed source or open source. BOM may be shared or not.
Third, mechanics. Maybe these files are made in Solid Works, thermal analyses is done in Mathlab or everything is done in CoCreate. BOM can be shared or not. Maybe CNC files are needed etc.

These are already covered, I really don't see your argument here.

Quote
Last, esthetics. Design can be made in open source software or something like illustrator. Design files are maybe not shared or only shared for printing/showing or what's needed for CNC.

This is essentially covered under mechanical.

Quote
Conclusion, with the letters we are having now, there is absolutely no way I can use it at all!

Yes there is, easily.

Quote
So therefore it's extremely limited and in my opinion just not usable.

Sorry, I see zero merit in your argument here  :-//

Quote
I am sorry, but for me it's just way to vague to put it all into 'CAD/Mechanical files'. A lot of things are interconnected.

And like I said before, you could go into a hundred levels and permutations if you really want to, you have to stop at some point, it's diminishing returns.
Everyone seems to understand this which is why no one else has mentioned the categories are nearly enough to cover thing, or at least make a huge improvement over the current system.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 14, 2016, 12:12:08 pm
Hi All,
Sorry about the newbie mistake. I actually had made another forum post with my own logo generator but I would prefer to move all of that discussion to this thread. Here's a link to my take on the logo generator: https://matthewbadeau.github.io/OSHW-Logo-Autogen/ (https://matthewbadeau.github.io/OSHW-Logo-Autogen/)

The old thread: https://www.eevblog.com/forum/chat/oshw-logo-generator/ (https://www.eevblog.com/forum/chat/oshw-logo-generator/)

Remove parts of my code from oshwlogo.js or switch the license to GNU GPLv3 (the one I used).

I was a bit overwhelmed at work, I'll try to publish a new version today with text under logo option.

Which parts? I didn't use your code actually, I used parts of https://github.com/derrickpelletier/react-download-svg (https://github.com/derrickpelletier/react-download-svg) which is MIT licensed.
I didn't even notice that you had posted your version until the day after you were complete. I was kind of dumb and didn't actually see this thread until I had posted my generator code up  :-[

If you're seeing parts of your code in mine, which branch on github are you looking at? If it's the gh-pages branch, that code is minified and autogenerated. If it's the master branch then you'll see that I didn't copy any of your code, even the font's different.

Master branch, file
Code: [Select]
src/oshwlogo.js, lines 5-33 added in commit 88f2ba48764945b32e9568f67255bc8f07379b8, you just changed variable names. I wouldn't care because it's so small, but since you made the project a day after me, used the same idea and styling (just reversed), structured the logo code similarly and plainly copied the coords just changing names and adjusting for different font, I do. We are talking open-source here and there you are, using code without complying to the license. I made it GPL for a reason.

Updated the generator (https://maciek134.github.io/oshw-logo-gen/ (https://maciek134.github.io/oshw-logo-gen/)) with under logo option, now it uses paths so there is no problem with user not having font on their pc.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: matthewbadeau on September 14, 2016, 12:58:15 pm
Hi All,
Sorry about the newbie mistake. I actually had made another forum post with my own logo generator but I would prefer to move all of that discussion to this thread. Here's a link to my take on the logo generator: https://matthewbadeau.github.io/OSHW-Logo-Autogen/ (https://matthewbadeau.github.io/OSHW-Logo-Autogen/)

The old thread: https://www.eevblog.com/forum/chat/oshw-logo-generator/ (https://www.eevblog.com/forum/chat/oshw-logo-generator/)

Remove parts of my code from oshwlogo.js or switch the license to GNU GPLv3 (the one I used).

I was a bit overwhelmed at work, I'll try to publish a new version today with text under logo option.

Which parts? I didn't use your code actually, I used parts of https://github.com/derrickpelletier/react-download-svg (https://github.com/derrickpelletier/react-download-svg) which is MIT licensed.
I didn't even notice that you had posted your version until the day after you were complete. I was kind of dumb and didn't actually see this thread until I had posted my generator code up  :-[

If you're seeing parts of your code in mine, which branch on github are you looking at? If it's the gh-pages branch, that code is minified and autogenerated. If it's the master branch then you'll see that I didn't copy any of your code, even the font's different.

Master branch, file
Code: [Select]
src/oshwlogo.js, lines 5-33 added in commit 88f2ba48764945b32e9568f67255bc8f07379b8, you just changed variable names. I wouldn't care because it's so small, but since you made the project a day after me, used the same idea and styling (just reversed), structured the logo code similarly and plainly copied the coords just changing names and adjusting for different font, I do. We are talking open-source here and there you are, using code without complying to the license. I made it GPL for a reason.

Come on, really? I'm trying to see what you're seeing but I can't. For one, the coords you think I copied are different. Two, We're both basically taking Dave's idea and trying to match it with code. I mean, how far away in coords can you really get? He used a bold, sans serif font. I used a bold sans serif font. You also used a bold sans serif font.

I made mine MIT because the code that 'inspired' my downloader came from an MIT licensed react library that I decided to scrap later and the React Materialize code is all MIT licensed. It even turns out that my crap attempt at a downloader is superbly under par and if there was *one* thing I would have taken from your code, you would think it would have been that, right? I mean, my code's total crap, I use a dozen libraries just to get it running. Your code is nice, neat and short. If I had seen your code to start, I would have given up because it already does everything that Dave requests, mine is all just fluff.

I promise you that I didn't copy your code, or even draw inspiration from it. I didn't even know your project existed until I posted my crappy attempt a couple of days ago. Even the materialize theme was just because I can't do front end design. The materialize theme is Apache licensed, react-materilize is MIT licensed, React is BSD-3 licensed, even the modified logo that we're working on is CC0. I'm going to stick with MIT because that's the license the software I *actually* used to create mine.

This post probably won't convince you because you're pretty set on finding *something* that I copied, I mean, you had to search through something like 20 commits to find something that looked almost similar to yours.  :-// Either way, the next thing I wanted to add was a 1bpp bmp, where I was going to modify this MIT licensed code https://stackoverflow.com/questions/29652307/canvas-unable-to-generate-bmp-image-dataurl-in-chrome (https://stackoverflow.com/questions/29652307/canvas-unable-to-generate-bmp-image-dataurl-in-chrome) but I'm pretty tired, so I'm not going to do that anymore.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 14, 2016, 01:21:58 pm
But just to give another example. Let's assume I am developing a bench power supply.
Including chassis, buttons, display, the whole thing.
So this project includes:
- Software (for interface, gui display, measurements)
- Electronics
- Mechanics (thermal mechanics, airflow, heatsink, fan, design chassis etc)

These 3 are already covered with the F, S, P, and M symbols. I don't see your point here.

Quote
- Esthetics (the way the GUI looks like, logos, menu structure, design of the case etc).

Aesthetics have never been covered with any license. The only way to protect the look and feel of your product is to get a Trademark and/or patents.
This is an entirely different thing to
Nobody worries about protecting aesthetics in OSHW. It's not even in the current definition nor any open hardware related licences. Well, ok, you're the first to worry about it.

Quote
First software, can be closed source or open source, and being made with open source tools or not, can have closed source plugins.
Second, electronics. Parts of the board can be shared, or completely. Can be drawn and in made in closed source or open source. BOM may be shared or not.
Third, mechanics. Maybe these files are made in Solid Works, thermal analyses is done in Mathlab or everything is done in CoCreate. BOM can be shared or not. Maybe CNC files are needed etc.

These are already covered, I really don't see your argument here.

Quote
Last, esthetics. Design can be made in open source software or something like illustrator. Design files are maybe not shared or only shared for printing/showing or what's needed for CNC.

This is essentially covered under mechanical.

Quote
Conclusion, with the letters we are having now, there is absolutely no way I can use it at all!

Yes there is, easily.

Quote
So therefore it's extremely limited and in my opinion just not usable.

Sorry, I see zero merit in your argument here  :-//

Quote
I am sorry, but for me it's just way to vague to put it all into 'CAD/Mechanical files'. A lot of things are interconnected.

And like I said before, you could go into a hundred levels and permutations if you really want to, you have to stop at some point, it's diminishing returns.
Everyone seems to understand this which is why no one else has mentioned the categories are nearly enough to cover thing, or at least make a huge improvement over the current system.
The 3 categories are only partly covered.
I still don't have an answer what to do as in my example. So when different categories don't all share the BOM for example.
Or when some categories are closed source.

I am feeling I am talking in circles. I only see people saying 'they are already covered', but nobody explains really how.
As for now they are simple not, as proven in my examples.
Start to be a little frustrating actually.

Maybe I just expect to much at ones. Let's just go back to electronics only. :-\
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 14, 2016, 01:28:07 pm
Come on, really? I'm trying to see what you're seeing but I can't. For one, the coords you think I copied are different. Two, We're both basically taking Dave's idea and trying to match it with code. I mean, how far away in coords can you really get? He used a bold, sans serif font. I used a bold sans serif font. You also used a bold sans serif font.

I made mine MIT because the code that 'inspired' my downloader came from an MIT licensed react library that I decided to scrap later and the React Materialize code is all MIT licensed. It even turns out that my crap attempt at a downloader is superbly under par and if there was *one* thing I would have taken from your code, you would think it would have been that, right? I mean, my code's total crap, I use a dozen libraries just to get it running. Your code is nice, neat and short. If I had seen your code to start, I would have given up because it already does everything that Dave requests, mine is all just fluff.

I promise you that I didn't copy your code, or even draw inspiration from it. I didn't even know your project existed until I posted my crappy attempt a couple of days ago. Even the materialize theme was just because I can't do front end design. The materialize theme is Apache licensed, react-materilize is MIT licensed, React is BSD-3 licensed, even the modified logo that we're working on is CC0. I'm going to stick with MIT because that's the license the software I *actually* used to create mine.

This post probably won't convince you because you're pretty set on finding *something* that I copied, I mean, you had to search through something like 20 commits to find something that looked almost similar to yours.  :-// Either way, the next thing I wanted to add was a 1bpp bmp, where I was going to modify this MIT licensed code https://stackoverflow.com/questions/29652307/canvas-unable-to-generate-bmp-image-dataurl-in-chrome (https://stackoverflow.com/questions/29652307/canvas-unable-to-generate-bmp-image-dataurl-in-chrome) but I'm pretty tired, so I'm not going to do that anymore.

I didn't search through 20 commits, just clicked history on the file I assumed included my code. I wanted to point out that the coords are different, because you adjusted for a different font, but it doesn't matter because you convinced me it wouldn't make sense to copy something like that.

I never intended to stop you from working on your project, I'm terribly sorry if I caused that.

Side note: you can license MIT code on GPL, just not the other way around.

The 3 categories are only partly covered.
I still don't have an answer what to do as in my example. So when different categories don't all share the BOM for example.
Or when some categories are closed source.

I am feeling I am talking in circles. I only see people saying 'they are already covered', but nobody explains really how.
As for now they are simple not, as proven in my examples.
Start to be a little frustrating actually.

Maybe I just expect to much at ones. Let's just go back to electronics only. :-\

Well BOM on the logo is for electronics, I don't think it matters that much for mechanical (I may be wrong on that) - it's not like you can't work with the part if you don't know the exact kind of steel used. It shouldn't matter in which software the project was made in, sure it's nice if it's all open source software, but if a company makes the product without OSHW in mind and later decides to open it they shouldn't be penalized for using SolidWorks and Altium Designer. As for some things not being open source I can compare it to software - if I release only a part of my code I can't say the project is open source.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: mux on September 15, 2016, 09:00:51 am
The 3 categories are only partly covered.
I still don't have an answer what to do as in my example. So when different categories don't all share the BOM for example.
Or when some categories are closed source.

I am feeling I am talking in circles. I only see people saying 'they are already covered', but nobody explains really how.
As for now they are simple not, as proven in my examples.
Start to be a little frustrating actually.

Maybe I just expect to much at ones. Let's just go back to electronics only. :-\

I can see what you're trying to say, but I really have to agree with Dave here; you're trying to get too much resolution into a logo that's not even meant to convey all this information in the first place. You're already talking about the minutiae while the logo just describes in very rough terms what you can expect.

Like any open source license, there are going to be very specific details that you can't fit on silkscreen. So a project page with a more elaborate explanation of your efforts to adhere to the standard is going to be compulsory, if only to actually put the design files :P

This is like the pdf vs. open source vs. closed source EDA file discussion; it's basically moot what you use. If you want to reproduce the design but the files are in the altium format you just torrent altium, generate a pdf, uninstall it and you're done*. Who cares. If you need a proprietary ICE tool for an FPGA to reproduce the board you're just not going to fucking care because 1) you're already spending hundreds on a multilayer board and FPGA tools and 2) you already have the design files, you can just recompile it for your own favourite FPGA that you already own the tools for. None of the minutiae actually matter to a designer who actually wants to built on a semi-open source hardware project. All that matters is that the design files exist in some way, somewhere. From that baseline, you can improve, but it's sufficient in nigh-on all possible situations.

* just as an example of what people are more than happy to do: the ESP8266 open source toolchain basically requires you to run a VM with all kinds of aggressively user-unfriendly bullshit, do all kinds of command line stuff, all to directly program the MIPS processor in the thing. Everybody does this, people rarely complain. If people want to do a thing, it gets done.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 15, 2016, 09:37:32 am
if I release only a part of my code I can't say the project is open source.
That's how this whole discussion/video even started from????  :-// :palm:

I am not only talking about the silkscreen btw, just some kind of symbol/logo to see how open a certain project is.
See it as a energy label or so.

And sorry, but I don't believe it's to much to put into a logo.
I only have seen very weak arguments (or no arguments) so far.

@klh_js
I think it should be obvious that we're not talking about 'the type of steel'.
No I am talking about the mechanical structure and the components needed.
A CNC machine is a very good example for that. Without a mechanical 'schematic' it's gonna be a hell of a job the assemble the whole thing.
Same goes for some parts, and the original 3D CAD files, BOM etc
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 15, 2016, 09:44:35 am
If you go back and very carefully listen to what Dave is saying from @5:44 to @6:30 he is saying that it doesn't seem right that companies that want to use the logo but don't want to fully open their product to the community should be shunned by the community.

He says @2:25 that the OSHW logo "has kinda become a bit meaningless and has lost its value and that's a major problem" and @1:15 "people slap the OSHW logo on and it doesn't meet the OSHW definition"

This proposal is not trying to solve the problem of misuse of the OSHW logo by returning it to its original intent of showing that a product is actually fully open and not partly closed.

This proposal is trying to legitimise the use of the OSHW logo on not fully open (by any definition of open) products so that the scorn of the community will be eased.

So regardless of fonts colours and logos the key question is, is it justified to continue to use the OSHW logo on a merely documented but not fully open product?

So my solution to this problem of misuse of the OSHW logo is to say NO! it cannot be justified. The way to solve the problem of misuse of the OSHW logo in a non bureaucratic way is TO STOP MISUSING IT. It is the communities responsibility to continue to bring pressure to bear on companies who try to deceive people.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 15, 2016, 09:51:44 am
So regardless of fonts colours and logos the key question is, is it justified to continue to use the OSHW logo on a merely documented but not fully open product?

It doesn't matter if it's justified or not, people are using for not fully open products, probably the vast majority in fact.

Quote
So my solution to this problem of misuse of the OSHW logo is to say NO! it cannot be justified. The way to solve the problem of misuse of the OSHW logo in a non bureaucratic way is TO STOP MISUSING IT. It is the communities responsibility to continue to bring pressure to bear on companies who try to deceive people.

Not going to happen, that ha been tried and failed.
It's like the war on drugs, it's pointless and will never work, so might as well make them legal and stop putting people in jail for it.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Chris Mr on September 15, 2016, 10:08:26 am
Interesting to use the analogy of drugs.

Having considered the options on drugs, making them legal is great - unless you are living next door to someone using them who keeps you up all night, defecates in the street outside your house (or whatever, that's just a bad example to show that people can be a serious nuisance) and then says "it's legal".   Would do wonders for house prices if you live in a terraced street.

More to think about!
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: klh_js on September 15, 2016, 10:19:56 am
Interesting to use the analogy of drugs.

Having considered the options on drugs, making them legal is great - unless you are living next door to someone using them who keeps you up all night, defecates in the street outside your house (or whatever, that's just a bad example to show that people can be a serious nuisance) and then says "it's legal".   Would do wonders for house prices if you live in a terraced street.

More to think about!

You made the analogy better - if someone defecates on street or is loud during night hours it's still illegal - and from my experience with neighbors doesn't require drugs of any kind. If some company really overuses the logo, like using it to get funds and then not releasing anything we would have a problem - but this has nothing to do with the new logo, they can do that with the current one too.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 15, 2016, 10:43:41 am
Softdrugs like weed is already tolerated in NL for years. Offically on paper it's still illegal.
What it means that a police officer won't arrest you if they see you using it on a way that's debateble.
(like next to a school, bothering other people with it etc)
They will ask to put it away/trough it in a bin.
If you rufuse, they have the right to fine you or arrest you.

Barely anyone uses weed here, except the tourists. So I think it does work very well, but only on a way that's been tolerated, but on paper still illegal.

I personally never understand the strict black & white views on rules and laws. It makes things only more grim and worse. There are many grey scales
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 15, 2016, 11:08:30 am
It doesn't seem right that the community can create something for the good of all and just because some big players come in and abuse the rights of the community to decide how they want things to be, that the community has to roll over and let it happen. It's outrageous and unfair.

At least in the case of decriminalising the lesser drugs the community gets to decide how the police and judicial resources that they also pay for will be allocated.

At some point you have to make a stand because if you give away everything you will end up with nothing. If you redefine closed as open where will you be? Just ask a door.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Chris Mr on September 15, 2016, 11:25:04 am
Interesting to use the analogy of drugs.

Having considered the options on drugs, making them legal is great - unless you are living next door to someone using them who keeps you up all night, defecates in the street outside your house (or whatever, that's just a bad example to show that people can be a serious nuisance) and then says "it's legal".   Would do wonders for house prices if you live in a terraced street.

More to think about!

You made the analogy better - if someone defecates on street or is loud during night hours it's still illegal - and from my experience with neighbors doesn't require drugs of any kind. If some company really overuses the logo, like using it to get funds and then not releasing anything we would have a problem - but this has nothing to do with the new logo, they can do that with the current one too.

Sorry, I wasn't very clear.  What I meant was that being unable to control yourself, and doing antisocial things; being prosecuted what would the judge say if the accused says "I was on xxx your honour, it's legal, and I have no control of what I do when I am on xxx that's what it does to people which is why we take it - but its legal".

I know what you mean about neighbors, but if they're sober (whatever that is) you can at least talk to them and have a reasonable chance of them remembering.

b_force makes a good point about rigidity +1  :-+

From a legal perspective, a logo is either trademarked or not.  You only have to (literally) put TM by it (and say it is your property) rather than register it, the R in a circle just means registered (which you pay for).  Without either it is in the public domain who can do whatever they like with it.  With either you can restrict use, but you have to police it which costs.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: timb on September 16, 2016, 01:31:54 am
Interesting to use the analogy of drugs.

Having considered the options on drugs, making them legal is great - unless you are living next door to someone using them who keeps you up all night, defecates in the street outside your house (or whatever, that's just a bad example to show that people can be a serious nuisance) and then says "it's legal".   Would do wonders for house prices if you live in a terraced street.

More to think about!

You made the analogy better - if someone defecates on street or is loud during night hours it's still illegal - and from my experience with neighbors doesn't require drugs of any kind. If some company really overuses the logo, like using it to get funds and then not releasing anything we would have a problem - but this has nothing to do with the new logo, they can do that with the current one too.

Sorry, I wasn't very clear.  What I meant was that being unable to control yourself, and doing antisocial things; being prosecuted what would the judge say if the accused says "I was on xxx your honour, it's legal, and I have no control of what I do when I am on xxx that's what it does to people which is why we take it - but its legal".

That doesn't work. Think it through... Alcohol is legal, but if you get drunk and kill someone in a bar fight, you can't then turn around and say, "But I was intoxicated and not in control of my actions!" Why? Because you *chose* to drink the alcohol in the first place. You're responsible for whatever happens after that decision. If you kill someone, it's still manslaughter.

To more clearly illustrate this point, think about the following scenario: Someone with schizophrenia decides to stop taking his medication. He knows that, in the past while unmedicated, he's been violent. Despite that, he still stops taking his medication. This time, he kills someone during a psychotic episode.

Is he responsible? After all, he does suffer from schizophrenia, he can't help that, right? Well, legally, yes he is responsible because he chose to go off his meds. When he made that decision, he may not have meant for anyone to get hurt, but he should have been able to foresee the consequences based on his history, which makes it reckless disregard. (This actually happened about 20 years ago in New York.)

The More You Know! ~~~*
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 04:39:50 am
Yes.  Analogies can be helpful - at best - but all too often their shortcomings become distractions ... and no matter how irrelevant, these can take over and the original point is buried.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 04:48:25 am
Referring back to an earlier comment...

This is basically a religious debate about just what "open source" means.

It would seem there are indeed some hard line fundamentalists weighing in.


If I could borrow a relevant saying, I might be tempted to put forward the following proposition:

"They are so Heavenly minded that they are of no Earthly use."


While I completely understand the desire to "maintain the faith" - the implementation must be practical for it to be of any worth and for it to survive.  Whatever your beliefs, even religion itself has performed in this regard - and it has not been through the dogmatic insistence that you must be exactly like Jesus or Muhammad, or you should be put to death.


Yes, the OSHW concept is an ideal, but being uncompromisingly idealistic in a practical environment sets a path that leads to oblivion.

IMHO.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 16, 2016, 05:23:18 am
Referring back to an earlier comment...

This is basically a religious debate about just what "open source" means.

It would seem there are indeed some hard line fundamentalists weighing in.


If I could borrow a relevant saying, I might be tempted to put forward the following proposition:

"They are so Heavenly minded that they are of no Earthly use."

I've made some efforts to educate myself a bit since I said that. I still stand by it but I am now more aware of the issues surrounding the nature of OSHW. I am going with the relaxed position that hardware can be open if it can be copied and modified even with the need for commercial closed software tools. Or if you have to take a PDF and type it into a CAD package yourself that's also fine by me. If you want to do no work at all then you might just as well buy the original product because you can't be willing to do much work to add or modify the product. The fundamentalists would say everything must be open and I think there is a place for that in some cases but there will be less OSHW if that strict doctrine is inflexibly maintained. There is little point in sharing an OSHW product with Altium (or other expensive CAD package) files if it is for hobbyist markets because few hobbyists will have access to expensive tools. It is in this area that hardware differs from software. But if a hobbyist wants to take the pdf and enter it into Kicad then they can. Thereby the community has played a part in opening up the product further. I do not insist that a commercial vendor do all the work in porting designs to common open source packages. If the documentation is only available in English than some members of the community can translate it into other languages.

However, I am absolutely not going to get on board with calling OSHW open if it is not open even by the relaxed standard.  Because if it is not open I'm calling it closed.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 05:31:25 am
You're entitled  to your opinion, of course, but I believe - as do a number of others, including Dave - that the concept of 'open source' that you support limits its potential.


Also, I find it frustrating that the ultimate "openness" you champion can be identified and accommodated within the schema presented.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 16, 2016, 06:00:44 am
You're entitled  to your opinion, of course, but I believe - as do a number of others, including Dave - that the concept of 'open source' that you support limits its potential.


Also, I find it frustrating that the ultimate "openness" you champion can be identified and accommodated within the schema presented.

The concept of open source that I support is only that it has to actually be open to the lowest standard. No detail necessary to copy and/or modify it must be withheld. I don't see how that limits its potential. I am only demanding that it not be closed because some critical detail is not provided.

There is nothing more limiting to the potential of open source than masquerading something not open as if it is open. That is the crux of the issue. You do not need to annotate the OSHW logo to do that. You just need to not use it.

I'm afraid I do not fully  understand your last sentence. I do think the schema presented  is attempting to relax the definition of open to incorporate "not open".
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: b_force on September 16, 2016, 06:07:54 am
We don't have to debate about the definition.
The goal is to get more people into OSHW, period.

Limiting every with strict rules is not gonna help in that. Like my example (and also what Dave said in the video)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 06:54:30 am
Indeed.

Mudbloods and Muggles need not apply.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 16, 2016, 08:48:31 am
We don't have to debate about the definition.
The goal is to get more people into OSHW, period.

Limiting every with strict rules is not gonna help in that. Like my example (and also what Dave said in the video)
Flooding the OSHW community with closed hardware will not get more people into OSHW. That is the Homeopathic option for solving the problem.

Go and relisten to the video from about 5:44 to 6:44. Dave has his view and I simply do not agree with him. I am not an OSHW zealot. I hadn't even read the definition before a few days ago, so I am hardly qualified to fight the good fight on behalf of OSHW. I do however know that open does not include closed.

Only when agreement is reached that open includes closed will this concept have a chance of solving anything. Do you agree that open should include closed? If you say yes then Dave has a solution.

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 16, 2016, 09:01:05 am
Only when agreement is reached that open includes closed will this concept have a chance of solving anything. Do you agree that open should include closed? If you say yes then Dave has a solution.

Formal agreements do not matter, it's a fact that usage of the OSHW logo includes a majority of projects that are at least partially closed. The community has spoken and that's the result regardless of what position you hold.
This (inconvenient) fact is not open to argument, it's simply a fact.

Now, you can either do one of several thing knowing this
1) Keep screaming that OSHW should be 100% open. Ok, that's fine, but just understand that you are fighting a losing fight, history has shown this. This is what the OSHW association have effectively done, they have given up the fight and decided to start again with a trademarked logo and more rigid rules.

2) You can ignore the problem and hope it gets better or goes away.

or
3) You accept the problem and do something about it buy supporting partially open projects by encouraging changing the formal definition and implementing an idea like I have proposed.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 16, 2016, 09:04:15 am
There is nothing more limiting to the potential of open source than masquerading something not open as if it is open. That is the crux of the issue. You do not need to annotate the OSHW logo to do that. You just need to not use it.

Too bad that's not how it's worked out in the real world, and there is no changing that.
Keep hoping all you like, but it's not going to change, the majority of people will continue to use the OSHW logo without their project being fully open.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 16, 2016, 12:08:38 pm
There is nothing more limiting to the potential of open source than masquerading something not open as if it is open. That is the crux of the issue. You do not need to annotate the OSHW logo to do that. You just need to not use it.

Too bad that's not how it's worked out in the real world, and there is no changing that.
Keep hoping all you like, but it's not going to change, the majority of people will continue to use the OSHW logo without their project being fully open.

Look Dave, I know you are right that it will continue. I'm not expecting to change it. I just want people to understand that you cannot debate an issue if you are not focussed on the true core issue. I didn't think people here had properly understood that. It isn't about the logo, font, colours, letters or symbols, it is about accepting you have to abandon OSHW as a concept in practical usage.

So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value and listing out the documentation. What are you left with?

All I can see is the current problem flipped on it's head. Instead of solving the issue of not seeing at a glance what the not open product gives you, you will simply introduce the problem of people seeking an actual open product having to ferret throught the documentation to see what is missing. Is that what you want to call progress?

Like I said before the proposal you put on the table only really serves to cover the butts of commercial vendors pretending to be open. That, is what I am opposed to.
Owners manuals at one time included schematics and sometimes parts lists. It was just part of the products documentation. The world managed quite well not calling it open.

Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 12:53:11 pm
... it is about accepting you have to abandon OSHW as a concept in practical usage.
If OSHW fails in practical usage, then one has to question the original premise and ask: "If it can't succeed in practice, what value was there ever in it?"


Quote
So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value....

Oh, the irony.



I had more to say, but I'm going to save my breath.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on September 16, 2016, 12:54:36 pm
All I can see is the current problem flipped on it's head. Instead of solving the issue of not seeing at a glance what the not open product gives you, you will simply introduce the problem of people seeking an actual open product having to ferret throught the documentation to see what is missing. Is that what you want to call progress?

 :palm:
That's the current situation which is what I'm trying to improve here!
I'm done trying to explain it now, you obviously don't see the issue the way most seem to, and well, ok, that's fine.
Most people seem to understand the problem and get what I'm trying to do and support it, so that's a win.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on September 16, 2016, 12:57:20 pm
Thanks Dave  ....  that's the point I was typing when I came to the same conclusion as you.

I decided to walk away from another  |O
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: wilfred on September 17, 2016, 02:52:36 am
... it is about accepting you have to abandon OSHW as a concept in practical usage.
If OSHW fails in practical usage, then one has to question the original premise and ask: "If it can't succeed in practice, what value was there ever in it?"


Quote
So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value....

Oh, the irony.


Yes it IS ironic. THAT'S my point. That's exactly my point. No  :palm: no  |O needed. If OSHW can't succeed in practice why seek to continue with the use of the logo in some not open form in the hope that it encourages more people into OSHW? I strongly suggest everyone go back and REALLY LISTEN to what Dave is saying with particular regard to @5:00-@5:44. The video has a few inconsistencies and that 44 seconds is the only end result that I can see this "solution" seeking to address.
Go and listen to EEVBlog#195 @2:27-@2:37 https://youtu.be/I0HOgcbtmws?t=132


That there are so few people on the forum making a case either in favour or against what I am saying is the interesting issue. Dave's made at least two videos on it. Apparently it is a polarising issue in other forums why not here. Do people here really not care one way or the other or are they reluctant to voice their opinions for some reason? Is it FOGFP?

And if you really want to do what I did and educate yourself about the issue, read the definitions. I also watched a video put out by an acknowledged opinion leader in the community. I'm not making any of this up.

https://youtu.be/I0HOgcbtmws?t=424  Group Hug.

I'm just getting my opinion out there and I do try to add a little something new and avoid abusing anyone. I don't want to be  :palm: or  |O


Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: rs20 on February 23, 2018, 12:04:36 am
What if a given board has no programmable elements, and so doesn't require any software or firmware (e.g., an analog circuit/audio amplifier). As a mathematician at heart, I'd consider it valid to include an "F" for firmware on the symbol, because:
Would people here agree that that is reasonable to include the F for this reason, or would people consider it deceptive? I strongly think it's perfectly reasonable to include the F, but maybe that's just me.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on February 23, 2018, 12:52:28 am
What if a given board has no programmable elements, and so doesn't require any software or firmware (e.g., an analog circuit/audio amplifier). As a mathematician at heart, I'd consider it valid to include an "F" for firmware on the symbol, because:
  • Pedantically, all of the firmware that you need to get the PCB operating (i.e., the empty/null set) is available. (In the same way that evaluating AllOf([]) returns true in any decent programming language.)
  • Otherwise it would be impossible to have a fully decked-out gear symbol, even if I was doing absolutely everything possible and reasonable to make it maximally open-source, purely because my design is non-programmable.
Would people here agree that that is reasonable to include the F for this reason, or would people consider it deceptive? I strongly think it's perfectly reasonable to include the F, but maybe that's just me.

I wouldn't put the F.
I would trust that it's so obvious to people that there is no firmware in this product and hence why the F would be missing from the letters.
I can appreciate the desire to have a "fully decked out" gear symbol with all the letters when you are giving away everything in he design, and I realised this at the time but didn't really have a good solution for that scenario.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on February 23, 2018, 12:56:05 am
I also wouldn't put the F in there.  It implies there IS something.

If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: EEVblog on February 23, 2018, 01:10:14 am
I also wouldn't put the F in there.  It implies there IS something.
If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.

Yes, a dot or a dash or something that would imply N/A
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: rs20 on February 23, 2018, 01:19:31 am
I wouldn't put the F.
I would trust that it's so obvious to people that there is no firmware in this product and hence why the F would be missing from the letters.

As much as I would hope that people would be thinking that carefully and rigorously when looking at the symbol, I think you and I both know that the majority of people are going to interpret the symbol at a glance and mostly just look at its "density" -- I'm pretty sure only a small minority of people would connect all those dots.

I can appreciate the desire to have a "fully decked out" gear symbol with all the letters when you are giving away everything in he design, and I realised this at the time but didn't really have a good solution for that scenario.

Is clarifying the definition of F as I've suggested not a good solution? It's not even changing the definition, just clarifying what is currently a grey area. To make it crystal clear, I'm suggesting that the presence of F means "there is no closed-source firmware" (read: "no annoying roadblocks here!"). This definition is logically totally identical to "all firmware is open source"*, but the former makes it perfectly clear that F is perfectly allowable for an analog board -- and thereby preventing analog boards from being pretty arbitrarily disallowed from having fully decked out gear symbols. I know that you'd prefer that people not blindly demand fully decked-out symbols, but you sort of know that a lot of people are going to do so regardless, and to leave purely analog boards with the resulting marketing disadvantage as a result seems unfortunate.

* !AnyOf([a, b, c, ...]) === AllOf([!a, !b, !c, ...])

I also wouldn't put the F in there.  It implies there IS something.

This is a worrying implication -- it implies that the F only means "open source firmware is present". What if there are two programmable chips, one open source, the other (actually doing all the work) closed source? If we don't insist that the definition is "all applicable firmware is open source", then

If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.

This is a fine compromise, I would probably adopt this idea.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: rs20 on February 23, 2018, 03:29:15 am
Sorry for the double-post, but I was talking about this over lunch today and a colleague pointed out that by extending my logic, it would be legitimate to sell pineapples with Open Hardware Gear icons on the label with S, P and F letters on the basis that a pineapple has no closed source schematics, gerber files, or firmware/software. So perhaps a totally mathematically pure approach is not necessarily ideal.
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Brumby on February 23, 2018, 03:50:33 pm
LOL.  (Thanks, I needed that   :-+)
Title: Re: EEVblog #921 - Open Source Hardware Problems Solved!
Post by: Birger on March 13, 2018, 11:28:08 pm
Hi,

I created a Font with all permutations of the OSHW EEV-Blog style icon, and though it would be a nice thing to share it with the community.
Included in the attached zip-file are a true type font (ttf) and a Open Type font (otf).
Makes it easy to add logo to PCB's etc..

Enjoy
/B