On Sat, Aug 06, 2005 at 04:53:08PM -0400, Jeff Garzik wrote: > > It is certainly preferred that someone write a document describing the > hardware, and then a totally separate team write the driver, based on > that document.
No question to that. However, I think it largely depends on _where_ the actual re-engineering is done. Here in Germany, the copyright law is perfectly fine with reverse engineering, as long as you don't actually decompile. The intent of the law is to prevent you from gaining access to the source code (which isn't possible in heavily optimized compiled languages anyway). There is no problem with trying to learn how the program works and what it actually does. All over the EU, the EUCD states that you are explicitly allowed to do _any_ kind of re-engineering for the purpose of compatibility / interoperability (and you want to make that card interoperable with the linux OS...) All you need to do is to ask the copyright holder for the required documentation. If they don't produce it within a given timeframe (IIRC one month), then you can go and start re-engineering without the approval of the copyright holders. Also, lots of the low-level driver routines are not copyrightable works anyway. If you need to set up the registers of a device in a certain sequence in order to get it work, then there is no other way of doing so. Therefore the corresponding source code is not the result of a creative process of the author. I don't want to turn this list into a list of legal discussion, but since I'm heavily dealing with exactly those issues during my gpl-violations.org efforts, I thought I share some of the facts. So in general, at least if you're doing that kind of work within the EU, I wouldn't be worried all that much. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
pgpzWxFMnk40J.pgp
Description: PGP signature
