Re: Copyright from the lcs-projekt!? [dwarf@polaris.net: Re: First cut at testing and validation]
On Wed, 12 Aug 1998, Jules Bean wrote:
> On Wed, 12 Aug 1998, Dale Scheetz wrote:
>
> > On Wed, 12 Aug 1998, Jules Bean wrote:
> >
> > > I can't quite agree with Dale's approach on this.
> > >
> > > IMHO, the 'validate' program should be modifiable, but should have a
> > > clause dictating that any modified version must be distributed under a
> > > different name, and clearly marked as such.
> >
> > And just what purpose would this "new" forked version serve? Validate a
> > different standard? Do some other job instead?
> >
> > What "useful algorithm" am I keeping out of the hands of the rest of the
> > community by not allowing modification? The major portion of this package,
> > which is not visible in the script I published are the files containing
> > the lists of objects being checked. Change one character in any of these
> > lists and the validation proceedure will no longer be useful.
> >
> > This is a piece of software that serves a specific, narrow, purpose.
> > Allowing it to be modified only dilutes the strength of the test and the
> > standard.
>
> The question is, are we in the business of making exceptions? If your
I believe that from the point of view of the LCS/LSB committee, we would
prefer that you do not make an exception. It is not really desirable that
this become a Debian package. This is not a utility of general use. It is
a template, or a key, which fits your system when it is compliant. Moving
one prong or trough from the key makes it fit a different lock.
> program does genuinely warrant an exception, then the DFSG is broken, and
> needs to be modified slightly to allow it in.
>
> As to reason to modify: Yes, to validate a different standard would be
> one.
Which is totaly undesirable from the LCS/LSB standpoint, multiple
standards are worse than no standard at all. The details of this
validation code are proprietary to the standard, not the author.
> To correct a foolish bug which you made just before you went on a
> two-week holiday would be another.
This is not a "continuing" development project. Once the committee signs
off on the validity of the code, it, by definition certifies the
particulars of the standard that it was created for. While it may grow and
change as the standard goes to new versions, each of these new versions
will have their own validate suite.
> To propose for discussion a possible
> alteration would be a third - as in 'Here Dale, I think validate should
> work like *this* - what do you think of my version?'.
>
You can still do this with the current copyright. The only difference is
that you can't distribute your changes, but must convince the standards
committee that the change should be made. Only the standards committee has
the authority to change the standard and this code. The only reason my
name is on it is that I am the author, and there is no "entity" to sign
the copyright over to. (LSB is a private organization unrecognized as a
corporate entity that could own such property. Only individuals or
companies can copyright material.)
> >
> > >
> > > Furthermore, the LCS team could have on their websites the sizes and
> > > md5sums of 'validate' (and any other scripts, and documents, which have
> > > similar issues attached to them). This means that it is possible to
> > > verify a given copy of 'validate' as being correct, buyt still distribute
> > > it as free software.
> > >
> > This is already the plan. The tarball of the validation suite will be
> > found along with a README.lcs-validate that will give the md5 sum for the
> > tarball to ensure the proper result.
> >
>
> In which case, given that you are taking these precautions, I don't
> understand why you object to making it modifiable. There would seem to be
> no danger of subversion, if you create the README file you describe
> (especially if you sign it).
Any modification of the code creates a different standard, defeating the
whole purpose of the standard. Copyright produces an identity for the item
under copyright that can not be smudged in this fashion without smudging
that identity. The standard needs its own identity in a fashion that
cannot be smudged into non-existance.
>
> > > Dale: Would this not be appropriate?
> > >
> > It only serves the letter of the Free Software ideal, not the spirit. I
> > don't see a single advantage to allowing modifiability, and several
> > disadvantages to doing so.
> >
>
> I see a few advantages, and no disadvantage...
>
Then you haven't been listening to what I have been saying.
No disadvantage to you, doesn't mean there isn't one to others.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: