Re: forwarded message from Jeff Licquia
Jeff Licquia <email@example.com> wrote:
> First of all, requiring a source file rename is, I think, obviously OK;
> renaming "foo.c" to "bar.c" doesn't really affect your rights, and is
> mostly an annoyance (tracking down Makefile references and so on).
Why is this obviously OK? DFSG #4 allows people to mandate the change
of the name of the work. Requiring name changes of files is too
granular. What if the license required you to change the names of the
functions inside the files (this would be analogous to changing the
API, just as the LPPL wants you to do). What if you had to change the
names of variables?
> Requiring a binary file rename is also OK; I think we might even do this
This is allowed by DFSG #4, because it is more or less explicitly listed.
> > The DFSG is a set of guidelines, not a legal document; it has room for
> > interpretation. Debian doesn't change the DFSG to indicate the details
> > of every debian-legal decision that required interpretation. Yes, this
> > means there's some ambiguity if all a person has for reference is the
> > DFSG text. (That's one reason these things are discussed publically.)
> Strictly speaking, not even debian-legal is "authoritative". A
> maintainer may do what (s)he wants with a package no matter what
> debian-legal says. However, it's likely that a maintainer who went
> against clear consensus on d-legal would find lots of people invoking
> the Technical Committee and/or filing General Resolutions to override
> them, so it generally doesn't happen.
I think that the only people who are really authoritative are the
ftp-admins. They generally defer to the consensus of debian-legal,
though. They might listen to a direct order from the technical
committee and/or a General Resolution.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com