Submitted by KernelTrap reports on an interesting discussion on the lkml. The specific topic is the legality of the ACX1xx wireless driver, which, according to Andrew Morton, will be included in the next kernel release (2.6.18). Jeff Garzik opened the discussion: “I’ve never had technical objections to merging this, just AFAIK it had a highly questionable origin, namely being reverse-engineered in a non-clean-room environment that might leave Linux legally vulnerable.” Christopher Hellwig posed an interesting point: “Please don’t let this reverse engineering idiocy hinder wireless driver adoption, we’re already falling far behind OpenBSD who are very successfully reverse engineering lots of wireless chipsets.”
Why not reverse-engineer video card drivers next and that too Linux binary drivers !
How do you think the r300 3D driver was developed?
Why isn’t it possible to use/port OpenBSD’s drivers instead of reverse engineering own ones?
I think that below the POSIX horizon you’d find an ABI nightmare that might make the porting less than fun, not that I’ve looked much at the Linux kernel code, and never at all at the OpenBSD source, mind you.
The real issue is cultural; the BSD license is not too distant from Public Domain, whereas the GPL makes heavy assertions about the meaning of freedom, and the motives of the coders.
Thus, IMHO, both collective sides of the issue need to find more capacity to tolerate foreign ideas if greater cooperation is a goal.
OTOH, I submit that, while possibly a tactical loser, the fact that FOSS supports a broad spectrum of motives for participation is a strategically Good Thing.
You really didn’t bother to look, did you? ^^
Linux doesn’t have an Application Binary Interface (ABI). But it has an API. And this API is rather clean. Well, in the most cases, anyhow. If you don’t dig too deep.
Linux kernel/module programming is much easier than, say, Microsoft Windows Module/Driver programming. Try to implement your own serial driver and you know what I mean.
I do agree, however, that there should be more cooperation between BSD and Linux. The problem, however, is not only of political nature, but also of legal nature.
Imagine a linux kernel developer taking the source code of a BSD kernel module. He add some fixes, changes this and that … and wants it added into the linux kernel. So he releases the whole thing under the GPL. Perfectly legal, since the BSD-License allows that kind of things. The reverse, however, is not possible; you cannot take linux source code and integrate it into BSD.
Now, I’m a big supporter of the the GPL. It’s the biggest invention/idea since Freedom with a capital F. But sometimes, it’s also making things a bit more complicated.
Maybe BSD should simply switch to GPL. ^^ Not gonna happen, mind you.
Imagine a linux kernel developer taking the source code of a BSD kernel module. He add some fixes, changes this and that … and wants it added into the linux kernel. So he releases the whole thing under the GPL
BS !!! Please stop spouting nonsense. He can’t license the all thing under the GPL because he is not the copyright owner !
Your example is completely flawed.
Perfectly legal, since the BSD-License allows that kind of things
NO ! No license can give you copyright !!
The reverse, however, is not possible; you cannot take linux source code and integrate it into BSD
Of course you can. What nonsense ! You can especially if you are the author of the code. How do you think dual license are possible ?
Now, I’m a big supporter of the the GPL. It’s the biggest invention/idea since Freedom with a capital F. But sometimes, it’s also making things a bit more complicated.
No you’re not. You’re again one of these astroturfers that we see coming from miles away, as you don’t even understand what you’re talking about.
“The reverse, however, is not possible; you cannot take linux source code and integrate it into BSD”
Of course you can. What nonsense ! You can especially if you are the author of the code. How do you think dual license are possible ?
Err, no, you cannot take a piece of GPL code and merge it into a BSD because… Then the end result must be GPL too. In other words, it is impossible to integrate GPL code into a BSD kernel if you desire the end result to be BSD licensed as well. If you were to do that, you’d be breaching the GPL.
Dual-license is indeed possible, but only if you are the copyrightholder (original author).
One cannot take GPL’ed code and use it in BSD-licensed project.
One can however take BSD-licensed code and use it in a GPL’ed project.
The only exception is if you are the copyright holder, in which case you can release the source under any license you want, including dual-, triple-, quadruple-licenses and what not.
The BSD-license (and the MIT-license) allows for sublicensing and therefore it can be merged with GPL’ed software, resulting in the combined source to be GPL’ed.
The reverse, however, is not possible; you cannot take linux source code and integrate it into BSD.
Bollocks,you only have to share the code that´s all.
Not if he wants to abide by the GPL-license. Unless of course he is the copyright holder.
One other way would be to rewrite the source from scratch using the GPL’ed source as documentation.
I think that below the POSIX horizon you’d find an ABI nightmare that might make the porting less than fun, not that I’ve looked much at the Linux kernel code, and never at all at the OpenBSD source, mind you
Not that you understand what a driver does either. The problem is not ABI or API, the problem is just understanding what to do with the data the driver receive.
The real issue is cultural; the BSD license is not too distant from Public Domain, whereas the GPL makes heavy assertions about the meaning of freedom, and the motives of the coders
Oh god, this BS again. If you talk license, you are already very far from Public Domain. Having a license means someone has a copyright, therefore you are as far as possible from public domain, where there is no copyright.
The type of license can’t make you closer to public domain.
The GPL does not make any assertion on the meaning of freedom : it’s a legal text, which uses the definition used in legal documents. How people can make so much flame bait ? So in a scientific text, you’d say people make too much assertions on the meaning of “mass” (or “weight”) ?
The GPL is a license for the code, so it applies to the code and its use. It doesn’t say anything about the motives of the coders or the meaning of freedom : that’s your straw man. That’s why people with opposite motives can equally write GPL code.
Thus, IMHO, both collective sides of the issue need to find more capacity to tolerate foreign ideas if greater cooperation is a goal
You didn’t even understand the problem. It’s not between BSD and Linux devs that lies the problem.
I think he means: Use the OpenBSD driver as your guide instead of reverse engineering.
it IS possible afaik, but I guess it has to do with pride. “I reverse engineered my OWN drivers! yay!” or something along those lines.
Besides, Reverse Engineering is GREAT cause it gives you more experience with hardware programing, something tha I feel EVERY OS writer should have and keep dear to his heart
Video card drivers would be GREAT, except I think there are slightly more restrictions, and there would be a more aggresive response. For example, to just DOWNLOAD nvidia drivers, you have to agree to a licence, which includes a “I promise not to reverse engineer…” section.
Overall I think that this is great. More people should reverse engineer! We need help!
–ZaNkY
> “I promise not to reverse engineer…” section.
Please SiS and ASUS, I give you my laptop with crap SiS 740 onboard and you’ll give me back 2500$ I paid for it.
Edited 2006-06-13 12:47
That license wont apply to many people though. They reverse engineer it with the clean room approach and give the specs to someone else.
Not much can be done, you cant apply a license to someone when their laws dont allow for click thru licenses.
Many people in the world can legally ignore that license and reverse engineer it. Then give those specs to someone (who would normally be required to abide by the license, but whom the license no longer applies to since they never actually touched the original licensed driver)
For example, to just DOWNLOAD nvidia drivers, you have to agree to a licence, which includes a “I promise not to reverse engineer…” section.
This doesn’t mean much in countries where you have a specific right to reverse engineer.
The MS EULA is mostly void in Denmark, since the copyright is pretty much limited to distribution (e.g. “copying”).
What I do with it on my own machine is my decision, and whatever knowledge I trip over, is shareable as I see fit. However I cannot distribute the original driver, unless the license grants me that right. I can however do pretty much anything else, no matter the license.
I see an emerging market for cheap commodity hardware with open specifications…
not in legal wifi.
the words ‘cheap’ and ‘type certification’ do not go hand in hand.
I’m not sure I’d take legal advice from Christoph Hellwig. AFAIK he was implicated in the SCO vs. IBM legal epic, as the SCO employee who contributed code to JFS.
One of the most impressive reverse engineering of wireless drivers on OPENBSD is the openHAL project.
There is an ongoing project to port it to linux from a guy here in greece. And I can say that it works pretty well.
But there are some people that say it’s illegal in many countries and that it cannot be included in the linux kernel. I can’t find any info on google to support this claim.
It would be illegal to include if the person just reverse engineered it, then wrote a driver.
Clean room reverse engineering is perfectly fine because you can find someone to write a spec to whom that license doesnt apply
The legal problem here is pretty much limited to USA. It’s a non-issue in EU-countries.
Perfectly legal, since the BSD-License allows that kind of things
NO ! No license can give you copyright !!
Then tell me how Microsoft took Kerberos (BSD) and did its own PROPIETARY MS-Kerberos not compatible with the BSD one.
Then tell me how Microsoft took Kerberos (BSD) and did its own PROPIETARY MS-Kerberos not compatible with the BSD one.
Because of how BSD license works, you are allowed to release a modified version of software without releasing the source. I have no idea about the specifics of Kerberos, but as long as MS did not attempt to claim copyright on other people’s code, they would be able to gradually turn it into a proprietary version, replacing the old code as they wanted, until they owned the whole thing.
Because the BSD license allows that sort of thing, but the GPL does not. It is perfectly allowable under the BSD license to take code and close it.
Reverse Engineering is illegal. At least here in the US, if one actually reads any agreements there is always the clause about can not reverse engineer. This applies to aoftware as well as Hardware. Every time I see this I cringe, as I like Linux, but unfortunately I see the same legal battles cropping up for wireless drivers and other such items as has occured with libdvdcss, making it so they can not be included or distributed.
“Reverse Engineering is illegal. At least here in the US, ”
No, it’s not. You can do it in a clean-room environment (different developers document the interface/write the code).
That is news to me, I will research it. I have seen 4 lawsuits won where reverse engineering was done exactly as you describe, so I find it difficult to believe. I know it can be done in other countries, just experience tells me otherwise for the US.
http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0000120…
This process is sometimes termed Reverse Code Engineering or RCE.[3] As an example, decompilation of binaries for the Java platform can be accomplished using ArgoUML. One famous case of reverse engineering was the first non-IBM implementation of BIOS which launched the historic PC clone industry.
In the United States, the Digital Millennium Copyright Act exempts from the circumvention ban some acts of reverse engineering aimed at interoperability of file formats and protocols, but judges in key cases have ignored this law, since it is acceptable to circumvent restrictions for use, but not for access.[4]
“The Samba software, which allows systems that are not running Microsoft Windows systems to share files with systems that are, is a classic example of software reverse engineering, since the Samba project had to reverse-engineer unpublished information about how Windows file sharing worked, so that non-Windows computers could emulate it. The WINE project does the same thing for the Windows API, and OpenOffice.org is one party doing this for the Microsoft Office file formats.”—http://en.wikipedia.org/wiki/Reverse_engineering
If you reverse engineer in another country, it is outside of US jurisdiction even if resulting code is used in the USA. Sp I hope that the wireless driver will be included in linux. it would be a very bad PR move by wireless chip manufacturer if they try to sue because of this.
As the started of the acx100 project at source-forge. I think I know at least a little bit about our project. Even though I’ve not participated in the actual code writing and have been more responsible for the initial management and website.
I think this whole debate is highly problematic. Not because some are concerned about the legality, no! Because it drives those developers who work sweat to get something working nuts and discredits them.
In this case we got a driver … not only for the acx100 chip, but for alike chips too. It even has been source for porting the driver to other systems.
Now we are debating weather this was legal or not. As far as I know, our development took place in Europe and last time I checked. Reverse engineering for interoperability was legal here. As it has been stated on the ML too: if this approach we took would mean exclusion of the Linux kernel, we’d probably have to take out quite a few others too.
Anyway, back to the root problem: The whole discussion is not helping those who actually worked on the project. It is actually going to get them frustrated to work on projects like this again. This is very sad
I feel very sorry for A. Mohr — who has been doing a hell of work for this driver and is a contributor to Wine too –, D. Vlasenko and all our other team members and testers.
kindest regards,
Moritz Angermann
Quite a healthy debate till now it seems – BTW this was posted on kerneltrap quite a few days ago .
The GPL can be a pain in the behind it seems if “real” life – that is companies or individuals who want to not “give away” their interlectual property they have been working on for years and or are also making a profit from – by being the sole provider to the market – by GPLing it .
The GPL foreces freedom onto contributed code – the viral behaviour thing again .
& the GPL 3 is suppossed to get worse in that respect .
Another problem without disrespect of any kind is that Richard Stallmann seems to come from the “everything free & must all share” corner while that conflicts with interests of companies & such .
BTW how was GPL version 1 ?
How about Linux under a BSD liscence … the GPL is getting more “radical” not less it seems to me .. so unlikely .
Good Luck Linux – should work all out somehow .
BTW congrats to the project as mentioned – C what the GPL serves up .. .
Edited 2006-06-13 22:43
It’s been known to happen, but rarely do I see a thread with so much misinformation and misunderstanding, even on OSNews. Yet me try to clear things up:
BSD-licensed code can be relicensed as desired by anyone, so long as they retain the existing copyright notice in the source. The Linux kernel devs can use whatever BSD code they want in the Linux kernel by relicensing under the GPL. The fact that they choose not to do so in the case of the ACX driver either means that the port from *BSD to Linux wouldn’t be worth the trouble, or that it would hurt their egos. I think it has to be a bit of both.
This is where I am not 100% sure, and someone please correct me if I’m wrong: GPL code may be included in a derivative work with BSD code without relicensing, because the BSD license places no restriction on redistribution not also required by the GPL. In other words, its requirements for redistribution are a subset of those of the GPL. So although the BSD devs might have some ideological reservations about this, I think it’s lawful.
However, none of this has much to do with the debate surrounding the ACX driver for Linux. The issue here is US law, specifically case law surrounding the DMCA that requires that reverse engineering be done in such as way that the team can prove it did not directly copy or decompile the original. The preferred method of formal proof is called a “clean room” approach, where one team analyzes the original and documents as much as they can figure out about the program without referencing any code, and another unique team that implements the new code based on the documents created by the first team. In case of legal action, the developers can produce the documents as proof of a clean room implementation.
Part of the debate centers around how much influence US law, or the unique laws of any other government, should have on the globally distributed development of the Linux kernel. If the team that did the reverse engineering did it outside of the US and/or they are non-US citizens, are they subject to the burden of proof required in the US? These are questions for which I don’t have an answer, and I’m not so sure anyone really knows how a US court or a European court might rule on these issues.
Finally, if the kernel devs do merge the ACX driver, who would be held responsible if a court rules this a violation of the DMCA, and what actions would need to be taken to protect Linux? Understandably, the ACX guys have kept pretty quiet about their side of the story, as how they procede and communicate might be damaging if this ever comes to litigation.
This is one of that issues where the OSDL should have a whole bunch of lawyers working round the clock to figure this all out. The kernel devs need to have the support of their legal representation to move forward responsibly. Let’s not repeat the recent Debian/Java flamewars already!!