Author Topic: EEVblog #921 - Open Source Hardware Problems Solved!  (Read 41144 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #75 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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #76 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.
 
The following users thanked this post: thm_w

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #77 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
 

Offline pickle9000

  • Super Contributor
  • ***
  • Posts: 2132
  • Country: ca
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #78 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.
 

Offline klh_js

  • Contributor
  • Posts: 9
  • Country: pl
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #79 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/ for OSHW projects?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #80 on: September 10, 2016, 09:31:47 am »
It's up: 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.
« Last Edit: September 10, 2016, 09:38:30 am by EEVblog »
 

Offline suku

  • Contributor
  • Posts: 43
  • Country: hu
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #81 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
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 877
  • Country: gb
  • Embedded stuff
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #82 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.

Bob
"All you said is just a bunch of opinions."
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17631
  • Country: nl
    • NCT Developments
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #83 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).
« Last Edit: September 10, 2016, 11:45:31 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #84 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!)
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline b_force

  • Super Contributor
  • ***
  • Posts: 1180
  • Country: 00
    • One World Concepts
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #85 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.
"If you can't explain it simply (or at all), you don't understand it well enough." A. Einstein

http://www.oneworldconcepts.com/ | http://www.soundprojects.com
 

Offline b_force

  • Super Contributor
  • ***
  • Posts: 1180
  • Country: 00
    • One World Concepts
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #86 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.
"If you can't explain it simply (or at all), you don't understand it well enough." A. Einstein

http://www.oneworldconcepts.com/ | http://www.soundprojects.com
 

Offline Tabs

  • Regular Contributor
  • *
  • Posts: 106
  • Country: gb
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #87 on: September 10, 2016, 02:44:01 pm »
It's up: 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

 

Offline silicon_ghost

  • Contributor
  • Posts: 28
  • Country: us
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #88 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.
 

Offline doobedoobedo

  • Regular Contributor
  • *
  • Posts: 206
  • Country: gb
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #89 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"
 

Offline wilfred

  • Frequent Contributor
  • **
  • Posts: 785
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #90 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/ and here 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.


« Last Edit: September 11, 2016, 01:14:13 am by wilfred »
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 9215
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #91 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.)
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 9215
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #92 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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #93 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.
 

Online amspire

  • Super Contributor
  • ***
  • Posts: 3752
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #94 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.

« Last Edit: September 11, 2016, 09:35:16 am by amspire »
 

Offline Tabs

  • Regular Contributor
  • *
  • Posts: 106
  • Country: gb
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #95 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

 

Offline doobedoobedo

  • Regular Contributor
  • *
  • Posts: 206
  • Country: gb
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #96 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:

 

Offline b_force

  • Super Contributor
  • ***
  • Posts: 1180
  • Country: 00
    • One World Concepts
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #97 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.
"If you can't explain it simply (or at all), you don't understand it well enough." A. Einstein

http://www.oneworldconcepts.com/ | http://www.soundprojects.com
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #98 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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29658
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #99 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.
 
The following users thanked this post: ludzinc


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf