lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: looking for space for lynx distribution


From: Bela Lubkin
Subject: Re: lynx-dev Re: looking for space for lynx distribution
Date: Mon, 25 Jan 1999 21:44:37 -0800

David Woolley wrote:

RMS>>>                                                                 and it
RMS>>> should not refer the user to any non-free documentation.  The need for
RMS>>> free documentation is now a major focus of the GNU project; to show

Bela>> This is the sort of crap which makes me want to run as far away from GNU
Bela>> and RMS as possible.

David> Although I haven't been following the pro and anti GPL arguments very
David> much, I think you may be overreacting here.  I think the problem that
David> he is trying to fight here is that a lot of GPLed code is not well
David> documented, because the authors are programmers rather than writers
David> as a result a number of authors have started writing documentation,
David> but have been doing this a as commercial exercise and producing
David> un-redistributable works.  As a result you have code that is free,
David> but unuseable.  Moreover, it is probably the coder that invested more
David> in the work than the documenter, but the documenter is making the 
profits.

It's good of you to think that.  Over the years I've come to have a much
more legalistic view of what RMS says, because that's how he uses those
statements.  They're written ambiguously so that you can give him the
benefit of the doubt -- oh, he's only trying to make things better.
He'll say so in interviews, too.  But if you actually get down to hard
negotiation with him -- "Tell us explicitly that the following
interpretation, which we don't like, is *not* intended", he refuses.
Sometimes he even says that he's leaving such things open in case of
future legal action.

David> (Interestingly, Microsoft, with all their resources, seem to write such
David> poor documentation that there is a large third party market - some of 
this
David> is people needing documents for pirate copies, but in the office, we buy
David> third party documentation for properly licensed software.)

This if off-topic, but I tend towards conspiracy theory on that.  They
write poor documentation to encourage a large aftermarket, so that when
you walk into a bookstore you are impressed with how much is there --
they must be the market leader.  (In _what_?  Bad documentation?  You're
not supposed to figure *that* out so easily.)

David> Another area he is probably trying to address is de facto bookware, where
David> the author writes and sells the documentation, but gives software away.
David> 
David> I think one third problem area is that some GPLed stuff, e.g. gtroff,
David> duplicate large portions of the function of existing AT&T derived
David> code and as a result, and presumably partly for copyright reasons,
David> the man page only documents the differences.  To allow people to use
David> the software without the original documentation, he needs to encourage
David> people to write complete documents.  (troff is documented in files which
David> were available from Bell Labs over the internet, but the restructuring
David> into Lucent Technologies may make these documents disappear.)

Great, so he should write something like "A GNU program should be
substantially self-documenting; you should not need access to
proprietary documents in order to understand the basic workings of the
program.  For instance, if your program is a reimplementation of a
proprietary program, it is not sufficient to document how it differs
from the proprietary program."  As written, "should not refer the user
to" is too broad.  It would prevent statements like "If you are
compiling foo on ProprietaryOS, you will need to use the POcc compiler,
which has a rather different set of compiler options and which tends to
vary from one release to the next -- see the POcc man page."

I read the subtext as "your GNU program should work poorly on
proprietary OSes; here's another restriction I have placed in order to
make that likely."

Bela>> man page describing that system's own internal idiosyncracies.  RMS
Bela>> isn't just trying to provide free software, he's actively trying to kill
Bela>> all commercial software entities.  (I work for one, so yes, I'm biased,
Bela>> but I don't think I'm unreasonable.)

David> I've got an email from RMS where he states that he is not trying to
David> kill commercial software.  I had suggested that the reason SCO didn't
David> supply certain industry standard FSF tools, except in Skunkware, was
David> the restriction on bundling, but that got challenged, and eventually I

It is the restriction on bundling.  He can challenge it all he wants,
but whenever *SCO* talks to him about this, he will *not* define the
limits in a manner which SCO's legal department finds acceptable.

David> had a direct exchange in which RMS defined the limits  more precisely,
David> which actually seemed reasonably generous.  Paraphrasing:  "mere 
bundling"
David> extends as far as run time linking, and it is only really static linking
David> that is a derived work.  You must clearly document the bounds of the
David> GPLed material and the alternative licencing, but you don't have to ram
David> it down a turnkey customer's throat.
David>
David> Given that you have rather higher a profile than myself in this area,
David> I think it might be worth trying to clarify the position directly.

I wish some sort of rapproachment were possible between SCO and RMS.
But I'm not the person who would make it happen, and I no longer have
any patience to try to fight it out with RMS anyway.

Bela>> As one of those contributors, I'll make the following additional points:
Bela>> 
Bela>>   *)  If you make this change, I won't be contributing any more code.

David> I'm not clear wether you are talking about long options flags, or
David> FSF accreditation.

The latter, of course.

That's not intended as "threats" or "bullying".  If Lynx comes under the
direct control of FSF, I will no longer be interested in its well being.
Fact.

=============================================================================

Ok, enough arguing about GNU, now on to my employer...

David> Incidentally, I tend to see SCO as something more akin to a Linux
David> distribution creator than an original software generator (I know you
David> have access to the source and will know the extent to which the freeware
David> and AT&T original code has been modified, and may be in a position to
David> challenge that).  Largely SCO is selling the adaptation of the code and
David> documentation**, to relatively unsophisticated commercial users, rather
David> than the actual code.

SCO's operating systems are extensively modified from their original
forms.  It is not "just packaging and documentation".  Of course, there
are specific self-contained pieces that are pretty much delivered right
out of public domain; e.g. wuftpd as the default ftpd (except that
certain changes were grandfathered in from earlier ftpd's, which turn
out to protect it against an upcoming security alert).

Futhermore, SCO's UnixWare line is under development by the same group
that descends lineally from the original AT&T Bell Labs Unix team.  This
is as if a Linux "distributor" had hired Linus Torvalds and dozens of
the other brightest lights in the Linux development world.  Would you
then call that company's product a "derivative, mostly packaging" work?

David> ** In the past I've had to use SunOS documentation to understand SCO UUCP

I would guess that was far in the past.

David> and the documentation in the original source package to fully understand
David> their MMDF.  This is essentially because the documentation has been 
David> editted down for the target market.

MMDF is a good example of a SCO screwup...  MMDF itself is a good
package, albiet a bit long in the tooth.  It was never well-delivered by
SCO, in part because there was always the sound of sendmail baying over
their shoulders.  "Should we put a huge amount of effort into
documenting this correctly, when every month it looks more and more
likely that we're going to bag it and switch to sendmail?"

>Bela<

reply via email to

[Prev in Thread] Current Thread [Next in Thread]