1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
## Access to NDA documentation
**Contents** [[!toc ]]
### What does NDA stands for?
NDA stands for Non Disclosure Agreement. This means, when you agree to an NDA, you are agreeing to not disclose the information you are receiving, to parties other than whom are listed in the agreement you are signing or agreeing to.
### Doesn't XFree86.org have NDA documentation?
XFree86.org had documentation for some pieces of video hardware that was obtained under NDA. They were not able to distribute that documentation to other people freely, only to others who had signed a blanket NDA with XFree86.org. That NDA was the primary feature of the XFree86.org member program.
XFree86.org has since ended its member program and the documentation they previously offered is no longer available.
### What are the steps that one should take to get NDA documentation?
Please read Frank La``Monica's doc, [[Managing Graphics Hardware Vendor Relationships in the Linux Developer Community|http://dri.sourceforge.net/doc/vendor_relationships_paper.html]]
### What're the reasons behind NDA?
I'd just like to comment a bit about the mechanisms involved here, at least as I myself see them. It is not limited to any particular vendor nor to any particular individual seeking information. Also, my comments are solely my own, and do not in any way reflect any opinions of my employer, or of any hardware vendors, etc.
In a perfect world, all vendors would just allow access to their documentation outright and freely. However, we aren't in that utopia yet, and they do indeed control access to their documentation, whether or not individuals like that or not. So, to get to that documentation, we very much need to play by their rules. Again, I speak of no particular company here, or individuals.
If they want to restrict access to information, then IMHO, there needs to be some mechanism in place to determine who gets documentation, and who does not get it. If it were as simple as: Joe Blow signs up, is automatically accepted without any question, clicks on NDA agreement, and then gets the docs, they might as well just publish the docs on their website freely for anyone to download anyways, as they wouldn't be restricting information at all.
Who should they give their docs to? Do they want just anyone having the docs? Or do they want competent developers that are most likely to really use the information to produce real results?
What metric gauges the decision? Does Joe programmer have a CS degree in 3D work, thus more likely to successfully use the information to complete some open source work? Is he a video game programmer? What has he done? Or is he just someone who is wanting to help, and is good intentioned, but might not actually have the skills and/or time to truly contribute? How do they know? For all they know, someone could say they are working on fixing a bug in XFree86, however actually they are working for a competitor for example. Who knows what the logic behind it all, or cares. Either way, some metric is needed to decide how to divulge information.
If the purpose of using an NDA is to restrict access to information, yet let capable individuals access that information to yield working results, and thus improve support for and promote a hardware vendor's product well, there needs to be some metric with which to gauge someone, and whether they are truly capable, or whether they are just "good intentioned".
If someone is working for a graphics company for example, is affiliated with some past work such as DRI, XFree86, perhaps has their name in the kernel credits for graphics work, or has some credential showing their capabilities, then it would stand to reason the chances are much higher that they could use the information and produce results. Probability-wise that is.
If someone is not working for a company who does graphics, or is writing video drivers, or affiliated with XFree86 and/or DRI, or some other similar thing, they could (not would, just could) potentially be a higher risk of information leakage IMHO. It stands to reason then, that a company may want to see some credentials before allowing access to information. By having people become XFree86 members first, I think it is a very good metric to see who is serious on working on code. XFree86 does not have difficult membership requirements, and any programmer who is capable of taking register level documentation from a hardware manufacturer, and producing useful results from it, is also very capable of quickly becoming an XFree86 member.
To do so, one need only fix a bug in XFree86, or perhaps add a feature, even something small. It is a small measure of one's capabilities to do the job. Once someone has passed the test of writing some small patch, that fixes something in X, they have shown some level of troubleshooting skill, some level of proficiency, and are much more likely to also continue to contribute to the project in the future. By passing that test, one can elect to join XFree86 as a member, which involves reading a web page, firing off an email, and then bouncing a few emails, agreeing to the XFree86 NDA.
Once one is an XFree86 member, they open up a lot of doors, including access to information that XFree86 has under NDA, and other private stuff. One can then come to a hardware vendor, asking for technical specifications under NDA with something more than "I know how to program C, and have good intentions", they can say, "I am an XFree86 member wanting to add support for foo, and/or fix bar in driver baz on your fooblaster card." I don't know of any XFree86 developer who has been refused information by vendors who support open source after having adequately went through the right channels, and proved that they are truly serious about the work they'd like to do, by passing a few litmus tests.
In all honesty, I think if someone thinks fixing a bug in XFree86 and becoming a member is too much of a hassle, then they are most likely not going to come through on any serious code at all anyways, and are thus more likely to be a information leak to a particular hardware vendor than an asset.
People certainly don't need to jump into the lake completely, it makes at least some sense to me that they should commit to dipping their leg in up to their knee, rather than just putting their toe in, and wanting full scuba gear. Scuba equipment given to them, may end up sitting on a shelf, rather than being used for whatever it is scuba divers use their equipment for.
OK.. that was an oddball analogy, but it does the job. ;)
My above thoughts on the logic involved behind these processes, may be way off mark, but that is what I've come up with, while watching the processes at work, and trying to look at the situation from the various different sides involved.
I guess it could be stated more like this:
* You can get much further with a smile and a few bugfixes accepted into the code base, than you can get with a smile alone.
You can quote me on that. ;)
-- [[MikeHarris|MikeHarris]]
---
[[CategoryFaq|CategoryFaq]]
|
