On Tue, 20 Nov 2001, Dorin Lazar wrote: >> Sorry to bother you again. I talked with the people from ATI - they said >> that (and I quote) >> >> Hello Dorin. >> >> I noticed in your form you are doing work with Linux. We have provided the >> necessary documents to the Xfree86 and DRI projects. In order to co-ordinate >> development efforts, we recommend you join one of the projects mentioned. >> >> Regards, >> Jason Schellenberg >> ATI Developer Relations >> [EMAIL PROTECTED] >> >> As it seems, it sort of the egg and the hen... >> Are those documents available, somewhere? They really think they are... >> Thank you for your time... >> Dorin Lazar >> >> On Thursday 15 November 2001 06:13 am, you wrote: >> > On Mon, 12 Nov 2001, Dorin Lazar wrote: >> > > > to check that out (utah-glx.sf.net). Many of us have documentation >> > > > from ATI as well, you can apply to their developer program for docs at >> > > > http://apps.ati.com/developers/devform1.asp >> > > >> > > I cannot get that kind of documentation. I am from Romania - there is no >> > > such option, nor "Other country" in their list... :( What do I do? >> > >> > I'd suggest sending an email to [EMAIL PROTECTED], as I can't speak for ATI >> > or their licensing or NDA policies. Perhaps it's just an oversight on >> > ATI's part in creating their registration form. They seem to be one of >> > the more friendly companies when it comes to helping open source >> > developers. Good luck!
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 Red Hat, 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, wether 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 competant 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 truely 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 guage someone, and wether they are *truely* capable, or wether 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 truely 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. ;o) 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. ;o) -- ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion: #xfree86 on irc.openprojects.net ---------------------------------------------------------------------- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
