Re: Copyright from the lcs-projekt!? [email@example.com: Re: First cut at testing and validation]
On Thu, 13 Aug 1998, Philip Hands wrote:
> > If the script says you conform, then you do. If the script has been
> > modified to say that you do when you don't, then the copyright holder may
> > sue.
> Only if you modify the existing script. You could come up with an alternative
> implementation, and the copyright holder has no right to sue.
> The copyright is just not buying you what you are claiming for it.
It does what I claim, just not what you claim.
> If this sort of thing really worries you, you should be going for LCS as a
> trade mark or some such, so that you could determine the times people could
> use the term.
If the copyright doesn't fix it what makes you think a trademark would?
> Apparently it does not really worry you though, because you dismissed my
> trivial ``it works'' script, with ``the community would beat you up if you
> tried it'' --- as they would if one did any of the things that you are
> claiming the copyright is protecting the world from (which it doesn't).
All such "bogus" scripts are just that, bogus. If the copyright is changed
to allow modified versions to be spawned from the copyright material, that
copyright gives those modifications authority that they didn't have
before. They are then "derived works", derived from the LSB standard. They
are then seen to have validity, as they draw from the source of that
standard for their very existance. The bogus scripts that you and others
have presented have non of that authority, and thus will be laughed out of
town. If the copyright allows such modified versions, those versions then
gain credibility that they would otherwise not acquire under my version of
the copyright. It is this divergence based on the standard that is to be
avoided at all costs. Other folks ideas of what a compatibility standard
can still be freely expressed in their own standard, but not by founding
it on the current one.
> > This sounds like you don't trust the committee to vet this softare so that
> > it is guaranteed to validate a system. I have no reply for that, as it
> > doesn't make the least bit of sense. Why would the standards committee do
> > something that would screw up the standard?
> Well there is a history of reference implementations, and standards being
> divergent (take X for example), and you first draft was buggy despite being
> trivial, so when can we be sure that the last version is bug free ? ;-)
No one has so far reported any bugs. You suggested an enhancement.
I suppose, given the current point of view, you will never be satisfied
that the program is "bug free" and the standard will fail. Providing
modifiable validation code does nothing to resolve this, because the
committee can never be any more sure about you than you are about them.
> > > Debian have no problems with standards!
> > Then it should have no problems with a program that validates the
> > standard.
> Let's decide that IE is a test suite for the HTML standard ...
On whose authority?
> > > No change of the standard. But changes of the code without lie the user.
> > >
> > As Debian is not the controler of the standard, neither should they be
> > able to modify it at will.
> Not even to make the verification suite actually check for the standard ?
This supposes that it doesn't.
> You are publishing draft scripts under a no-modification license, and there
> are going to be bugs in them, but we cannot fix and test those scripts for you
> at the moment, because of the license --- that doesn't strike me as
> particularly intelligent.
I'm not sure who the idiot is. I'm certainly not going to agree that it is
Since when does any license on any code, no matter how restrictive, stifle
the right to discuss ideas and issues. You just can't modify that
particular code to do it. Only the copyright holder can do so. Other than
that I see nothing in the way of developing and debugging the code in
> If you had presented us with a completed verification suite in all its shining
> perfection, then making it immutable might make some sort of sense, but surely
> you've been around software long enough to know that ``there's always one
> more bug'' ?
There is no answer that I can see, except, "So what?"
Nothing stops that supposed bug from becoming identified and corrected.
The only difference is that only the copyright holder can change the code.
As the intent is to satisfy the standard that seems appropriate to me.
What doesn't seem appropriate to me is an organization or person who
doesn't understand the standard, and thinks the code is broken because it
declares a distribution non-compliant (or compliant for that matter), the
standards committee has not way to keep the validation suite from being
changed, contrary to the wishes of the committee.
> You seem to think that modifying the verification suite is modifying the
> standard. How about if I am pretty damn certain (having read the standard)
> that my system complies, but the suite says it doesn't. One possibility, is a
Then there will be a way to pettition the standards committee about such
issues, but if you look at what the script is fundamentally about, (and
therefore the standard) it is about the placement and names of components
in the system. If the validation suite works on a compliant system then,
by definition, any system that it doesn't work on will be non-compliant.
That is, if the test -L fails to report true for the name /lib/libc.so.6
then some of the most fundamental components of the system being tested
are completely fubar, and the system is non-compliant. The same is true if
it reports true when the file doesn't exist, and that is, arguably, much
harder to detect with the script as written. Are you suggesting such
pathological systems exist and will cause trouble? Then we need you on the
committee sharing your knowledge, so we can come to terms with those
> bug in the script. Say I find what I believe to be the bug, and I want a few
> people with known good systems to test the patched version to ensure that is
> still declares their systems sound --- I cannot do it with the current licence.
Well, I agree that the letter of the copyright could be seen to forbit
this, but I wouldn't consider that "distribution" of the changes, unless
you passed them off as the standard without the authorization of the
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-