Bruce, I would have been much happier with phrasing such as "has not yet responded" rather than the much more pejorative "broke off communications"... Sigh. Whatever.
Brock, we actually had been having discussions on this topic, and were working on a reply to you. I apologize for the delay in responding. However, at this point, I'll simply add some comments to Bruce's message below... On Tue, 6 Apr 1999, Bruce Sass wrote: > There are three issues with pine > (in order of importance to Debian, imo): > > 1. Pine does not allow redistribution of modified binaries without > explicit permission to do so. There are three fixes: Pine provides > executables that do not require tweaking by Debian, then takes on the > job of a Debian maintainer; The possibility of UW releasing a version of Pine specifically for Debian Linux is not out of the question, 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. But as I've said before, we're open to trying to identify a minimum set of changes needed for Pine to run on Debian for possible incorporation in the Pine distribution. > Pine changes the license Don't hold your breath :) > (why are patches ok, but the executables generated from them not ok?); I'll try to explain. When the owner of any software chooses to make source code available, they have to make some decisions on change control. There is a spectrum of possibilities ranging from "nobody can do anything without explicit permission" to "anybody can do anything without asking". I understand the tradeoffs of various points on this spectrum and don't wish to get into a religious debate about so-called "free" software. Suffice it to say that, for the Pine project, UW chose a mid-point on the spectrum. We take a great deal of pride in Pine and it reflects directly on us, so we are very much interested in retaining change control; on the other hand, we wanted individuals and site administrators to be able to adapt Pine to their specific local environment without hassle. So the mid-point compromise is to say "feel free to make local mods, appropriately marked, but please don't redistribute modified binaries without asking." 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. 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. 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? I consider this to be a very important question. > 3. The technical considerations, which Pine is working on and will > result in making life a little easier for the Debian maintainer, but > which also have no bearing on Debian being able to redistribute Pine > executables. > > I contacted UW, then Debian, then tried to get the two communicating; > to the extent of offering possible solutions to the impasse. At the > point were UW should have responded (yea, nay, or how about this > solution instead), Terry broke off communication... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's certainly not my recollection, and certainly wasn't my intent. What I do recall is endless messages from various people asserting that UW should essentially surrender all rights to a product that we and we alone have spent enormous effort over many years building and refining. I admit to not having much patience with such whining. Still, except for Brock's efforts to facilitate discussion, which I was indeed tardy in responding to, I believed the ball was in other people's courts. But there's no future in debating the past... I hope the above comments help clarify UW's position. I reiterate our willingness to work with the Debian community toward a constructive solution. (But kvetching about the UW license terms isn't constructive.) -teg