Work on the website.

* Note that we encourage free reuse too, not just redistribution.
* Some OEM kits are just boards, EVKs usually to have nice cases, full
  documentation, proper power supplies and test software.
* We may describe a chip/protocol/system in a human-friendly document, not
  just in the source somewhere.
* Clarify that we try for broad operating system support by inviting fans of
  various UNIX-ish environments. I know we have a couple of OSX users on-list.

1 files changed, 11 insertions, 10 deletions

diff --git a/www/for-vendors.html b/www/for-vendors.html
index 78283407..dff69860 100644
--- a/www/for-vendors.html
+++ b/www/for-vendors.html
@@ -89,8 +89,8 @@ works:</p>
 
 <p>Open-source projects are mostly manned by volunteers attracted to a
 particular technical problem; the results are published as source code
-under licenses that encourage free redistribution, and are freely
-available to all.</p>
+under licenses that encourage free reuse and redistribution, and are
+freely available to all.</p>
 
 <p>By harnessing the power of peer review, this process has been
 found to lead to a significantly higher average level of code quality
@@ -161,7 +161,7 @@ hardware.</p>
 
 <p>We will need complete protocol documentation for your product(s).
 If you are a chip or GPS-board vendor, this probably corresponds to
-what you ship with your OEM kit.</p>
+what you ship with your OEM or Evaluation kit.</p>
 
 <p>Note that we are a typical open-source project in that we do not
 sign NDAs &mdash; even if we wanted to, nobody on the project has the
@@ -169,16 +169,16 @@ authority to bind any of the other developers to an NDA.</p>
 
 <p>Be aware that any portions of the information you give us that are
 relevant to our programming task will be expressed by publicly
-available source code that anyone can read. The effectiveness of our
-development process &mdash; and all the benefit of it for your company
-&mdash; depends on this.</p>
+available source code and user documentation that anyone can read.
+The effectiveness of our development process &mdash; and all the
+benefits of it for your company &mdash; depends on this.</p>
 
 <h3>2. Evaluation units</h3>
 
 <p>We will need no fewer than one (1) and no more than three (3)
 evaluation units of each product you want supported.  These units
 cannot be loaners.  As we develop GPSD going forward, we frequently
-need to regression-test the software against supported hardware.</p>
+regression-test the software against supported hardware.</p>
 
 <h3>3. A technical liaison.</h3>
 
@@ -189,9 +189,10 @@ but you will find it is greatly to your advantage to have someone at
 the table.</p>
 
 <p>We feel safe in predicting that many of your development staff are
-already running Linux at home anyway, because engineers do that.  We
-strongly suspect that if you internally broadcast a request for a
-Linux enthusiast to work with us you won't be short of choices.</p>
+already running a Linux, BSD or other UNIX-like operating system at
+home anyway, because engineers do that. We strongly suspect that if
+you internally broadcast a request for a Linux or UNIX enthusiast to
+work with us you won't be short of choices.</p>
 </div>
 <hr/>
 <script language="JavaScript" src="datestamp.js" type='text/javascript'></script>