[OT] legal status of re-engineering (was Re: atheros driver - desc)
Sorry for again posting something OT, but I think the result of this discussion will in the end provide valuable input to a lot of driver authors. On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote: > On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote: > > Harald Welte <[EMAIL PROTECTED]> writes: > > > > > 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. > > > > Thanks for your answer, it cleared up things. I also don't want to > > discuss legal things here, we can discuss it more privately. But I'll > > just ask one more question in public: > > > > > So in general, at least if you're doing that kind of work within the EU, > > > I wouldn't be worried all that much. > > > > That's good news. But what about inclusion to the official Linux > > kernel? Can a driver reverse-engineered in EU be included to the > > kernel? (Big part of Linux is developed in US, I guess.) > > I will consult my legal counsel about this. Ok, as it seems the matter has not yet been investigated thoroughly enough from a legal point of view. The German institute for law and opensource software (http://www.ifross.org/) is interested in writing up and publishing a legal article on that subject, but that will certainly take some time for legal research, etc. I'll be advising them on technical matters and get back to you as soon there is some result. The analysis will be based on the EU copyright directive and should therefore be more-or-less valid for all EU member states. The US is totally different. As indicated before my holidays (just got back yesterday), I'll contact Eben Moglen about this, but first want to write up some explanations, questions, ... to give him the correct input. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpAZYDK7bU7G.pgp Description: PGP signature
Re: atheros driver - desc
On Fri, Aug 12, 2005 at 12:37:55AM -0700, Chris Wedgwood wrote: > On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote: > > > I will consult my legal counsel about this. My current naive > > position on this is that only the actuall process of the > > re-engineering matters, not the result. > > Which countries is this advice valid for? Does someone need to chase > this inside the US in parallel? I'll see whether I can get Eben Moglen to comment on that matter. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpEOdNBXlpM1.pgp Description: PGP signature
Re: atheros driver - desc
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote: > I will consult my legal counsel about this. My current naive > position on this is that only the actuall process of the > re-engineering matters, not the result. Which countries is this advice valid for? Does someone need to chase this inside the US in parallel? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote: > Harald Welte <[EMAIL PROTECTED]> writes: > > > 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. > > Thanks for your answer, it cleared up things. I also don't want to > discuss legal things here, we can discuss it more privately. But I'll > just ask one more question in public: > > > So in general, at least if you're doing that kind of work within the EU, > > I wouldn't be worried all that much. > > That's good news. But what about inclusion to the official Linux > kernel? Can a driver reverse-engineered in EU be included to the > kernel? (Big part of Linux is developed in US, I guess.) I will consult my legal counsel about this. My current naive position on this is that only the actuall process of the re-engineering matters, not the result. I'll get back as soon as I have a reply from my legal counsel. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpPZ66pwwvfD.pgp Description: PGP signature
Re: atheros driver - desc
Harald Welte <[EMAIL PROTECTED]> writes: > 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. Thanks for your answer, it cleared up things. I also don't want to discuss legal things here, we can discuss it more privately. But I'll just ask one more question in public: > So in general, at least if you're doing that kind of work within the EU, > I wouldn't be worried all that much. That's good news. But what about inclusion to the official Linux kernel? Can a driver reverse-engineered in EU be included to the kernel? (Big part of Linux is developed in US, I guess.) -- Kalle Valo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
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
Re: atheros driver - desc
Kalle Valo <[EMAIL PROTECTED]> wrote: | | This is great news. An open source Atheros driver which could be | included to Linux is really needed. | | But how was the reverse engineering done? I noticed that forcedeth | driver was implemented using the clean room design[1] and Linux | Broadcom 4301 driver project[2] seems to be using the same method. Reverse engineering was done by dissassemblying binary HAL and in harder parts by running it in userspace(yes, that is possible) and analysing input and produced output. The crucial part was to discover the meaning of hidden part of the structure describing device state. Once this was done it will be a little if no problem to me to provide updates for this driver, unless the whole binary HAL changes dramatically. That's one of the reasons I do this work myself. | | The reason I'm asking this is that I just wouldn't want see the same | happening this with this driver as happened during reverse engineering | of pwc Philips Webcam driver (some parts of the driver were removed | from kernel, but I believe the situation is now solved). If get into trouble I write documentation :-) I promise. | Actually, what are requirements to get a reverse engineered driver | included to Linux? Is clean room design an absolute must? It seems | that reverse engineering is needed if we want Linux support for most | of the WLAN cards on the market :( | Sad but true. The problem is not at vendors' side though. Look at FCC regulations... :/ kind regards Mateusz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
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. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
Mateusz Berezecki <[EMAIL PROTECTED]> writes: > The driver is not yet fully working because I didn't finish kernel > integration yet. Almost all > driver I/O ops are reverse engineered independently of openbsd openhal > which is missing just too much. > > > Ok, enough talking. Most of the atheros 5212 hal is now open :) This is great news. An open source Atheros driver which could be included to Linux is really needed. But how was the reverse engineering done? I noticed that forcedeth driver was implemented using the clean room design[1] and Linux Broadcom 4301 driver project[2] seems to be using the same method. The reason I'm asking this is that I just wouldn't want see the same happening this with this driver as happened during reverse engineering of pwc Philips Webcam driver (some parts of the driver were removed from kernel, but I believe the situation is now solved). Actually, what are requirements to get a reverse engineered driver included to Linux? Is clean room design an absolute must? It seems that reverse engineering is needed if we want Linux support for most of the WLAN cards on the market :( [1] http://en.wikipedia.org/wiki/Clean_room_design [2] http://linux-bcom4301.sourceforge.net/go/progress -- Kalle Valo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
On 8/5/05, Jeff Garzik <[EMAIL PROTECTED]> wrote: > There is no document describing the API AFAIK. > > The best thing to do is read over the ipw2[12]00 drivers. > > Jeff Ok, thanks for pointing me there. best Mateusz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
Mateusz Berezecki wrote: And regarding that ieee80211 API, I would be very excited if anyone could explain the general overview of how new wireless API works. I read the source but sometimes a quick answer from experienced kernel coder would do more good. There is no document describing the API AFAIK. The best thing to do is read over the ipw2[12]00 drivers. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
On 09:46 Fri 05 Aug , Bryan O'Sullivan wrote: > On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote: > > How far from working is it? I have a miniPCI Atheros card and would be > interested in helping out with bringing the driver up, but it would be > good to know what to expect first :-) > HAL is completely reversed, and it appears to work quite good. I have tested quite a lot using *cough* hardcoded solutions :-) What the driver is missing is integration with ieee80211 API from netdev tree, Wireless Extensions and I've recently added empty ioctl function templates. Basically that's what is missing. Nothing more, nothing less :-) And regarding that ieee80211 API, I would be very excited if anyone could explain the general overview of how new wireless API works. I read the source but sometimes a quick answer from experienced kernel coder would do more good. kind regards Mateusz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
Mateusz Berezecki wrote: Hi list members, I just post the code for review for anyone interested. I would be more than pleased to hear some feedback from you on the code. Im sending a series of 8 patches splitted and diffed as in SubmittingPatches documentation. The driver is not yet fully working because I didn't finish kernel integration yet. Almost all driver I/O ops are reverse engineered independently of openbsd openhal which is missing just too much. Ok, enough talking. Most of the atheros 5212 hal is now open :) sending patches... It's a good start. When you get a basic working driver, I'll push it into ieee80211 branch, and further review and work can occur. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote: > The driver is not yet fully working because I didn't finish kernel > integration yet. How far from working is it? I have a miniPCI Atheros card and would be interested in helping out with bringing the driver up, but it would be good to know what to expect first :-) http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
Hi. Mateusz Berezecki wrote: > Im sending a series of 8 patches splitted and diffed as in > SubmittingPatches documentation. Patch 4/8 is missing here. Bye, Mike -- Use PGP/GPG! My key: http://keys.indymedia.org/cgi-bin/lookup?op=get&search=62C29B94 Fingerprint: BC2E 79BF 0C8F 0282 864B 9CEC 8343 5169 62C2 9B94 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
atheros driver - desc
Hi list members, I just post the code for review for anyone interested. I would be more than pleased to hear some feedback from you on the code. Im sending a series of 8 patches splitted and diffed as in SubmittingPatches documentation. The driver is not yet fully working because I didn't finish kernel integration yet. Almost all driver I/O ops are reverse engineered independently of openbsd openhal which is missing just too much. Ok, enough talking. Most of the atheros 5212 hal is now open :) sending patches... Mateusz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
