Anthony Towns <aj@azure.humbug.org.au> writes: > I think it'd probably be reasonable to drop non-free at around week > 650 when we're only going to be affecting a handful of packages, or > possibly earlier, in the case, but the mere possibility of some > fluctuation isn't a problem even if we decided to only remove > non-free once we were confident there'd *never* be any useful > non-free software needing packaging.
So your position is that we should have non-free for as long as there is any doubt whatsoever if there will ever be a package to place in it? I mean, you talk at first in what I've quoted here as if there were some point at which we could remove it despite there being a handful of packages, but you seem to take that back and suggest that we really shouldn't remove it unless there are not only no packages in it, but we must also be confident there never will be again. And I don't know how we could ever have that confidence, unless the copyright laws get changed, because someone could always write something and make it non-free but distributable. Perhaps I've misunderstood. Is there some minimal number of packages such that if we have only that small number, we can disregard them and close down non-free, in your opinion? > That's the system we've already got -- people don't like maintaining > non-free software, so when there really is some free software that fills > the same niche, it gets dropped by the maintainer. If you'd like to do QA > work making sure that happens more promptly than it does atm, please do. In practice, this is not true. Often there is a different maintainer, who continues to maintain it because he likes it, completely independent of whether there is a free alternative. Netscape did not get dropped because free web browsers became available; it got dropped because there was an irredeemable security flaw. So what you describe is a nice theory, and maybe it would be satisfactory if it happened, but it does not seem to be a very common pattern. Thomas
