Patrick McNamara wrote:
I am rather wary of trying to write our own license for several reasons: confusions and complexity being two of the big ones. The process of hammering out the license is complex if we actually try and take into account all the voices of the community and there will no doubt be confusion about what we are trying to do. Though I don't really know how much the confusion will matter.
I think you're right. Writing a new license from scratch would be fraught with problems, not least of which is that it would be incompatible (e.g. do you want to be able to use GPL-licensed cores from Open Cores?).
I believe the GPL applies here as it stands. The "code" for generating a chip is no different than the C/Java/Ruby/Forth/<insert your favorite language here> code used to create a computer program. Just the compilation steps are different.
While this is compelling from an engineering standpoint (it's a nice analogy), I think the language in the GPL is not clear on how it should be interpreted for hardware.
One way to solve that is to say explicitly what you mean in a "license grant", where you say something like: "For the purposes of this license, 'compilation' will be interpreted to mean fabrication of components mastered from the source documents" or some such wording.
> programmer's guide is needed. What should we call this? Open > Documented Hardware. Again, I agree. And while the OHF should support Open Hardware projects, if we are lucky enough to gain any influence, it should also lobby regular companies to produce Open Documented Hardware as JRT calls it. You could also call this Open Design Hardware.
I like calling it "Open Specification" hardware. Please, let's not use "Open Design" to mean this, because to me it sounds like you mean the design of the hardware is open (i.e. the other kind of "open").
The implementation may not be open, but all the details necessary to produce a compatible replacement are, assuming you have the skills and resources to do so.
Yeah, that's what I call the "specifications" for the implementation: essentially it's a description of the interfaces it must provide.
Though a number of them would be loath to admit is for quasi-religious reasons,
Frankly, I'm at peace with my "quasi-religious reasons". Sometimes the best reason for a thing is not the same as the practical reason. ;-)
Or as my English teacher used to tell me, "Every man has two reasons for everything he does: the perfectly reasonable reason he tells you, and the real reason". I imagine he was quoting somebody, but I don't know whom.
I would venture that most in the Open Source community would plenty happy if all that ever happened in the world was a shift towards open documentation of hardware. In reality, this is all the Open Source Software community really needs.
In the static sense, yes. But truly open hardware is a better way to ensure this in the long run.
Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
