Slashdot Log In
Hifn Restricts Crypto Docs, OpenBSD Opens Fire
Posted by
ScuttleMonkey
on Wed Jun 14, 2006 07:45 AM
from the don't-tread-on-me dept.
from the don't-tread-on-me dept.
Mhrmnhrm writes "After totally closing off public access to documentation for their chips roughly five years ago, Hifn is again offering them, but with an invasive registration requirement. Needless to say, Theo de Raadt and the rest of the OpenBSD team were not amused, and following a Hifn manager's missive, the gauntlet has been thrown. Either open the docs fully, or be removed from the system. This wouldn't be the first time... the same thing happened to both Adaptec and Intel following similar spats."
Related Stories
[+]
Mobile: Update On OpenBSD Firmware Activism 134 comments
putko writes "Here's an update on the OpenBSD firmware activism. Basically, Intel says no. Plenty of contact info, in case you want to write someone an email or a phone call.
As Theo writes, 'Without
these firmware files included in OpenBSD, users must go do some
click-through license at some web site to get at the files. Without
those files, these devices are just bits of metal, plastic, and sand.'" While I applaud the notion behind Freer distribution (as in beer) it's also highly probable that Intel doesn't have much ground make them freer - we've seen this before on machines like the HP nw8000; basically, the wireless stuff is owned by someone else, licensed by Intel. That's not to say that the fight isn't worth fighting for freer distribution - it is. But if you want to make your voice heard, remember to be effective advocate.
[+]
Hardware: OpenBSD Clashes with Adaptec In Quest for Docs 367 comments
TrumpetPower! writes "OpenBSD developers have been asking for documentation from Adaptec for over four months. Adaptec's response has been to deliberately misunderstand what is being asked of them. A former Adaptec employee admits that the hardware is buggy and tricky to get right. So, as a result, OpenBSD 3.7 will ship without Adaptec RAID support. Personally, I'm glad that Theo isn't resting on his laurels."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Go Theo. (Score:4, Funny)
This should get really interesting.
Re:Go Theo-Batter up. (Score:5, Interesting)
OS developers' desires for unfettered acces, etc. No personal info should need to be given to a
vendor unless he's entering into a sales relationship with them. Honestly- too much risk of Identity
Theft through this sort of thing.
Seriously, I'd have to agree with him on this one- and I'm from the Linux camp and would be driving
sales into that segment very shortly. I'd be making a big stink about it too. And what's sad about
all these vendors is that they're doing nothing but pissing off the people that'd be helping them
sell chips.
In reality, the vendors are doing this because idiot IP lawyers tell them to do so. There should
be no IP revealed in the systems interfaces to a device. It should be the silicon equivalent to
an API. If there is IP honestly revealed, then you've got something new, and the patent itself
should be sufficient to protect it. If you're trying to hide a design flaw by not revealing info-
don't. You should design devices with interfaces that make sense and are system safe or can be made
so with the right device driver code.
Keeping it secretive helps nobody in reality. For example, ATI's drivers work adequately on the
desktop space but are less performant on at least part of the laptop line under Linux- because of
a design/coding flaw in the closed source drivers. I can't reccomend anyone get a laptop with an
ATI based display because they just don't seem to work as well. If someone had source code and
technical data access they could most likely fix the problems in question- unless the chip had a
design hickey. Even then, unless it's something that would compromise security, it should be
able to be coded around- Windows drivers can do Sideport memory correctly, why can't the Linux
support do the same thing?
At any rate, I believe I've drifted from the conversation... Yes Theo's got a niche play- but
in the segment that Hifn's in, it's an important one all the same.
Parent
Theo (Score:5, Insightful)
Oi, Theo! I agree with you 100%, but please, tone down the virtiol just a smidge! From TFA:
Calling their products "crummy" and threatening them with driver deletion if they don't stop "baiting" you is not a way to get what you want. Now it means some egomaniacal manager has to eat crow for the driver to go public. I was in 100% agreement with your post until I got to this point.
Sometimes, I wish someone would just slip some sort of tranquilizer in the water supply near Alberta...
Re:Theo (Score:5, Insightful)
Some people just do not listen unless you threaten them like this. It must've been the last straw..
Parent
Re:Theo (Score:5, Interesting)
Looking at the NetBSD issue, Theo was bitching about developers who kept introducing security holes - I dunno about you, but I'd bitch slap people who keep introducing security holes too, else you end up with something like Windows.
Parent
Re:Theo (Score:5, Interesting)
The problem is that Manufacturers seem to have the idea that they can dictate terms to the people who produce software to run on their hardware. Unfortunately, In the majority of cases, that appears to actually be the case.
The insulting thing in the original email was that he should be expected to comprimise his principles to support other people's profit, and as he is *not* being paid by Hifn, I personally see that it is well within his rights to not support the hardware in question.
Perhaps if you went up to some Civil rights protestor in the 1960's and said that this entire equality thing was a bit silly, and they should just accept these limitations, because its convenient for the asker, you may get a similar response.
Yes, i know this is a bit contrived, however, its worth noting that there are people who consider this sort of thing a matter of Civil rights. The right to be able to do whatever you want with the electronics in your computer, as opposed to what someone you have never met tells you.
Some people do consider this sort of thing a huge insult, and if putting it in plain language offends you enough that you dont use open source software, then i feel sorry for you. Your missing out on a lot of great software written by people who love what they do, however thats your choice.
Parent
Well, theres a surprise. (Score:5, Insightful)
i) is basically right
ii) still manages to sound like spoiled whiny tosser in the process.
Personal Info == Legal Tender (Score:5, Interesting)
From Theo's response:
Theo is essentially taking the position that personal information is tantamount to currency, and therefore, requesting personal info is tantamount to charging...hence, HIFN can no longer be considered Open Source. This position may currently be confined to OSS in general and the HIFN question in particular, but it's not difficult to imagine this argument generalized to apply to any situation in which an entity requests personal information. Personal info needs to be treated as the valuable commodity that it is...kudos to Theo for taking a stand on this issue.
Theo also addreses something many of us here are worried about:
Even disregarding the 'personal info == currency' argument outlined above, this objection stands on its own. HIFN is basically stating that yes, the info gathered will be handed over to the U.S. government on request, to satisfy their licensing requirements. This alone is a deal-breaker.
Theo sums his entire argument up beautifully here:
Well said, Theo. I for one don't care to support a company who engages in such practices, and I would rather see no support for a product than half-assed support, because the driver writers were not allowed full, unfettered access to the data sheets.
And finally from Theo's response:
Don't just say it, Theo, do it. If you stand by your statement, then HIFN has no place in the source tree, and should be deleted immediately.
Can hifn comply with OpenBSD's demands? (Score:5, Insightful)
The real question that should be answered is whether hifn are indeed required by law to ask personal information of the people downloading documentation, as hifn claims they are.
If they are, than hifn simply cannot comply with OpenBSD's demands without breaking U.S. law.
Parent
How does this sort of exaggerated response help? (Score:5, Insightful)
If he objects to providing that information, he can say so, but this sort of easily-refuted hyperbole doesn't help.
Oh for pity's sake... (Score:5, Informative)
How would this violate US Export Licences???
Fine, don't export chips overseas without knowing who you're selling to, but documentation? For driver developers no less?? When Hifn themselves are trying to say that this information is open and free???
This is the key point of Theo's argument, surely: that Hifn are not at all obliged to demand this information, and therefore are going against the principles of open access/source by demanding it. Can someone please explain what I'm missing here.
Re:Oh for pity's sake... (Score:4, Interesting)
How would this violate U.S. Export Licenses
It wouldn't. Exporting documentation...even source code...is protected as Free Speech, provided the export is in book format.
From this article [goingware.com]:
If you can export PGP source code without violating U.S. export restrictions, I'm betting you can export data sheets too. Therefore, HIFN's argument is invalid.
Parent
Gotta be some restrictions even on book format (Score:4, Interesting)
Parent
Abusive much? (Score:4, Insightful)
Whinge whinge whinge.. (Score:4, Informative)
past, but because your policies are privacy invasive towards us, and
thus completely thankless for the sales that we have given you in the
past -- we will not spend any more time on your crummy products."
Sales?
Unless Theo can give a decent estimate of how much 'sales' OpenBSD has 'given' them, I doubt the upper brass at Hifn cares about Theo's whinging.
If you want drivers for "less mainstream OS'es", please attach your request to a large multi-mega-million part order from <insert vendor here>. If you don't believe me, we'll, the only reason NVIDIA's Linux support is miles ahead of ATI is due to the demand from Hollywood setups to use high-end-5000%-margin professional cards on Linux, not geeks on Slashdot playing Tuxracer.
Simple solution to a stupid problem. (Score:4, Insightful)
Just give bogus information.
Everybody does! [brandrepublic.com]
Thanks, but no. (Score:5, Insightful)
Fair enough, Hank. But I reserve the right to not use proprietary crypto code in sensitive applications - which are the only ones that I'd actually buy hardware acceleration for in the first place.
Let's get this straight: there's a world of difference between closed video card drivers and closed crypto drivers. Many of us are squeamish about about the former, so why would you think we'd cheerfully accept the latter? A closed source video driver could potentially crash my non-networked game machine. A closed source encryption accelerator cold potentially open my VPN server to the whole world.
I hope you can appreciate the community's position here, but whether you agree with it or not is immaterial. Should you change your opinion to better mesh with that of your would-be customers, please let us know. Many of us would like to buy your products if they become usable for our applications.
Re:By my math... (Score:5, Insightful)
>Is this worth throwing a hissy fit over?
And I count one (1) principle at stake.
Which is *always* worth throwing a fit over.
Parent
Re:By my math... (Score:5, Insightful)
You have to sign an NDA to get the documents. So you would be violating the NDA to redistribute them.
There isn't a business advantage to this sort of secrecy because your competitors can easily obtain this same information through a blind. So it comes down to policy motivated by irrational fear & greed. Who needs to really deal with company with these qualities?
This topic is of primary interest to me because I am shopping for a crypto accelerator card right now, for use in the fall. Given the success and ease I have had using OpenBSD, and given the great support I have from the mailing lists, this is a reasonable criterion to use when purchasing hardware. In fact at some point of the decision making process for all of my hardware I have done a search on the OpenBSD mailing lists. This sort of information makes installation and maintenance a simple thing.
So it really does boil down to unless the OpenBSD group recommends a certain piece of hardware I won't buy it...
Parent
Re:Export regulations? (Score:5, Informative)
Hence, the docs that OpenBSD folks need (and had access to, until a few years ago) are NOT covered.
The choice is between "giving back access to documentation to allow developers to work with your hardware" or "keep track of developers for marketing purposes".
Export regulations enter the picture only if you don't know them.
Parent
Would that not be... (Score:5, Interesting)
Would that not be on documentation that explained exactly how the chip worked and not just how to send and receive bits from it?
If this is the case with HIFN, why do some other hardare companies in the same field not have the same restrictions?
There was a good comment made later in the thread:
Perhaps you can talk to your legal counsel and actually break out the documentation needed for these open source drivers into a separate and truly open to the "general public" anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations
....snip....
I understand it's very easy these days for attorneys to just say put everything behind your registration only access extranet to be safe. This is not acceptable and, in my opinion, is not open to the general public like you stated.
That sums up my thoughts much more succinctly.
Parent
Re:Export regulations? (Score:4, Informative)
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws. Cryptographic technology actually falls under an even more restrictive license class - munitions.
http://en.wikipedia.org/wiki/Export_of_cryptograp
Read the "Current Status" section. My point is that Hifn isn't "baiting" anyone. You might disagree with their lawyer or think it's your right to demand that Hifn fight "the man", but that's another issue.
Parent
Re:Export regulations? (Score:4, Insightful)
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws.
Please post links supporting this contention, or withdraw it.
Cryptographic technology actually falls under an even more restrictive license class - munitions.
Whle this is true, the source code can still be legally exported in written format, since it falls under Free Speech.
From this article [goingware.com]:
Given that, as you stated, crypto falls under the even more restrictive license class of 'munitions', if you can export PGP source code without violating U.S. export restrictions, I'm betting you can export data sheets too.
My point is that the HIFN's explanation of their requirement for personal info to satisfy their U.S. export license is pure codswallop, your nonsensical comments about HIFN 'fighting the man' notwithstanding.
Parent
Re:Export regulations? (Score:4, Insightful)
The applicable categories are obvious.
If they're so obvious, why didn't you post links to those categories, or better yet, applicable excerpts?
Don't forget to read interpretations
Fair enough...I read through Part 770 - Interpretations [gpo.gov], but strangely enough, the word 'documentation' is only used once in the entire document. I've posted the relevant passage for clarity:
Please explain how the above supports your contention that 'detailed hardware documentation is considered the same as the product under the export license laws'.
and supplement 2.
Which supplement 2? The Supplement No. 2 to Part 764 - Denied Persons List [gpo.gov], or the Supplement No. 2 to Part 774 - General Technology and Software Notes [gpo.gov]? (HINT: Neither supplement contains anything to support your contention that 'detailed hardware documentation is considered the same as the product under the export license laws'.)
In short, it looks like you thought you could try to justify your argument by pointing me to a ridiculously large government document, and then hoping I wouldn't bother to actually read it. You thought wrong.
I'm not going to respond to the rest of your rant,
Translation: I can't refute it, so I'll shut my eyes and pretend it's not there.
other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
And this from the person who qualified their original contention with 'AFAIK' and "IANAL'. Pot, meet kettle.
Parent
Re:Theo's behavior doesn't help the cause... (Score:5, Insightful)
If I have the choice, I run OpenBSD on servers because when it fits, it fits like a glove. If Theo acts like everyone else and just rolls over when a suit tells him no, OpenBSD would be just like every other Linux/BSD distro. This sort of attention to details (in both software and licenses) makes OpenBSD distictive. In marketing-speak, this is called 'developing a niche'. Within its niche, OpenBSD has no equal. If it looses its niche, then it will loose its market share. So I think the best thing Theo can do is to be Theo.
Parent