On Saturday 25 November 2006 02:15, Timothy Miller wrote: > On 11/24/06, Jonathan J Smith <[EMAIL PROTECTED]> wrote: > > Back on this subject again huh?. > > > > This is really a can of worms. > > > > A definition like "Requires HDL", means that NOTHING designed out > > of common chips could be called open hardware, only things designed > > from the logic level up could be. > > Yes, "Requires HDL" is too narrow. This is why the GPL goes on about > preferred forms, etc. You have to be able to let people use standard > off the shelf chips, like RAMs and DVI transmitters, without needing > their internal designs. > > But see, OGD1 is designed so that we're not reliant on a specific > chip but rather, a standard interface. As long as something is > replacable in perpetuity, it's not any sort of practical problem.
But you can't programme the FPGAs we use without using a proprietary piece of software, since their internal structure isn't documented. The PCB artwork is definitely open, but the entire product isn't. But where is the limit? Do we want the HDL for the resistors too? The GPL says that the complete corresponding source code to a work does not include the compiler and standard libraries and so on that you would expect to find on a typical system. We could use a similar definition, stating that you don't have to have the source to commonly available parts. But what is commonly available? Discrete parts certainly are, simple 74HC chips are, perhaps even an x86 CPU could be considered commonly available, but I don't think that the FPGAs we use fall into this category. Perhaps this is where open standards compliant comes in? If there is a full specification of the part, then it could in principle be replaced by a newly designed, but completely compatible part. On the other hand, that would make a board with only a single open standard compliant chip on it open hardware if the board layout is under an open licence, even though the board is only a minor part of the product (if the chip is complex enough). > > Another variation might require that the person > > developing the firmware has access to information only available > > under NDA, with no encumbrances on said firmware being distributed > > for any and all to view/use. Is this Open Hardware compliant > > because NOT _ALL_ of the documentation is readily distributable? > > Again is this useful or not? > > So much open source software is undocumented... as long as we have > the designs and source code, we're happy. And there is free software that has proprietary documentation. If (and only if) the hardware itself is open, so that the documentation could (technically and legally) be derived from the hardware description, then I would find this acceptable. > > In my view things that encourage more and more "openness" and head > > the general state of affairs MORE that direction are probably more > > useful in the short-term/long-term than a very RIGID methodology > > that Does little to encourage or foster people, organizations, and > > companies to operate with as interaction with the open community as > > they can. > > Agreed. Agreed, but to a point. We need a rigid, ambitious definition of "completely open". We might add some lesser definitions to reward people who are at least moving in the right direction. What we definitely can not do is create a weak definition first, and then make it stronger as time goes on. That would result in companies making something open (according to our definition), and then being told "that's not good enough anymore, we want more" repeatedly. We can't do that. Lourens
pgpBb1QhxE6NE.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
