Re: xinetd license possibly violates DFSG #4

[Sam Hartman <hartmans@debian.org>]

>>>>> "Branden" == Branden Robinson <branden@debian.org> writes:

    Branden> On Mon, Jun 14, 2004 at 10:24:44AM -0700, Josh Triplett
    Branden> wrote:
    >> Side note: while researching this further, I discovered that
    >> the xinetd license requires keeping the original version number
    >> and only appending new numbers:
    >> 
    >> > 1. The version number will be modified as follows: > a. The
    >> first 3 components of the version number > (i.e
    >> <number>.<number>.<number>) will remain unchanged.  > b. A new
    >> component will be appended to the version number to > indicate
    >> the modification level. The form of this component > is up to
    >> the author of the modifications.
    >> 
    >> While DFSG4 does allow licenses that "require derived works to
    >> carry a different name or version number from the original
    >> software", this seems to go much further than that, since it
    >> requires keeping the original version number.  There is a note
    >> in the license file giving the current upstream maintainer an
    >> exception, but that does not change the requirement for other
    >> distributors.

    Branden> I agree; this goes too far even for DFSG #4.

I think I'll probably end up agreeing with you if I consider this long
enough.  However it would make things much simpler if you could think
of a case where this limitation would affect our users' freedom in
some important way.

For example, how is this different than requiring that the software
say it is based on xinetd version x.y.z?  does this license require me
to keep printing the version number?  Are there any cases where the
version number could become part of an API and I'd be unable to be
compatible with some future version of xinetd because I cannot change
the version number?  Would this license get in the way if I wanted to
take parts of xinetd and use them in other projects?