LibrePlanet discussion list archive (unofficial mirror)
 help / color / mirror / Atom feed
From: Arthur Torrey <arthur_torrey@comcast.net>
To: libreplanet-discuss <libreplanet-discuss@libreplanet.org>
Subject: Free Hardware - my USD$0.02
Date: Tue, 1 Feb 2022 22:04:50 -0500 (EST)	[thread overview]
Message-ID: <968298199.192204.1643771090797@connect.xfinity.com> (raw)

While it seems to me that much of this discussion has gotten to the point of flagellating dead equines, I thought I'd put in a few comments...

1. I am more in favor of "Open Source Hardware" as a term for 'design available' hardware than any variation on "Free" (Libre might be OK) because of a key difference between hardware and Free Software, namely that "Bits are free, Atoms cost money"...  I can give endless copies of my (as in 'on my PC', not as developer) Free Software to others without any significant cost, and without losing my possession of it.  But while I can give away the SOURCE of my hardware, I can't give away the actual device w/o cost or losing my possession of it....  Thus the design can be free, but not the actual 'atoms' that make it.  I.e. I can give away endless copies of my brownie recipe, but my supply of edible brownies is limited and cost me money to make...

2. Particularly in re the MIDI controller, but otherwise relevant - the manufacturer of an electronic gizmo is under no obligation to provide drivers for every known O/S, and is unlikely to spend the money it costs to develop them unless convinced that it will result in enough increased sales to justify the cost.  (economics 101) A friend I know is the maintainer of "Andy's Ham Radio Linux" which is an Ubuntu based distro focused on Ham Radio software.  He says he has had very good success dealing with the manufacturers of various radio products that only had software for other O/S by offering to write GNU/Linux software for them if they would supply him with enough info on their API to do so (and explicitly NOT asking for any info about the device internals beyond that) He said this has let him develop GNU/Linux software for several products, as he could make the case that this didn't cost the company anything while making their product more valuable...

3. IANAL, but I remember a presentation at an OSHWA conference several years ago that pointed out that the world of 'I.P.' (and yes Richard, I know you don't like the term) is very convoluted, but that an important aspect is that physical hardware is NOT protected under Copyright law, it is under Patent Law.  However the design documentation IS under Copyright law...  As such it would be possible to put the design documents under a Copyleft (or looser) license, but NOT the actual hardware device.  Further that there was no real equivalent of a Copy-left (Patent-left???) mechanism under Patent law.  In addition, without a hardware patent it wasn't legally possible to prevent a Copylefted design from being made private since a design made based on the Copylefted design with some changes would be a different product.

4. A question was asked about designing hardware from a schematic - I'd suggest looking at the workflow in KiCAD (Free software electronic design package) basically it starts with making a schematic (or importing in a KiCAD supported format).  Then you assign each component a "footprint" based on the physical dimensions of the actual part that will be used, and the manufacturer specs on required solder pad dimensions, heat sinks, etc.  The next step is to put all the footprints on the virtual PC board.  They will have an accompanying 'rats-nest' of lines connecting all the parts as described in the schematic.  Then you need to shuffle the parts around so that you can 'route' the rats-nest of lines so that they can be converted in to traces on the board, meaning they can't intersect unless the schematic calls for it, and meeting all the design requirements for things like current capacity, spacing, preventing electrical interference and all the other electrical engineering considerations that make the difference between theoretical parts and real ones...  This is probably the hardest part...  After your have a board layout, you feed it into a final process that generates all the Gerber files needed to actually make the physical board...

5. Not a lot has been made about the fact that while the detailed internal designs of chips is generally not available, the datasheet on ANY chip will have all the details needed to use it in a design, including functional block diagrams, electrical specs, timing and similar data, and so on...  If it is a programmable or processing (CPU) it will have the details about the commands / code that it 'understands' etc.  It would not be possible to use a chip in a design without this information.  Given the current real-world difficulties of making home-brew chips, there isn't a lot of point in having the detailed chip internal data as it isn't practically useful...  

6. It is worth pointing out that much (most?) physical hardware does NOT contain CPU's or other user programmable parts. (or even any sort of electronic / electrical bits) Often this hardware would be easier for user production....  Open source design concepts apply to this sort of hardware just as much (if not more so) than any electronic stuff.

7. The FSF has recently started pushing the idea of the 'Freedom Ladder' w/ 100% proprietary software at one end and "RMS level" refusal to use anything non-Free at the other...  A similar concept could easily be applied to hardware designs - how much info do they provide?  It seems that this sort of gradient approach is not unreasonable and provides a path to urge manufacturers of goods to follow as far as they feel comfortable...

ART

------------------
Arthur Torrey - <arthur_torrey@comcast.net>
-------------------

_______________________________________________
libreplanet-discuss mailing list
libreplanet-discuss@libreplanet.org
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss

                 reply	other threads:[~2022-02-02  3:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/libreplanet-discuss

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=968298199.192204.1643771090797@connect.xfinity.com \
    --to=arthur_torrey@comcast.net \
    --cc=libreplanet-discuss@libreplanet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).