Re: Discussion with Pine developers & Debian Issues
On Tue, 6 Apr 1999, Terry Gray wrote:
> The possibility of UW releasing a version of Pine specifically for Debian
> Linux is not out of the question,
I think a possible solution for this "problem" is that UW itself
distributes pine in .deb format.
Would you willing to do this?
> but it is also not entirely trivial
> since our folks don't completely agree with your folks on the best way to
> configure mail software.
Making a mail reader to be setgid-mail is part of the Debian policy,
which is available online:
http://www.debian.org/doc/debian-policy
Chapter 5.5, Mail transport agents.
BTW: I have yet to find the time to implement the maillock and mailunlock
functions properly.
> > Pine changes the license
>
> Don't hold your breath :)
>
> > (why are patches ok, but the executables generated from them not ok?);
>
> [...]
>
> One difference between sharing patch files vs. redistributing the
> resulting binaries is that the ultimate user or site administrator will
> tend to be more conscious of what is "standard Pine" vs. "modified Pine"
> if they go through the process of applying patches themselves.
I think something must be said here about the word "standard".
"Standard pine" looks for configuration files in /usr/lib.
This is non-standard in Linux (according to the Linux FSSTND standard, or
the most recent FHS standard).
So, paradoxically, installing the so-called "standard pine" in a Linux
system makes the system to be non-standard, since not every configuration
file is found in /etc.
Since a Debian user wants a version of pine which follows Linux
and Debian standards, a Debian pine user is not interested
at all in the "standard pine" the UW distributes.
The end result: A Debian pine user will compile pine from the patches
Debian distributes, regardless of it being also available in .deb
format or not.
I think this is a waste of time for everybody, and I still fail to
understand why sharing patches is allowed but redistributing the resulting
binaries is not.
> Perhaps
> the more fundamental point is that without the requirement to get
> permission before redistributing modified binaries, UW essentially gives
> up all claim of change control. I take your question to imply that our
> position would be more "consistent" if we required everyone under all
> circumstances to ask permission before they could modify Pine in any way,
> but that isn't where we wanted to be on the change control continuum.
But the end result is the same. If the source is available, people will
change it. Allowing patches but not allowing modified binaries is just
making life difficult to everybody.
> Again, we want to enable end-users and site administrators to make changes
> necessary for their environment without any hassle about permissions...
> while at the same time retaining some modicum of change control over Pine
> as it flows throughout cyberspace. (Some people consider this desire to
> be unreasonable; we do not.)
>
> > Debian gets a Pine maintainer that is willing to get explicit
> > permission everytime Pine is recompiled for Debian (Pine releases,
> > Debian releases, bug fixes, and security fixes).
>
> Not quite. No one ever said that explicit permission would be required
> "everytime Pine is recompiled...". For example, it is entirely reasonable
> and feasible to work out an agreement whereby an approved set of
> modifications can continue to be applied and redistributed against
> successive versions of Debian Linux without multiple approvals. No one
> has asked to do this so far, but I see no philosophical nor legal barrier
> (with the usual caveat that I'm not a lawyer, and proud of it :)
>
> > 2. The above requirement places Pine in non-free, rather than main,
> > which means Pine could not be put onto Debian CD's. The only fix for
> > this is a licensing change; for Pine to modify their license, or for
> > Debian to change the DFSG.
>
> I'm not clear on what the "above requirement" refers to. Does this mean,
> for example, that if UW provided a Debian-ready binary for redistribution,
> it would not be considered eligible for inclusion on Debian CDs?
Exactly. Whatever is included on Debian CDs have to be free by the Debian
definition of free (which is contained in the Debian Free Software
Guidelines).
To quote some points:
2. Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form.
3. Derived Works
The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified
form _only if the license allows the distribution of "patch files" with
the source code for the purpose of modifying the program at build time.
The license must explicitly permit distribution of software built from
modified source code. The license may require derived works to carry a
different name or version number from the original software. (This is a
compromise. The Debian group encourages all authors to not restrict any
files, source or binary, from being modified.)
BTW: The complete guidelines are available at:
http://www.debian.org/social_contract#guidelines
Packages which comply with the Debian Free Software Guidelines
are in the "main" section.
Packages which do not are in the non-free section.
Only packages in main are put in Debian CDs, and pine is far away
from being part of main.
> I consider this to be a very important question.
In fact, I'm glad that you asked, since it may help to clarify some
points. Does this answer your question?
Thanks.
--
"ba1f1029cda5b530cd63abe770989bcf" (a truly random sig)
Reply to: