|author||Denys Vlasenko <firstname.lastname@example.org>||2010-08-07 11:55:58 (GMT)|
|committer||Denys Vlasenko <email@example.com>||2010-08-07 11:55:58 (GMT)|
slight tweaks to license.html
Signed-off-by: Denys Vlasenko <firstname.lastname@example.org>
1 files changed, 13 insertions, 8 deletions
diff --git a/license.html b/license.html
index 336f963..acd7a8e 100644
@@ -107,7 +107,7 @@ source tarball:
<p>B) bundle a written offer good for three years to provide source upon request
(these days this is often a URL).
-<p>C) point you users at the upstream source (I.E. pass along somebody else's 3B
+<p>C) point you users at the upstream source (i.e. pass along somebody else's 3B
<p>Using option 3A, that is, putting exact BusyBox source and .config file
@@ -126,7 +126,7 @@ from the company's website. Give exact URL to the page where it can be downloade
<p>Regardless of whether you use option 3A or 3B, please make sure
you distribute the <em>exact</em> same source tree you used to build the binary.
It doesn't have to be a single archive. Indeed, most people distribute modified
-sources in the form of unmodified BusyBox-N.N.N.tar.bz2 archive
+sources in the form of unmodified busybox-N.N.N.tar.bz2 archive
and a set of patches which add features or fix problems.
<p>If you added an applet, or an option to one of the applets in BusyBox,
@@ -273,7 +273,7 @@ and let them know where the source is. All this is the lawyerly equivalent
of "raising your voice to be heard". I've only seem them take the gloves off
once. They've only <em>needed</em> to once.
-<p>A lot of companies get in trouble because although they use an upstream
+<p>Some companies get in trouble because although they use an upstream
vanilla source tarball, they don't say what version it was, or they don't
explicitly say it wasn't modified. Then when we approach them for more
information, they don't understand what we could possibly want, and panic.
@@ -333,9 +333,14 @@ distributing the firmware for their WRT54G Router.</a>
Following their example would be a fine way to ensure that you
have also fulfilled your licensing obligations.
-<p>Ideally, what the BusyBox developers really want is for people who develop a
-product using BusyBox to post a message to the BusyBox mailing list when
-their product ships. What's most useful to <em>us</em> is something like:
+<h3>Add yourself to the Products page</h3>
+<p>We (BusyBox developers) would be happy to add the information about your
+product which uses BusyBox to our Products page. In order to be added there,
+post a message to the BusyBox mailing list when the product ships.
+While at it, the following information would cover the GPL licensing questions
+about the product:
<p>A) a description of the product (including the build environment: processor
type, libc version, kernel version).
@@ -346,9 +351,9 @@ type, libc version, kernel version).
nicely broken up series of "diff -u" patches on the web, or attaching the
patches to the message, or explicitly saying it isn't modified).
-<p>D) attach the BusyBox .config file you used to build the thing.
+<p>D) attach (or give URL to) the .config file you used to build the BusyBox binary.
-<p>E) A link to your website, so we can add it to our products page.
+<p>E) A link to your website.
<p>This is the "being nice to the developers" approach, which acts as a sort of
free advertising within the developer community.