On Wed, Jul 14, 2010 at 10:32 PM, Dave N6NZ <[email protected]> wrote: > > On Jul 14, 2010, at 7:46 PM, Windell H. Oskay wrote: > >> >> On Jul 14, 2010, at 7:36 PM, Ales Hvezda wrote: >>> >>> And my usual questions: >>> >>> http://lwn.net/Articles/396011/ >> >> I've had some part in this. Whether or not proprietary design files can be >> compatible with open source hardware has been an active topic of debate, >> even amongst the people writing that draft definition. It's a tough, tough >> call, for all the reasons that Bunnie mentions. >> >> I think that the proper place to resolve this issue is in the actual >> *licenses,* which as with OSS may vary from permissive to restrictive. I'd >> like to see the evolution of at least one OSHW license where a requirement >> is that the design files for the project-- and its derivative works --need >> to be in open, documented formats. >> > That's the right answer -- let there be a battle of licenses. Although > hopefully, it is a small set and we avoid the "license salad" issues that > have sprung up in software. I, too, want to see (and would use) a license > where all source files for all aspects of the design are in open, documented > formats, but that isn't going to be to everyone's liking or practical in all > cases. > > But also, I'd like to point out that just having an open & documented source > language isn't really enough. What I really want in the end is a 100% open > source tool chain, and simply having an open file format isn't sufficient. > Example: FPGA's. Verilog source isn't going to help if the FPGA fitter tool > proprietary. So (thinking out loud) maybe some kind of license that says the > file format documentation *and* sources (or mirror pointers) for all the > development tools are a required part of the distribution source.
I too _want_ a 100% open source tool chain, but it's not going to happen anytime soon and I don't think it's appropriate to insist upon it in a license. If a developer wants his work to be maximally free, he should ensure that it _can_ be built with an open-source toolchain, but not that it _must_. Example: GCC and various GNU/Linux utilities. No software license that I'm aware of requires the use of an open-source compiler. Most open-source users choose to use GCC, but a minority compile with icc, armcc, or some other proprietary compiler. But the openness of GCC is such a draw that it completely dominates development of open-source C projects. GCC does not need license restrictions to compete with icc or armcc. Similarly, if there were an open-source FPGA fitter that worked worth a damn, users would switchover in droves. Furthermore, I'm not sure how one would require an open-source toolchain in a software license. Remember, we are talking about licenses, not contracts. A license can only grant privileges; it cannot restrict a user more than copyright law already restricts. Any restrictions that you want to place in a license must typically be restrictions on redistribution. So would your license require a developer to ship the source code of his FPGA fitter on demand to anyone who downloads his verilog LED blinker? I for one am glad that I don't have to ship the source code of the Python interpreter (and libraries) just because I distribute an open source program written in the Python language. -Alan > > -dave > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
