Re: Non-DD's in debian-legal
On 6/12/06, Theodore Tso [EMAIL PROTECTED] wrote: The d-l list has a problem which is shared by many Debian mailing lists (including debian-vote and debian-devel, and I'm sure it's not limited to them) which is that far too many people subscribe to the last post wins school of debate. People don't listen, they just assert their point of view --- back and forth, back and forth. Foo! Bar! Foo! Bar! That's a real problem, unfortunately. A problem also exists where trivial issues sometimes get far more weight than significant issues. Where sharp lines are drawn, with definite factions evident, it's too often that core issues and real solutions are not a subject of discussion. We have something of a safety valve -- ultimately, each person responsible for actually doing something is the one who gets to decide what's really important. But other safety valves (such as good [non-hostile] senses of humor, and insight into other people's points of view) are also welcome. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 2/21/06, Margarita Manterola [EMAIL PROTECTED] wrote: On 2/20/06, Raul Miller [EMAIL PROTECTED] wrote: As a specific counter example, consider http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which is a project porting a windows driver to linux. This port appears to be possible because the windows driver was made available under a free license. With this particular driver, I think you are making a mistake. rt2x00 is available as an independent driver (i.e. without ndiswrapper). What is my mistake? It looks to me as if the sequence of events was: 1 open source windows driver available (can be used with ndiswrapper) 2 someone ports windows driver to linux 3 linux driver available These events are sequential, and event 3 does not erase event 1. As can be read in the project's history [1], the open-source project started because Ralink decided to release the Linux drivers under a free license. There's no mention on the page of a Windows driver. So the mention is not on that particular page, and is on a different page. Why is this a problem? Note: I'm not saying there is no problem. But if we're going to change our rules for acceptable in main from FOO is allowed in main if FOO is free and everything FOO requires for installation is free to FOO is allowed in main if the typical use of FOO can does not involve any non-free software then we have a much bigger issue than ndiswrapper. And if we're going to tackle this issue properly, we need to define the problems clearly before we can even begin to come up with a decent solution. For example, while we might want to define a six degrees of separation free debian subset, but before we could do that we'd need to have a good idea of what goes in that subset, how people that use it can be sure that that's what they're getting, what we're going to do about people who have come to rely on other software, etc. etc. -- Raul
Re: Bug#353277: ndiswrapper in main
On 2/20/06, Robert Millan [EMAIL PROTECTED] wrote: I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. This proposal is clear enough. My reasons are: - The sole purpose of these packages is allowing the use of non-free Windows drivers. - There are no free Windows drivers for this interface, except a port of a Linux driver to Windows (cipe), which is only used on native Windows platform (since it is pointless to emulate it from Linux, where the original cipe is already available). I'm not sure I agree with this. When I look at the list of drivers that ndiswrapper supports http://ndiswrapper.sourceforge.net/mediawiki/index.php/List I see several that seem to be open source. You've asserted that none of these drivers satisfy the DFSG, but I think we would need more than an assertion on this issue. As a specific counter example, consider http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which is a project porting a windows driver to linux. This port appears to be possible because the windows driver was made available under a free license. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/10/06, Anthony Towns aj@azure.humbug.org.au wrote: I didn't say anything about the ballot options being ignored -- I said the constitution doesn't say anything about ignoring foundation documents -- ie the social contract or the DFSG. We're actually doing that right now in a sense, by continuing to leave bugs like #199810 unfixed. So stick it in non-free for unstable, until the issue gets resolved. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/11/06, Glenn Maynard [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 03:21:57PM +1300, Nick Phillips wrote: The vote is not a means of rescinding the DFSG or SC, nor even of contradicting them. It is the *only* means we have of determining whether something is in compliance with them. If a majority say that that is the case, then for our purposes, it is so. This is silly. It seems like the constitution effectively says if the resolution passes it required a simple majority; if it failed, it needed 3:1. The only silliness is the verb tenses. Once some concept passes supermajority it doesn't need to pass again, because it has already passed. The real problem here is that the option in question uses poor grammar. For that reason alone, I think this option would be bad for the project. It's already spawning arguments because people think they agree with the option, but it's not clear what agreement with the option means. Fortunately, or unfortunately, our resolution mechanism for this kind of problem involves voting. Personally: I am reasonably confident that most of the developers will vote against something like this: where the grammar of the proposal is so poor that it spawns grammar based arguments about what it would mean if it were accepted -- before it's even voted on. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/10/06, Anthony Towns aj@azure.humbug.org.au wrote: Personally, I'd rather the secretarial role be as automatic as possible, even to the point where votes would be run without any human intervention. I've thought about that before, but I don't have the inclination to write any code for it. I don't know what this means. In general, humans are capable of understanding what is meant by a ballot option, while machines are not. I don't think incomprehensible ballot options are very useful, and we're already pushing that envelope. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Feb 09, 2006 at 05:18:18PM -0500, Raul Miller wrote: On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: As it happens, it says nothing about implicit changes to foundation documents, or even about having to act in accord with them. Section 4.1.5.3 seems to say something about this issue. It doesn't use the exact words you've used, but the meaning of the words it does use seems more than adequate. It says how the documents can be superceded or withdrawn; it doesn't say anything about ignoring them outright, or changing the way they're interpreted. That's a strawman argument. The ballot options are not being ignored. Manoj is not leaving them off the ballot. The 3:1 supermajority issue is only relevant for options which are not being ignored. And Manoj is not changing the option. The option in question is making a statement about the DFSG. It says GNU Free Documentation License protects the freedom, it is compatible with Debian Free Software Guidelines. But until the option has been accepted as a successful GR, the proposal is not something we as a project have agreed to. If it passes, then it will be true that this issue isn't a 3:1 supermajority issue, but if it does not pass then this will not be true. If it was true for us, without us having to vote on it, the this wouldn't be an issue I think it's a mistake for Manoj to have taken on that role in this case, but it's his choice. And that seems to be the right choice. I certainly would not want the secretary acting as if controversial proposals were a true of the project goals before they had been voted on. As far as the outcome's concerned, though, I don't think it matters either way -- I think Anton's amendment has received more than enough discussion that it ought to be voted above Further Discussion, and I think it's far better for us to decide what we want to do based on what we want and what we think, rather than attacking each other. I agree that voting on this issue is the best way to resolve it, and that attacking each other is not a good way of resolving anything. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: To impose the 3:1 requirement requires, beforehand, a judgment concerning the DFSG. Since no one has found a Secretarial basis for that power, it follows that to arbitrarily impose 3:1 supermajorities (when doing so on the basis of a personal interpretation of the DFSG) is not proper. That the 3:1 bit is mentioned in the constitution is quite irrelevant. All debian developers are required to understand and apply the DFSG -- the DFSG is critical to Debian. You don't need special powers to understand and apply the DFSG. Package maintainers are supposed to make judgements about the DFSG in the context of their packages. The same goes for the Secretary in the context of preparing the ballot. You can't argue that since the constitution doesn't explicitly forbid the Secretary to take it upon him/herself to interpret the DFSG for everyone else, that therefore he/she must do so, in order to discharge the constitutional duty of placing 3:1 supermajorities on amendments, etc. That's backwards. Essentially you'd be asserting that any delegate has _any power_ he or she deems necessary to fulfill his or her view of their own constitutional duties, unless explicitly forbidden, item by item, by the constitution. That's not my argument. And, likewise, you can't argue that the secretary must treat an option as accepted when preparing the ballot. Treating controversial general resolution proposals as if they'd already won the vote before the vote begins would be the very abuse of power you're alluding to. Because that's the only way I can see for getting from the constitution mentions that some votes should require 3:1 supermajorities to therefore the Secretary must be the constitutionally ordained arbiter of DFSG correctness for all votes. And this despite other constitutional verbiage that suggests that developers have that power. Huh. The Secretary is a developer. Indeed, section 4.1 states that the developers, by way of GRs or elections, have the power to issue, supersede and withdraw nontechnical policy documents and statements. These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. They may also include position statements about issues of the day. The GFDL sounds like an issue of the day to me. Sure, and the constitution goes on and lists the procedure the developers follow when doing these things. And we're following those procedures. So where's the problem? The problem is that in the course of this procedure, the Secretary overstepped his authority, as I've explained above. You may not agree with that view, but I don't see why you should be so confused about my complaint. I've yet to see any description of your complaint that doesn't require me to accept that Anton's proposal is universally accepted by the project. But if I accept that Anton's proposal is universally accepted by the project, then the barrier you're talking about does not exist. So I'm faced with a contradiction: how can the Secretary be mis-using his power if this mis-use of power can only be a mis-use if it is not a mis-use? -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Feb 08, 2006 at 08:58:39PM -0800, Thomas Bushnell BSG wrote: It's not about honor; it's about decision-making. When you raise the implication that your fellow developers can't be trusted, you make it about honour; when you think it's important to move a decision from one set of hands to another in order to ensure the right decision is made, that's a pretty direct implication that you don't trust the first group. Is this courtesy to be extended to the project secretary? If not, why not? If a majority sincerely believe that their proposal does not run afoul of the 3:1 requirement, does that mean that it therefore does not? If the secretary sincerely believes the proposal has a 3:1 requirement, does that mean it does? I think you're better off looking at the constitution, personally. This seems to be a moot distinction, given that the constitution says that the secretary is the judge in disputes about what the constitution means. (section 7.1.3) As it happens, it says nothing about implicit changes to foundation documents, or even about having to act in accord with them. Section 4.1.5.3 seems to say something about this issue. It doesn't use the exact words you've used, but the meaning of the words it does use seems more than adequate. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/8/06, Nick Phillips [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 11:50:51AM -0500, Raul Miller wrote: If the GR is adopted by Debian, there is no significant difference between contradicts the foundation documents and modifies the foundation documents. First of all, you're assuming that it does contradict the foundation documents. It clearly asserts otherwise, and one might assume that developers voting for it would agree with that. If it won a majority, it would therefore seem to be the case that the majority of developers agreed with it. In which case those asserting that it needed supermajority wouldn't have a leg to stand on. So we'd be in a right mess. That would be a moot point, not a contradiction. Second, you're completely wrong. Of course there is a difference between modifying the foundation documents and appearing to contradict them. One modifies them and the other, well, doesn't. This can only be true where appearances are deceiving. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: Please cite the part of the constitution which grants the Secretary this extraordinary power. Despite what Raul Miller repeatedly asserts, a minor power to decide issues of constitutional interpretation in cases of deadlock DOES NOT mean that they have the power to interpret the DFSG, since the DFSG is not the constitution. Repeatedly asserts? I think, if you check my assertion, it included a direct reference to the text of the constitution that I was referring to. If you think I'm wrong, perhaps you could say specifically what it is about what I wrote which conflicts with that part of the constitution? Note also that the 3:1 supermajority requirement is not a part of the DFSG. So your explicit claim about DFSG interpretation being out of scope for the secretary doesn't seem to provide a basis for your implicit claim that the secretary does not have the right to impose the requirement on some of the options in this vote. Indeed, section 4.1 states that the developers, by way of GRs or elections, have the power to issue, supersede and withdraw nontechnical policy documents and statements. These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. They may also include position statements about issues of the day. The GFDL sounds like an issue of the day to me. Sure, and the constitution goes on and lists the procedure the developers follow when doing these things. And we're following those procedures. So where's the problem? -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: But why does the Secretary get to decide whether this barrier should be set or not? The constitution says: ... the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). I think that's pretty clear. Also, you might want to read the references it lists. I think it's pretty clear here that the Secretary is not exceeding his powers in any way, shape or form. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/8/06, Nick Phillips [EMAIL PROTECTED] wrote: The GR as amended might appear to contradict the Social Contract, or the DFSG, but it certainly *does not* modify them, and hence cannot be said to require a supermajority. This comment seems insincere. If the GR is adopted by Debian, there is no significant difference between contradicts the foundation documents and modifies the foundation documents. -- Raul
Re: Licenses for DebConf6
It seems to me that we have some responsibility for the licenses used on these presentations. It also seems to me that we should structure our approach to these licenses similarly to the way we approach other license issues. That is: we should encourage people to use a DFSG license, and we should label the presentations to let people know whether it's main/contrib or non-free. We don't have to exclude non-free presentations to encourage free software. However, unlike other conference holding bodies (such as the ACM), we aren't really in the business of collecting and selling copyrighted material. So rather than asking for a transfer of license to ourselves we should be asking for a DFSG copyright on the material. But SHOULD is not MUST any more than it is SHOULD NOT or MUST NOT. You build a community by encouraging participation, not by mandating it (nor by discouraging or forbidding it). This applies to our part in the free software community as much as it applies to anyone's part in any other community. -- Raul
Accepted silc-toolkit 0.9.12-4.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sat, 10 Sep 2005 13:04:57 -0400 Source: silc-toolkit Binary: libsilc-1.0-2-dev libsilc-1.0-2 Architecture: source i386 Version: 0.9.12-4.1 Distribution: unstable Urgency: low Maintainer: Tamas SZERB [EMAIL PROTECTED] Changed-By: Raul Miller [EMAIL PROTECTED] Description: libsilc-1.0-2 - SILC library (silc-toolkit) libsilc-1.0-2-dev - developer files for SILC library (silc-toolkit) Closes: 323035 Changes: silc-toolkit (0.9.12-4.1) unstable; urgency=low . * This is an NMU, I don't know why Tamas didn't want to fix this. rebuild control file whenever shared library's soname changes, to satisfy debian policy requirements for shared package names. (closes: 323035) See section 8.1 for more details. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html Though policy doesn't mention it, the point is to provide a migration path when for other packages when changes to the lib require changes to the soname. Files: 84e6301e2973221e6ea9aa699fa5cac0 899 devel optional silc-toolkit_0.9.12-4.1.dsc 45ead4de5a0e25ac94d3825010591e53 7655 devel optional silc-toolkit_0.9.12-4.1.diff.gz b919ed7afa50ad9710b87ba35666808b 130982 libdevel optional libsilc-1.0-2-dev_0.9.12-4.1_i386.deb d5496b56df182b9fe02041206b11da98 122536 libs optional libsilc-1.0-2_0.9.12-4.1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQEVAwUBQyncCvK/+Baey4gJAQEwMggAiJ8uMm1WkHAMC3+eMUbXHEi9oeK+o7vo TQ0xOV7BRhagX02KsxuvWklgIj1skLR031zzGXMYRL9eV3bZajnBAohlxdkCRBwc NLp5ls5OMUElglWQU0JsaoIEUemgDd5981sKPJ7K5fZ8OW7rxV6bFBFsJiG464rh 5eB/SnHID0P+f5m+sluhRGgLvtvw4M24GFhZO9cr5muw989teoZHlmdY0X5OA/Fu Sy/cDd6StBQI5+l6/5M5pm9ZIqT0OVjG4KL7y6tICxRbXqUv+TBKQ2x9rPpze3EG KNfNnL3MKNQUA6XcOLY4zHXWpKF5bCPtI9Y4s7HznoRVC9s98/fwlw== =6Nms -END PGP SIGNATURE- Accepted: libsilc-1.0-2-dev_0.9.12-4.1_i386.deb to pool/main/s/silc-toolkit/libsilc-1.0-2-dev_0.9.12-4.1_i386.deb libsilc-1.0-2_0.9.12-4.1_i386.deb to pool/main/s/silc-toolkit/libsilc-1.0-2_0.9.12-4.1_i386.deb silc-toolkit_0.9.12-4.1.diff.gz to pool/main/s/silc-toolkit/silc-toolkit_0.9.12-4.1.diff.gz silc-toolkit_0.9.12-4.1.dsc to pool/main/s/silc-toolkit/silc-toolkit_0.9.12-4.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
On 5/19/05, Michael K. Edwards [EMAIL PROTECTED] wrote: The GPL is anomalous in that the drafter has published a widely believed, but patently false, set of claims about its legal basis in the FSF FAQ. For the record, I disagree that this faq is patently false. It is, in places, a bit simplistic, but I wouldn't advise anyone delve into those fine points of law unless they've retained the services of a lawyer (at which point the FAQ is merely an interesting commentary -- it has less weight than professional advice). Furthermore, that FAQ is far and away better than anything you've proposed. -- Raul
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
For the record, I disagree that this faq is patently false. It is, in places, a bit simplistic, but I wouldn't advise anyone delve into those fine points of law unless they've retained the services of a lawyer (at which point the FAQ is merely an interesting commentary -- it has less weight than professional advice). On 5/19/05, Michael K. Edwards [EMAIL PROTECTED] wrote: The FAQ is not merely an interesting commentary -- it is the published stance of the FSF, to which its General Counsel refers all inquiries. And if you have retained counsel of your own, I'd let your lawyer deal with that. If you haven't, then my interesting commentary comment is irrelevant. Although I am not legally qualified to judge, I believe that he can have no reasonable basis under the law in his jurisdiction for many of the assertions that it contains, particularly the assertion that the GPL is a creature of copyright law and not an ordinary offer of contract. That may yet become a problem for him personally as well as for the FSF. I don't find in the GPL FAQ any assertion that the GPL is not to be considered an agreement under contract law. I can only guess that you're objecting to the implication that copyright law is somehow important to understanding the GPL. I'm stopping here because I'm assuming that the rest of what you wrote is somehow logically related to these assertions which do not appear in the FAQ. -- Raul
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
On 5/19/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Perhaps that is indeed what you would do. I don't consider lawyers to be the only persons capable of reading the law for themselves. They are the only ones authorized to offer certain forms of legal advice and legal representation, but that's a whole 'nother animal. In a sense, it's that ability to offer legal advice which I was talking about. In any event, I'd consider going to a lawyer as better than listening to someone else reading the law for themselves. Happily, the public record is not limited to websites under the FSF's control. Google Eben Moglen for the text of various interviews, and read his statements (especially paragraph 18) in http://www.gnu.org/press/mysql-affidavit.html -- or Google's cached copy, if that URL mysteriously stops working. Are you talking about point18? It's pretty clear that 18 refers to people who are not engaged in copying or distributing. There are no terms in the GPL which impose any contractual obligations in those cases. (Though it is the case that if someone is distributing a work illegally, that a person could receive work which supposedly has been released under the GPL but where parts of it aren't legal for further distribution.) I can only guess that you're objecting to the implication that copyright law is somehow important to understanding the GPL. Presumably this bit of grandstanding is meant for the benefit of any reader who doesn't know that you and I have been spamming debian-legal (and on and off debian-devel) with this debate for months, and hence you can guess a great deal more than that. Well... if I thought I understood what your points were, I'd probably be in better shape here. For the most parts, I'm hung up on what appear to me to be gross leaps of illogic, and I'm reduced to guessing about what your points are. I'm stopping here because I'm assuming that the rest of what you wrote is somehow logically related to these assertions which do not appear in the FAQ. Yeah, right. Like you haven't been arguing strenuously for months that the GPL is not an offer of contract. I am starting to question your sincerity again. I've been objecting to the nature of the generalizations you've been making. In other words, I see you asserting that things which are sometimes true must always be true. In the case of the contract issue -- I've been arguing that it's not always the case that the law will rely solely on contract law. I've not been arguing that contract law would never apply. In my opinion, an assertion that contract law would never apply would involve the same kind of over generalization as an assertion that contract law must always apply. I have been convinced, over the last week, that within the U.S., contract law will almost always apply. I think there is a basis even in U.S. law for other kinds of legal action, but I think that you're much more likely to find examples in international law than in U.S. law. -- Raul
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
On 5/18/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: That is completely not possible. Once you offer (and someone accepts) code under the terms of the GPL, they are for evermore entitled to use *that* code under the GPL. There are some exceptions to this. For example, if you're not the copyright holder, your offer doesn't count. Worse, in the U.S., copyright can be revoked after 35 years (with lots of legal fine print which makes this difficult to talk about simply). But none of that seems relevant here. (And none of it seems specific to the GPL -- I think this would be just as true for BSD.) Or, at least... the assertion by nullsoft that nullsoft wasn't authorized to release WASTE seems to raise the question of whether they're authorized to claim it wasn't released. [If they weren't authorized to release it, who would have been?] The only reason I can see for Debian to not want to package WASTE is that as a general rule we try to go along with the wishes of upstream developers. But, ultimately, that kind of issue is up to the package maintainer. -- Raul
Re: GPL and linking
On 5/11/05, Peter Samuelson [EMAIL PROTECTED] wrote: The GPL did not use the word equals. Neither that is to say nor namely are equal to equals. Are we to understand that your argument hinges on such fine semantic distinctions as claiming that that is to say does not connote equivalency? Have you nothing better with which to prop up your point of view? I'm disputing an argument which seems to require a number of such fine points. It is difficult for me to raise such disputes without mentioning the the points themselves. However, I can present my point of view without resorting to this argument: Let's say that we have a court case which involves some contested GPLed work. How should we proceed? First, let's consider a work which doesn't have any binaries. This would be no different from any other copyright case -- you have to show that the work in question is copyrighted under the GPL, and you'd have to show that the terms of the GPL are being violated. This should be relatively simple, and we can neglect sections 2 and 3 (which are clearly being complied with if the rest of the license is being followed). Now let's imagine that we've got a case which involves binaries. What do we have to do? First, we need exhibits: the sources, and the binaries. Out of consideration for the court, we want to pick examples which are as simple as possible while representing all of the important contested issues. So let's imagine we have Exhibit A (the sources) and Exhibit B (the binary). [We need to also show that this binary is representative of something which is being distributed, but that's not really different from what you have to do in other copyright cases, so I'll ignore that part.] Second, we need to show that Exhibit B is derived from Exhibit A. Again, we want to present this in a simple and easily understandable form, and we want to also present complete information. Once we've shown that B is derived from A, we can start examining the terms of the GPL to make sure that they are being followed. For example, let's say now that we're the defending party, and we want to show that the mere aggregation clause applies. To do this, we would show that the disputed work could be replaced by something trivial, and that having done so, the program is still the same program -- we might do this by showing that it still has the same behavior. Switching sides again, if someone asserted that the mere aggregation clause applied, and used program behavior to make that assertion, and I believed that mere aggregation did not apply, I would show how the program failed to operate in some independent context, with the disputed section removed. Is that clear enough? Now, back to the argument: an argument has been raised that the GPL is flawed because a work based on the Program defined in two parts, where the first part asserts that work based on the Program is a derivative work. The assertion has been made that the second part of that definition is meaningless. Let's assume that this assertion is true, that the second part of that definition is meaningless. Let's further assume that I can construct an example case where a work isn't covered by the GPL because the second part of that definition is meaningless. What would that mean? Since Section 0 says that the GPL grants you license to distribute this work, and since there's no part of the GPL that grants you license where Section 0 does not apply, in our hypothetical case we would have shown that the GPL does not grant you license to distribute this work. At this point, either: A) Copyright law doesn't apply, so it doesn't matter that you don't have license, or B) The GPL doesn't apply, so it doesn't matter that the GPL doesn't grant you license, of C) Distributing the work is prohibited by law. My argument is that if you reach C) by ignoring the second half of the definition of work based on the Program, that you're doing something wrong. Does that make sense? -- Raul
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: So I'm not going to say that your point of view isn't perfectly valid as your own point of view; but I don't have any reason to believe that it's a good predictor of how a court case involving the FSF suing FooSoft for linking against GNU readline would be argued. Of course, a court case does not have to be argued that way. However, I believe that a person who holds a GPL copyright who neglects these points in court is likely to lose. A judge can ignore issues which are not raised in court, and will focus on issues which are raised and contested in court. -- Raul
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/11/05, Raul Miller [EMAIL PROTECTED] wrote: Of course, a court case does not have to be argued that way. No, but if it's to have a prayer of winning, it has to be argued in terms of the law that is actually applicable, not as if the court were obliged to construe the GPL so that every word has meaning and then proceed directly to copyright law. The law as written says that you do not have permission to copy except as granted by a license. Thus the GPL's license grant is not only applicable, it's the issue which is most likely to be contested in such a case. A judge can ignore issues which are not raised in court, and will focus on issues which are raised and contested in court. A judge cannot ignore law which doesn't happen to be in one of the parties' briefs. In principle, at least, the parties will not be contesting the law. In principle, one party will be asserting that unlicensed copies are being distributed, and will be asking for monetary compensation for the resulting damages. The other party will be asserting that the copies were licensed (or, perhaps, simply settling out of court). Of course, I did gloss over a number of other issues which you would have to address in a real court case. For example, I didn't say anything about how to determine damages for the case -- for that you'd probably have to put a value on development time and show how the issue has cost you development time. -- Raul
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Fine. I have been goaded into rebutting this specimen. Most of this is focused on contract law issues. I've written a separate post suggesting the obvious alternative (Tort law) Since Section 0 says that the GPL grants you license to distribute this work, and since there's no part of the GPL that grants you license where Section 0 does not apply, in our hypothetical case we would have shown that the GPL does not grant you license to distribute this work. Wrongo. The GPL grants you license to copy, modify, and distribute A under the applicable terms. Whether by mere aggregation or by reductio ad absurdum, you may distribute some collections containing A; and there is no basis in the text of the GPL for enforcing on the licensee any division into some permitted collections and some forbidden collections. So B may be distributed so long as the applicable covenants of specific performance with respect to A are honored. I'm assuming that we're talking about a case involving binaries for the work A+B, which means we're talking about a case where either 1) The applicable terms are being followed, and B is available under GPL terms 1a) B is merely aggregated with A in the context of these binaries, or 2) The applicable terms are not being followed, and B is not available under GPL terms, and the work A+B is a significant work in the context of copyright law. At this point, either: A) Copyright law doesn't apply, so it doesn't matter that you don't have license, or B) The GPL doesn't apply, so it doesn't matter that the GPL doesn't grant you license, of C) Distributing the work is prohibited by law. My argument is that if you reach C) by ignoring the second half of the definition of work based on the Program, that you're doing something wrong. Does that make sense? No. Ok, I'm looking for how you think this doesn't make sense. Copyright law applies to the copying of A. True. And to the copying of B. And, to the copying of A+B. The distributor of B claims license under the GPL to copy A. This requires that B do so under certain terms, which is I think where our dispute lies, but continuing... The court construes the terms of that license, settles all other relevant questions of fact, and either decides that the plaintiff is entitled to some relief or that he is not. No disagreement here. It is then so ordered, and there's a path for appeals on points of law. Prohibited by law doesn't mean jack. It's true that the court can (and will) interpret the law. However, Prohibited by law does in fact have meaning. -- Raul
Re: GPL and linking
On 5/10/05, Humberto Massa [EMAIL PROTECTED] wrote: Raul Miller wrote: That's another re-statement of what a work based on the Program means. The GPL just equated the two, before the colon! It states, clearly, that the a work based on the program is a derivative work under copyright law, and then, using a colon and the introductory phrase that is to say, it states that a work based on the program is a work containing My point is that the second statement is not stating the same thing, so it can NOT be a re-statement. It must be something else. According to Wordnet, that is to say means namely. It had equated the two of them in the first part of the phrase. The GPL did not use the word equals. Neither that is to say nor namely are equal to equals. -- Raul
Re: pine license
On 5/10/05, Glenn Maynard [EMAIL PROTECTED] wrote: In the past, UW has (in my opinion) played deliberate word games to retroactively revoke the Freeness of a prior Pine license, and this license is clearly non-free *without* any such stretching or contriving. I don't think the issue at that time was that they revoked the prior license, but that we generally try and cooperate with the providers of software. If someone doesn't want us working with them, why should we? Also, if I recall correctly, there was a gnu project to write a pine replacement, but I don't know where that stands. Probably it's not complete because of a lack of development effort. -- Raul
Re: GPL and linking
On 5/9/05, Humberto Massa [EMAIL PROTECTED] wrote: You can't re-state something saying a different thing. GPL#0 says that a work based on the Program is a derivative work under copyright law, and then says that is to say, a work containing..., which is NOT a re-statement of a derivative work under copyright law. That's another re-statement of what a work based on the Program means. Yes and no. The GPL is the authoritative document on whatever it wants to define and whatever it CAN define (the GPL CANNOT define what is a derivative work under copyright law, for instance)... but IF AND ONLY IF it defines it without ambiguity. The GPL is not defining what a derivative work under copyright law means. It's defining what a work based on the Program means. What the GPL actually does is defining a cat this way: '' a cat is the animal on the page 3 of the Domestic Pets Handbook, that is to say, an animal with four legs and whiskers. ''. Does this defines all animals with four legs and whiskers as being cats? Not actually. Cats are outside the scope of copyright law. -- Raul
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/5/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Sorry to spam debian-devel -- and with a long message containing long paragraphs too, horrors! -- in replying to this. Who is sorry? How sorry? Let's assume, for the sake of argument, that this sorry-ness is not something that matters enough to you to avoid posting long and elliptical messages to debian-devel. On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: The GPL simply defers to copyright law to define derivative work. Actually, it tries to define work based on the Program in terms of derivative work under copyright law, and then incorrectly paraphrases that definition. It's probably worth noting that derivative work and work based on the Program are spelled differently. What's not clear, to me, is whether the word that refers to the d phrase or the w phrase. Careful study sheds no insight into this burning issue. [If I read the GPL, I can't find where it paraphrases the d phrase. On the other hand I can't figure out how someone could claim that the GPL incorrectly paraphrases the w phrase.] There has been so much silliness written about this topic ... Agreed. -- Raul
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/6/05, Raul Miller [EMAIL PROTECTED] wrote: On 5/5/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: The GPL simply defers to copyright law to define derivative work. Actually, it tries to define work based on the Program in terms of derivative work under copyright law, and then incorrectly paraphrases that definition. It's probably worth noting that derivative work and work based on the Program are spelled differently. What's not clear, to me, is whether the word that refers to the d phrase or the w phrase. Careful study sheds no insight into this burning issue. [If I read the GPL, I can't find where it paraphrases the d phrase. On the other hand I can't figure out how someone could claim that the GPL incorrectly paraphrases the w phrase.] Second sentence in Section 0: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. I believe you're objecting to the that is to say phrase, which restates what work based on the Program: means. As I read it, the phrase after the colon is a paraphrase of the ether/or clause it follows, i. e., an attempt to restate it in layman's terms. Yes. And that either/or clause says what work based on the Program means. And it's incorrect, as I explained, and for which I have previously given references to treaty, several countries' statutes, and lots of case law, in messages on -legal to which you responded (generally constructively and courteously, I might add). I disagree: work based on the Program is not the same thing as derivative work. The definition of work based on the Program uses the derivative work concept, but builds on that concept. I think claiming they're equivalent is silly. -- Raul
Re: GPL and linking
On 5/6/05, Humberto Massa [EMAIL PROTECTED] wrote: ??? Let's try again: '' The GPL tries to define work based on the Program in terms of derivative work under copyright law, and then, after this definition and a colon, it tries to explain what is a derivative work under copyright law, but gives a wrong explanation, which would remain wrong even if only USC 17 was considered as a global copyright law. '' See? The GPL says, in its section 0, caput, with [] braces mine: Except what you're calling a paraphrase of the derivative work concept is a restatement of the work based on the Program concept. Then again, other things you say, such as 'The GPL tries to define' shows that you're not really interested in talking about what the GPL is or what it's saying. The GPL does define work based on the Program. There is no element of try here. The GPL -- not your email -- is the authoritative document about what the GPL does and does not define. -- Raul
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/6/05, Raul Miller [EMAIL PROTECTED] wrote: On 5/6/05, Michael K. Edwards [EMAIL PROTECTED] wrote: [snip] Second sentence in Section 0: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. I believe you're objecting to the that is to say phrase, which restates what work based on the Program: means. Attempts to, anyway. I think this attempts to quip is meaningless. As I read it, the phrase after the colon is a paraphrase of the ether/or clause it follows, i. e., an attempt to restate it in layman's terms. Yes. And that either/or clause says what work based on the Program means. Yep. That phrase is, in its entirety: either the Program or any derivative work under copyright law. And that's the definition of work based on the Program for the duration of the GPL, as far as I'm concerned. To recap: W: work based on the program D: derivative work E: either/or phrase C: phrase after the colon. W means E C paraphrases E Thus, you have concluded, C attempts to paraphrase D Should we keep going back and forth on this, trying to show why you believe C attempts to paraphrase D? Also, either: (1) Your other paragraphs are logically based on this concept (C attempts to paraphrase D), and therefore are based on a false premise, or (2) Your other paragraphs are not related to this paragraph by theme or logic, and thus there's little point in continuing unless they contain some worthwhile independent theme (personally, I've not spotted one -- they just seem like a bunch of statements with little cohesive logic).] Or something else? I don't know why it's important that all this be sent to debian-devel. After this post, I'm probably going to delete debian-devel from my followups (and a great sigh of relief is heard throughout the land). -- Raul
Re: LCC and blobs
On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote: However, if somebody writes a graphviz-client which just pushes the dot file over the network to graphviz.example.com on some port and gets a postscript file back, it can go into main. No matter what software said server is running. Correct? In essence, yes. Do you have a problem netcat being in main? -- Raul
Re: LCC and blobs
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote: The social contract says ...but we will never make the system depend on an item of non-free software. not but we will never make the system depend on an item of non-free software /which we must distribute/. We don't make the hardware. -- Raul
Re: LCC and blobs
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote: Please suggest any case which you don't think this criteria adequately covers. The bios. Unless, we decide that the bios we put in non-free isn't the bios we need to boot the machine. -- Raul
Re: LCC and blobs
Raul Miller wrote: Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. The fact that we uploaded the firmware does not excuse the device from respecting its API. Personally, I've never found devices to be particularly apologetic under any circumstances. Nor is it our task to write the firmware, Debian is a distribution for general-purpose computers, if you want to have a distribution for firmware you are free to do so. Are you thinking that these firmware devices are not used in general purpose computers? If not, this seems about as relevant as the other stuff you've said (which is to say: not at all). Debian should consider hardware as things that you have to talk to with a certain protocol. This would make all software which uses a well defined interface into hardware It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The has to bit. -- Raul
Re: LCC and blobs
Raul Miller wrote: The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. On Fri, Dec 17, 2004 at 03:51:22PM +0100, Peter Van Eynde wrote: I don't understand you. Hmm... An API is not programmed. Programs are written against an API. The API represents the aspect of the computer which is being programmed when you write a program. Something can provide or support an API or use an API. Use an API can correspond to an API being programmed for the case that that the use of the API involves the creation of a program to do the using. In this case the firmware+hardware provides and API to the linux driver. Sure. But that's not the API I was talking about. I was talking about the API the firmware uses -- the one that the program contained in the API was designed to work with. It is known, we can support it. Which has nothing to do with the issue I was talking about, because you've got the wrong API. If the device has bugs in executing the API it makes no difference if there is a firmware or not to the driver, nor does it to our support because we don't provide the firmware, we only use it. EXACTLY! We don't provide the firmware. And the reason we don't provide the firmware is that we don't understand the issues well enough to do so. This rather concisely captures what the DFSG is about. The mere fact of uploading the firmware does not give us an obligation to support it. And, in fact, we shouldn't support it. If your printer misprints a page you don't expect debian to patch it do you? This is another good example. And, taking it a bit further, I think shipping a printer to me would be a waste of Debian resources. [That said, I don't have a printer.] It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The has to bit. If the has to is to do a specific task, eg connecting to a wifi network, then the has to is no different from grub loading the XP bootsector. We don't distribute the XP bootsector. In the other case the ipw2100 driver already loads and does some (very limited) work. The issue is completeness. A piece of software which has to have some non-free software to become functional is useless without that non-free software. -- Raul
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:33:41AM -0500, I clumsily wrote: I was talking about the API the firmware uses -- the one that the program contained in the API was designed to work with. That should have read: I was talking about the API the firmware uses -- the one that the program contained in the firmware was designed to work with. -- Raul
Re: LCC and blobs
[just some minor additions.] On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote: No, I argue that because you've pried chips off the board, the hardware is broken. On Thu, Dec 16, 2004 at 09:39:59PM -0500, Glenn Maynard wrote: Er, no. Flash can be overwritten with invalid data (eg. nulls or interrupting a flash process), rendering drivers that expect a working flash to not work. And some monitors can be driven in ways that cause them to burn out. In both cases, there's a change in the electrical characteristics of the device which renders it non-functional. It's not correct in the general case to say that no driver can drive that; some hardware can still be re-flashed to correct the data, so a driver that does have a (usually redundant) copy of the firmware and code to upload it can, in fact, drive the device. In principle (depending on the board design), the flash data can be pulled off the device. We don't have to distribute the data to allow users to reflash their devices. [And, in the general case, we probably shouldn't -- because we're not set up to track all the potential hardware changes, and we're not in a position to make sure we're providing the proper version of the data for the instance of hardware that the user has. Of course, we'd also get it right in a number of cases.] Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. However, unlike non-flash devices that need the firmware uploaded every time, the driver is still useful without it. Yes. Whether or not the misflashed hardware is a broken device analogy is bought, the fact remains that many copies of the hardware still do function, having working firmware. The existance of non-working hardware is irrelevant. Exactly. -- Raul
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: What I am concerned about is the following scenario: Mr. John Wontshare writes a streaming multicast client. To deal with packet loss, he uses my error-correcting library. Without my library, Mr. Wontshare's client can't work at all. Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. He then distributes his client along with my library to end-users. These users don't get Mr. Wontshare's code, even though he uses my library. Even worse, he refuses to port his client to MacOS X for business reasons. (intentionally giving an unfair competitive advantage to another platform) Given that Mr. Wontshare's client represents only a small investment of effort, refuses to port doesn't sound like much of a problem. Regardless of whether you make your code available under a simple API, there's other possibilities: Mr. Wontshare (or someone else) puts your library behind a simply api and then builds some application which uses that api, and yet refuses to release his code. Someone works with the ecc concepts behind your code and reimplements them in some proprietary code base. Unfortunately, ideas are hard to protect in the first place, and the laws aimed at protecting ideas were originally designed based on the assumption that not sharing ideas is protecting the ideas. -- Raul
Re: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))
On Thu, Dec 18, 2003 at 10:41:46AM +0100, Mathieu Roy wrote: You are currently saying that the GNU in GNU/Linux is justified by the glibc and not by any other GNU software, because these GNU software are common on other unixes. Maybe what he was saying, but that's obviously not the real issue. recapThe original reason for the change from Linux to GNU/Linux was that: the kernel was developed and built with gcc AND libc was gnu AND most of the system tools in userland were gnu AND the developers involved were not rabidly anti-gnu (though the switch did flush a bit of rabid anti-gnu sentiment out of the community)./recap The bsd port is still mostly vapor, so it's kinda hard to figure out how much of the above is relevant. Thus, knowing whether GNU is appropriate (or whether a de-emphasized lower case gnu is appropriate) is more a matter of speculation than a matter of hard fact. Moreover, this speculation touches on a lot of issues (aesthetics, us vs. them group dynamics, incompatibilities, bugs, and the hard technical work of a very few) which mean we'll probably be seeing echos of this supposed trademark discussion for years. I've even contributed to it a bit myself -- it's an easy discussion to jump into, even though it's not really a well defined problem. If we follow your theory, it means that if someday another system use the glibc, we should remove the GNU from the GNU/Linux name. We don't, as a general rule, follow theories very far. Theories are a good starting point, but they have to stand up to testing. That said, I could wish for the gnu glibc crew to have a more up-to-date website [forinstance]. -- Raul
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Tue, May 20, 2003 at 04:57:18PM -0400, Raul Miller wrote: Hard to understand? We'd require a certain level of voter approval before we'll consider an option -- options which don't achieve that can't win. How is this hard to understand? On Fri, May 23, 2003 at 12:50:02AM +0200, Jochen Voss wrote: The thing which is hard to understand, is the following. Dropping the option which nobody likes can change the winner among the interesting options. This is explained in detail at http://www.mathematik.uni-kl.de/~wwwstoch/voss/comp/quorum.html There you will find an example, where voting in favor of an option B will make this option loose, because of the quorum interferes. I'm going to focus only on your claim that this page shows an example of the violation of monotonicity by Manoj's proposal. Monotonicity (http://electionmethods.org/evaluation.html#MC) requires With the relative order or rating of the other candidates unchanged, voting a candidate higher should never cause the candidate to lose, nor should voting a candidate lower ever cause the candidate to win. But, on your page, I don't see any examples of voting a candidate higher with the relative order or rating of other candidates unchanged. Instead, I see one example of an introduced vote where B, C and A are all changed with respect to the default option. -- Raul
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Tue, May 20, 2003 at 05:58:10PM -0500, Manoj Srivastava wrote: At this point; under my version; I can express my opinions with no fear of harming my candidate. Under your amendment; if I do not vote; the vote is nullified. However, if I vote against the option -- the option shall win!! On Wed, May 21, 2003 at 10:12:52AM +0200, Sven Luther wrote: But you cannot know what the situation is, unless you have insider knowledge, the votes are secrets, and the results published only after the election is closed. The significance of Manoj's example is not you knowing what the situation is until after the vote. Until then, it's things like what the voter believes about the situation. (Why don't Anthony's quibbles get this much attention?) -- Raul
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Wed, May 21, 2003 at 09:57:13PM +1200, Nick Phillips wrote: I don't believe that it's acceptable for an otherwise beaten option to win due the the otherwise winning option being discarded due to a quorum requirement, as John suggests might happen. Under the proposed system, we would do exactly the same thing for otherise winning options being discarded due to a supermajority requirement. What makes this behavior acceptable for supermajority requirements and unacceptable for quorum requirements? To my knowledge, the only issue here is that other voting systems [for example, those indicated by Roget's Rules of Order] have defined quorum in terms of number of voters present and do not collect votes if quorum is not met. -- Raul
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Tue, May 20, 2003 at 12:19:33PM -0700, John H. Robinson, IV wrote: The amendment uses the concept of a Quorum requirement to inhibit stealth decisions by only a handful of developers. While this is a good thing, the per-option quorum from the amendment has a tendency to further influence the outcome of the vote in a hard-to-understand way. This modification corrects this deficiency. Hard to understand? We'd require a certain level of voter approval before we'll consider an option -- options which don't achieve that can't win. How is this hard to understand? Note also that your amendment would create situations in which a developer voting against an option might cause that option to win*. How is this easier to understand? * For example: quorum: 20 developer has reason to believe that not many votes will be cast. developer has reason to believe that the few votes which will be cast will be in favor of an option which developer is opposed to. Casting ballot against that option might cause ballot to achieve quorum. [Yes, this circumstance is unlikely -- that's because not meeting quorum is itself unlikely. If not meeting quorum becomes likely then this example also becomes likely.] To make your proposal work right, we'd need a separate quorum determination phase which is independent of the voting phase. Thanks, -- Raul
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Tue, May 20, 2003 at 02:39:08PM -0700, John H. Robinson, IV wrote: example: quorum of 20, two ballots on the measure, plus the default option. two major schools of thought: those that support option A, and those that support option B. If the quorum of 20 is significant, neither school of thought is major. Perhaps detectable would be a better adjective. * For example: quorum: 20 developer has reason to believe that not many votes will be cast. developer has reason to believe that the few votes which will be cast will be in favor of an option which developer is opposed to. Casting ballot against that option might cause ballot to achieve quorum. this is a strawman, because if R people vote, then no option will achieve the R+1default per-item quota. Expressed in terms of scenario: A vs B, quorum 20 Case 1: 15 ABD D wins Case 2: 15 ABD 8 BDA A wins Here, the vote(s) for B caused A to win. Other examples are possible (for example: 19 ABD, 1 BDA). To make your proposal work right, we'd need a separate quorum determination phase which is independent of the voting phase. i fail to see that argument. See above. -- Raul
End of leader vote
Today is the last day of our vote for our new leader. Because we've had a variety of problems, and for reasons documented in the Robert Grudin quote, under Date Input Format in the info docs on the date command, I'm declaring that the vote is over at midnight, as measured at the international date line. To find out when this is, issue the following command on your system: date --date='2001-03-28 23:59:59 -1200' If you've had problems submitting your vote (especially, if you submitted your vote when the LDAP server was down), please resubmit as soon as possible. Please have your votes in well before the cutoff time, so we don't have to about ambiguities such as local clock drift and communication delays. Please don't vote after the voting period is over. [If such ambiguities do arise, I'll make an arbitrary choice.] Thanks, -- Raul
Leader vote coming up soon
-BEGIN PGP SIGNED MESSAGE- As has previously been announced (http://lists.debian.org/debian-vote-0102/msg4.html), polls for the debian leader election will open March 7. The nominees should currently be campaigning. We have nominations for: Branden Robinson Ben Collins Anand Kumria I'll be posting a ballot soon. Thanks, - -- Raul -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iQEVAwUBOpCYJvK/+Baey4gJAQFPLgf/a1WmRradkqJV5/W7v5TrONOD0d8FA//0 eRNCiV5ROpqLYDee9k6biI/wnfl3CJbwCq0ROWxf/gH1+IKUY/pXU9uMV/aBep09 w2DiJ65wFYGpTmbySjPaCIiHNGOVYUbNcLfIJBKDhLvEDJO/QXwpwXBhhRHcDb6g qHAJSSY8z1pQEhf5QHFi273H30nV94gkHfekQxxJ8l85q0KjHZcADA3/4zDL9jIs QARN7O0UL/vtgDdohuFDDAzfRTx2b/Z3D4bsIxSNbnuKYQ0zVoB9ibtpCWex+GcL G+xqlsLyXS07Uj+4jy9PvpCp1qYmY5V35Aq/pSC1VA+upqyF9bnndw== =VC2H -END PGP SIGNATURE-
Re: KDE2 - nice demolition job ...
On Mon, 11 Sep 2000, erik wrote: [lots of stuff deleted -- basically a bitch about new maintainer] On Wed, Sep 13, 2000 at 07:57:41AM -0400, Christopher C. Chimelis wrote: Good point :-) Not really: [1] This point (if it really erik's point -- hard to tell) is not well expressed by erik's subject line, and was not well expressed in any of erik's original posts. Even the current post is way to verbose to be worth quoting. [2] New Maintainer is a tough job, with a lot of work to be done (especially because we weren't processing applications at all, last year, because things had gotten so out of hand and the people dealing with it had gotten so stressed out). In spite of that, NM is processing people at a fairly decent rate (and most of the people who haven't been processed haven't had their identities confirmed, yet). Not to stir anything up, here, but, to the NM team, what exactly is the process for dealing with NM applications? Please read: http://nm.debian.org -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and KDE: Appology
[EMAIL PROTECTED] (Richard Stallman) writes: Meanwhile, you don't seem to be concerned about the mob of people who are attacking me. On Sat, Sep 09, 2000 at 06:06:53PM +0200, Paul Seelig wrote: I may now be even more concerned that you seem to consider the authors of free KDE software a mob. Or maybe you are simply confusing a mob with the KDE authors? Paul: what information do you have, which shows that this mob is really only the KDE authors? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote: I don't see us making this kind of check for code written in perl, or code wirtten in C, or any other language. Perl is available under two licenses: GPL + Artistic. Not much room for a reasonable person to introduce conflict there. C runtime support (libraries) is typically available under very reasonable terms, for example, the LGPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and KDE: Appology
On Thu, Sep 07, 2000 at 05:52:04PM -0500, Joseph Carter wrote: Fortunately, my part of it is done - KDE is being uploaded to Debian now to join Qt in main. Unfortunately, not by any action of KDE. Troll Tech made the decision. KDE and Debian both benefit. I can speak for a sizable portion of Debian when I say regardless of how the resolution came about, we're happy with it (and in fact, most of us are absolutely delighted that Qt is now available under the GPL, even if it means that KDE essentially did nothing to clean up their own mess..) While I agree with most of your points, I must point out that Troll fixing this is far the right solution than KDE changing their licensing. If you like, I can go into details, but I'd prefer to keep that to private email -- the details don't in any way enhance debian development. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: removal of libqt1g from woody
On Thu, Sep 07, 2000 at 07:35:44AM -0400, Brian Almeida wrote: 'explorer' also depends on it (using the old qt1g package name) Explorer also has nine bugs, some important, six over two years old. Note especially: #29053: package explorer depends on obsolete library libstdc++2.8 (1y, 308d) #53642: Bad dependency (254d) #16190: explorer: explorer segfaults (2y, 264d) #20560: explorer: Fails to run due to undefined symbol in shared library (2y, 161d) #20764: explorer: doesn't start (2y, 158d) The first two are important -- if they're not fixed, explorer isn't going to be released as a part of woody. I don't think explorer is sufficient justification to keep qt1 in woody. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with mail system? [Fwd: Returned mail: User unknown]
On Thu, Sep 07, 2000 at 06:09:31PM +1100, Craig Sanders wrote: nobody's telling anyone to get any particular ISP or that they have to pay for a premium quality service. True. it's simple - if you want a service that's worth having, you pay whatever it costs. if you don't want that, then pay for a cheap/crappy service and put up with it without whining. Eh? (that said, i don't believe that missing reverse DNS is a good reason for bouncing mail. a 450 try again later response is more appropriate, to cope with temporary dns outages. bouncing mail from nonexistant domains, however, is a different story - it's almost certainly spam and there's no point in accepting a message which doesn't have a valid reply address so just bounce it) Ouch. I think debian developers should have a better understanding of DNS. [1] A mail domain does not have to have a valid IP address. As a default, if you use a mail domain for which there's no mail exchange, the default is to look for a host address with that name. But that's just the default. [2] A PTR record does not have to contain *any* information whatsoever. Imagine the mail client at 1.2.3.4 initiates an smtp session with your system. Your mail server performs a PTR lookup and gets back 4.3.2.1.in-addr.arpa. It then performs an A lookup and finds that 4.3.2.1.in-addr.arpa has the address 1.2.3.4. What have you learned? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with mail system? [Fwd: Returned mail: User unknown]
On Thu, Sep 07, 2000 at 09:06:55PM +1100, Craig Sanders wrote: i think you misread what i said. i said that missing or incorrect reverse DNS is *NOT* a good reason for bouncing mail. I guess I did. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine?
There's no legal difference between Debian and people who recieve it from us. [Legally, there's no such entity as Debian.] Nor is there a difference from the viewpoint of our social contract. On Tue, Sep 05, 2000 at 10:35:49AM -0400, Peter S Galbraith wrote: Then why do we have DSFG #8 `License Must Not Be Specific to Debian' if there is no Debian? [1] I did not say that there's no Debian -- I said that there's no such legal entity. [2] There is a Debian, but (at least conceptually) it can include everybody. In other words, DFSG #8 is exactly what I'm talking about. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine?
Their position was that the words permission to copy, distribute and modify do not grant permission to distribute a modified version. In other words, they say you can distribute the software, and you can modify the software, but you can't modify it and then distribute the result. I don't see anything in that language which indicates that special permission is required to modify and distribute the software. On Sat, Sep 02, 2000 at 10:55:26PM -0600, Richard Stallman wrote: I don't either--but that is not the point. The point is that the U of W has actually threatened to sue the FSF for distributing a modified version of a program that was released under the same words. Personally, I'm still in the process of confirming this. To treat a program released under those words by U of W as free software is being oblivious to the problem. Which would be bad. And, in the long run, we might adopt your solution. After all, it might be the best one. Then again, we might find a solution we feel is better. At the moment, at least, there doesn't seem to be any reason to panic. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine?
On Fri, Sep 01, 2000 at 01:26:53PM -0500, Steve Greenland wrote: That to me says Debian has permission to re-distribute our modified version, but that people who recieve it from us do not, unless they too ask permission (We do expect and appreciate...). Non-free. If she had written just We appreciate... I'd be comfortable putting it in free. There's no legal difference between Debian and people who recieve it from us. [Legally, there's no such entity as Debian.] Nor is there a difference from the viewpoint of our social contract. Trying to divide us up, by drawing a line where there isn't one, is very much against what we're about. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine?
I've an outstanding, unanswered question which I've sent to UW in a related context (IMAPD): what specific clause of the copyright is being violated, when modified versions are distributed. On Thu, Aug 31, 2000 at 02:46:40PM -0600, Richard Stallman wrote: Their position was that the words permission to copy, distribute and modify do not grant permission to distribute a modified version. In other words, they say you can distribute the software, and you can modify the software, but you can't modify it and then distribute the result. I don't see anything in that language which indicates that special permission is required to modify and distribute the software. Anyways, Lori said she's busy this week, but would try to have an answer for me next week. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine? Fsck Pine!
On Fri, Sep 01, 2000 at 03:39:05PM +0200, Sven Guckes wrote: I don't see why Debian (or GNU, or Linux) bothers with the IMAPD of UofW so much at all. Aren't there quite some replacements by now? [1] The copyright appears to meet our standards (DFSG). [2] The only alternative imap daemon doesn't support mail stored in mbox format. [Which makes a certain amount of sense, considering the reliability issues associated with mbox, but still...] We might indeed drop all UW software -- either because we decide that we want better relations with their developers (though that seems a bit self-contradictory), or because we decide it's too much of a headache. But that's a decision for the individual package maintainers. Also, note that I'm waiting for some clarification from UW on this copyright issue. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote: For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote: I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. While I agree with your thinking, I think you've left out a case: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] While I'm on this subject, I should mention: the man page for the netstat in netbase 3.18-1 claimed: netstat -ei will print a table or a single interface entry just like ifconfig does. This is true for the netstat in net-tools 1.57-1, but was blatantly false for the netstat that came with netbase. Strangely, the manpage in net-tools doesn't document this behavior (nor the netstat -er behavior). I wonder if this new lack of documentation should be considered a bug? -- Raul
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. This has nasty implications with the current implementation of dpkg, given that /sbin is currently a real directory on debian systems. -- Raul
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:40:42PM -0500, Branden Robinson wrote: In other words, I think the choice of directory should be controlled by factors intrinsic, not extrinsic, to the program in question. I think this is a reasonable viewpoint. -- Raul
Re: Free Documentation License
On Sat, Mar 11, 2000 at 08:30:08PM -0400, Nicolás Lichtmaier wrote: I think we have a problem here. The DFSG clearly does not apply to documentation, just like the GPL. As the FSF created a new license, we need to create guidelines to what we consider a free documentation, as in free speech.. =) I'd phrase that The DFSG does not clearly apply to documentation. The underlying issues behind the DFSG apply to documentation (we need to be able to legally distribute a coherent, easily administered operating system). But software is a loose term (mostly it's stuff that's not hardware). -- Raul
Re: cannot login in xdm anymore (upgrade potato - potato)
On Fri, Mar 10, 2000 at 09:03:25PM +0100, Richard P. Groenewegen wrote: [2] Logging in is still impossible: my password is accepted but apparently I cannot connect to the X-server (here is my .xsession-errors:) Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server xrdb: Can't open display ':0' Xlib: connection to :0.0 refused by server ... After less than a second, the login screen is there again. This is both a cry for help as a (not so precise) bug-report. I'm happy to give whatever information you might need about (configuration files on my) computer. Oddly enough, I got this too -- but only on my laptop (which is rarely connected to any networks). I tracked it down as far as noticing that the xdm auth file (some wierd name in /var/lib/xdm/authdir/) had keys for display ## (I think it was four fs, but I'm not sure). Then I decided that I didn't really need xdm on my laptop and I purged it (so I'm probably not going to be much help in isolating this problem). [I didn't file a bug report because I didn't know that this wasn't something I'd done to my configuration. That, and I was too impatient to try to figure out whether I'd read all the relevant documentation.] -- Raul
Re: Some developers still using slink?
On Tue, Oct 05, 1999 at 11:00:46AM +0100, Edward Betts wrote: So how many other developers are not using unstable? Raul Miller wrote: Perhaps this should be taken up on another list, if you expect input from more than a few people. On Tue, Oct 05, 1999 at 02:43:25PM -0700, Joey Hess wrote: A list other than debian-devel? A list with a charter of This is the main discussion list for development topics. All developers should be subscribed to this list.. His message was fine for this list, but when inviting a lot of followups of an information gathering sort, sometimes it might be better to redirect replies elsewhere. Then again, maybe that doesn't matter for this particular example. -- Raul
Re: perl dependancy problem
On Tue, Oct 05, 1999 at 10:27:00PM -0700, Joey Hess wrote:
What am I supposed to do? I could make debconf depend on perl-5.005, but it
really works with any version of perl 5. Also, if only perl-5.004-base,
perl-5.005, and perl-5.005-base were installed, and the alternatives pointed
/usr/bin/perl to perl 5.004, then it would still fail! I realize that would
require manual intervention to change the alternattives priorities, but it
still worries me.
If you want debconf to work before the perl packages get fixed you could
do something like (maybe use a different use statement):
#!/bin/sh
eval 'perl -e use POSIX 2/dev/null exec /usr/bin/perl -S $0 ${1+$@}'
if $running_under_binsh;
eval 'exec /usr/bin/perl5.004 -S $0 ${1+$@}'
if $running_under_binsh;
--
Raul
Re: dpkg -l format
On Tue, Oct 05, 1999 at 10:58:06AM +0300, Antti-Juhani Kaijanaho wrote:
Or simpler:
grep-status -P netscape | grep-dctrl -FStatus -sPackage -n \
'install ok installed' | xargs dpkg --purge
Or simpler, and closer to the original intent:
dpkg --get-selections | grep 'netscape' | xargs dpkg --purge
Or, if you don't want the noise associated with purging bogus packages
named install, deinstall ...:
dpkg --get-selections | awk '/netscape/{print $1}' | xargs dpkg --purge
Note that this last is equivalent to:
grep-status -P netscape | awk '/^Package: /{print $2}' | xargs dpkg
--purge
but it doesn't require any non-standard packages.
--
Raul
Re: Some developers still using slink?
On Tue, Oct 05, 1999 at 11:00:46AM +0100, Edward Betts wrote: So how many other developers are not using unstable? Perhaps this should be taken up on another list, if you expect input from more than a few people. For what it's worth, I'm using a slink system with potato in my apt/sources.list, and I've run apt-get install __ several hundred times. Sometimes this means that I stumble on old, fixed bugs (so I apt-get install any buggy package and try to repeat the bug before I even bother looking at BTS). Sometimes this means I stumble across bugs that no one has reported yet. Sometimes this means I stumble across fixed bugs in non-obvious packages. More generally, we're still supposed to be supporting slink users -- including slink users who only upgrade to a few packages from potato. -- Raul
Re: slink - potato
On Sun, Oct 03, 1999 at 09:57:12AM -0400, Raul Miller wrote: As far as I know, leaving inetd accepting connections would, worst case, fail -- which is no different from having the service disabled. In other words, I don't see that disabling the daemon solves anything useful. On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote: I think the worst case would be a telnetd linked with a broken shlib (or in the case of telnetd, perhaps a missing or broken /usr/lib/telnetd/login) that gives a security hole. If you wish to minimise downtime, the proper way to do it IMHO is to have certain packages flagged as daemons, and they should be upgraded (by whatever program that is in charge) one by one. Under what circumstances would this be in effect during an upgrade but not otherwise? -- Raul
Re: bash package removing /bin/sh on upgrade
On Mon, Oct 04, 1999 at 02:10:45AM +1000, Anthony Towns wrote: (What is the problem with --rename, btw? I'm curious, and dpkg-divert is horribly underdocumented) From dpkg-divert --help: --rename causes dpkg-divert to actually move the file aside (or back). There's no reason to remove the /bin/sh link. By default, dpkg-divert will divert the effect of future installs without touching the target file. -- Raul
Re: ITW/P: freecati
On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote: it may be an important tool, but that doesn't give you or anyone else the right to pester people in their own homes. it really does no good to apologise or even to promise not to call back - by that time, the damage has been done...the interruption/disturbance has been made, the invasion of peace, solitude and privacy has already been perpetrated. Huh? I'd rate such (genuine survey) phone calls as more pleasant to deal with than any of your recent emails. I've gotten phone calls from telemarketers, and I've gotten phone calls from survey folks. The survey folks are incomparably more polite. On the other hand, I've got a decent sized buffer (voice mail) on my phone and don't feel compelled to answer it if I'm in the middle of something else (which is most of the time). -- Raul
Re: slink - potato
On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote: I think the worst case would be a telnetd linked with a broken shlib (or in the case of telnetd, perhaps a missing or broken /usr/lib/telnetd/login) that gives a security hole. If you wish to minimise downtime, the proper way to do it IMHO is to have certain packages flagged as daemons, and they should be upgraded (by whatever program that is in charge) one by one. On Sun, Oct 03, 1999 at 07:06:10PM -0400, Raul Miller wrote: Under what circumstances would this be in effect during an upgrade but not otherwise? On Mon, Oct 04, 1999 at 09:57:35AM +1000, Herbert Xu wrote: The fact that dpkg does not deconfigure a package which depends on another deconfigured package is a bug in dpkg. This should not be used as an excuse to not deal with things correctly in maintainer scripts. Ok, if dpkg didn't have this bug, how would this bug be triggered? -- Raul
Re: bash package removing /bin/sh on upgrade
On Mon, Oct 04, 1999 at 01:58:07PM +1000, Anthony Towns wrote: One benefit always moving it has, is that it tests all code paths on upgrade (including the add a /bin/sh symlink) which makes it more likely to catch any bugs while we're still working on potato. I don't see how this makes --rename a `Very Bad Thing', though. I don't see that there's ever a need for /bin/sh to not exist. And, since we can't control the environment, I think it always should exist. -- Raul
Re: Debian membership (with a twist)
On Sun, Oct 03, 1999 at 09:31:42PM -0700, Yves Arrouye wrote: b) give the Project Leader the ability to stop stupid things like the /usr/doc - /usr/share/doc debate, and just pick an option. That's been the case at some point. Isn't it true anymore? The DPL has this ability. In this specific case, he delegated it to the technical committee. This forced the technical committee to get its act together (it took three weeks for the technical committee to come up with a decision, which is longer than it should have taken). Anyways, the decision has been settled for a month now, and the policy group still hasn't issued the relevant policy. I hope the DPL doesn't have to step in again on this. [I think the policy group is waiting on Manoj, and I think Manoj is on vacation or some such.] -- Raul
Re: BTS: How are the bug reports organized?
On Fri, Oct 01, 1999 at 07:36:28PM -0600, Jason Gunthorpe wrote:
Consider if we have bugs 0-199 and you take the first digit. You end up
with 10 bugs in each bucket except bucket '1' which has 110. Put that on a
broader scale and account for expired bugs and you see the trouble.
Why not base the BTS directory structure on the perl phrase:
(join /, map {() unless $_} split /(...)/})..html
?
Or, if you just want directory names:
join /, /(...)/g
Or maybe use (..) instead (since 200 directory entries allows for finer
grained cache management than 2000).
--
Raul
Re: bash package removing /bin/sh on upgrade
On Fri, Oct 01, 1999 at 08:36:01AM -0400, Ivan E. Moore II wrote: yea...I just did an update today and something decided to remove /bin/sh during the upgrade...and didn't put it back before it was needed... so if something hoses for you just recreate it by linking it to like bash... On Fri, Oct 01, 1999 at 03:00:51PM +0200, Torsten Landschoff wrote: If somebody could come up with a better method of handling this it would be most welcome. On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote: Just having /bin/sh included in the .deb is Good Enough -- diversions work as designed. Good Enough is not good enough (TM). There's a different preinst in one of the bug reports, ummm, #34717 I think, that does the diversion stuff itself, too. That uses --rename, which is A Very Bad Thing in this case. A wonderfuly horrible hack has occurred to me, by the way: A cron job which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh rebuild-bin-sh would take a configuration file in /etc to determine preference order for building the link (and fall back to some arbitrary order if all those fail), test each to find one that works then recreate the /bin/sh link. I'm tempted to say that rebuild-bin-sh should be statically linked (and use _exit() and not use anything related to printf()) to deal with cases where /bin/sh has died because of a library upgrade and there happens to be a suitable shell hanging around that uses a different library. [I'm willing to write such a thing if it seems like a good idea for longer than a few hours.] [Of course rebuild-bin-sh should be run manually after the config file is changed, for a smooth upgrade of the link. You don't really need the cron job -- it's a remedy for a situation that should never happen. and it's a remedy that may not have any use should that situation arise.] If such a thing is written, and deployed, it would be nice to integrate support for it into all posix shell. [Not for potato -- this is too critical of an app, in my opinion.] -- Raul
Re: slink - potato
On Sun, Oct 03, 1999 at 08:56:23AM +1000, Herbert Xu wrote: The idea is that when you upgrade the package like telnetd, there may be new shlib dependencies, etc. which means that you should stop spawning new daemons until it is configured. Of course, this may not happen for every release, but the prerm file comes from the old version, so it can't tell whether this is necessary, but it is the only one that knows exactly how to stop the daemon from spawning, so it just has to stop it every time. Note that there can be an extended period between unpack and configure. Especially if there's a package that needs a prompt answered that hits in this interval. [Imagine that you're running dpkg under screen and a network outage drops your connection.] As far as I know, leaving inetd accepting connections would, worst case, fail -- which is no different from having the service disabled. In other words, I don't see that disabling the daemon solves anything useful. [Aside: I never become root over a non-encrypted session, except in very unusual circumstances -- and even there I try to minimize the number unencrypted ip hops, but that's a different issue.] -- Raul
Re: daemon configuration
On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
I'm uncertain whether this is a good idea or not. I have helped many
people install redhat linux and, frankly, the daemon enable screen
confuses them. They don't know what all these things are or which ones
they may need. If this gets implemented at least have an obvious enable
default daemons button.
Agreed, this is a problem with Red Hat's implementation.
We should ask the user what kind of policy they want to have for network
services. We should inform them that there's a small risk that remote
users may compromise their machine if they enable network services,
but that in some situations the machine would be worthless without such
services. We should present a couple examples (http, remote login),
present the basic options (no network services on by default, most
network services on by default, choose on a service by service basis),
and we should give them a command to use after the install is complete
that lets them see what network services are in use and what package
is responsible for them, and a reference to how to find documentation
in the variety of formats a package could supply it in (man, info,
/usr/{,share}/doc, --help or -h, documentation embedded in configuration
files, or for the really desperate: documentation embedded in programs)
I'm not sure whether is such a reference about documentation.
I'm sure there's no such reference about associating packages with
network sockets. It would be possible to write such a thing, based on
lsof -F -i -n, but maybe it's better to teach everyone how to use lsof
(run lsof as root, teach about the +M option, egrep for '(UDP).*(LISTEN|\*)'),
use dpkg -S to find package associated with a program.
--
Raul
Re: bash package removing /bin/sh on upgrade
On Sun, Oct 03, 1999 at 10:07:03AM -0400, Daniel Burrows wrote: On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller was heard to say: A wonderfuly horrible hack has occurred to me, by the way: A cron job which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh Hmm. There's a bit of a problem here: aren't cronjobs executed with /bin/sh? :) Ok, so that part is completely bogus :) -- Raul
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Sat, Oct 02, 1999 at 08:06:10PM +1000, Craig Sanders wrote: i show no regard for those who demonstrate they are fools. i show contempt for those who demonstrate that they are annoying fools. guess which category you fall into. Ok, try this on for size: How many network services do you get if you are doing if you decide to install cfs? How many if you decide to install crossfire-sounds? [Aside: obviously there's a difference between not accepting a connection and accepting a connection then dropping it. Very occasionally this makes a difference from a security standpoint.] [Aside: I know that if you install packages one at a time, using apt, and if you read each package description, and sit back and read the package docs after installing it, that you'll not have any problems with unwanted network services cropping up. But: is this how you use debian?] -- Raul
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
On Sat, Oct 02, 1999 at 03:53:43PM +1000, Anthony Towns wrote: In any case, I fail to see how pressing `_' in dselect before any unnecessary daemons are installed could possibly be less secure than saying No, I don't want services activated by default and then installing them anyway. How long are you suggesting a person study their initial configuration in deselect before installing any packages? -- Raul
Re: bash package removing /bin/sh on upgrade
On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller wrote: On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote: Just having /bin/sh included in the .deb is Good Enough -- diversions work as designed. Good Enough is not good enough (TM). On Sun, Oct 03, 1999 at 11:55:54PM +1000, Anthony Towns wrote: *shrug* Name a case where it fails. You don't remember the problems when libreadline broke? Or, to address your implicit question rather than your explicit question: Bash is an order of magnitude more complex than what's needed for /bin/sh -- this results in efficiency problems and results in a number of potential reliability problems. -- Raul
Re: Suggestion: binfmt_misc handling
On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows wrote: [ as I understand it, a security 'breach' could only occur with this system if a user had execute permissions but *not* read permissions on a file that wasn't of a normal executable format; in other words: rwx--x--x /usr/bin/haha-you-cant-run-me.exe or if the user normally didn't have permissions to run the interpreter but had enough permissions to execute files of that type. Both of these seem to me to be unusual cases, but who knows? :) ] Or if the interpreter was setuid or setgid. -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Oct 01, 1999 at 10:53:44AM +1000, Craig Sanders wrote: i'm talking about the current practice of postinst scripts in various packages enabling the services that they provide (if any). i am not talking at all about which packages are base or required or extra or whatever - i'm talking specifically and ONLY about what the postinst scripts of packages do when they are installed. install a package which provides a daemon and it *should* be enabled in the postinst. if you don't want the service it provides then don't install the package. Of course this is completely unreasonable in many cases. And, of course, different package instances may or may not provide daemons and the decision at the package level may have been for a different instance. And, in general, there's more than one way to do it. All of which make this current discussion rather... odd. -- Raul
Re: Is XEmacs nonfree?
On Fri, Oct 01, 1999 at 05:01:05AM +0100, Chris Rutter wrote: Yes, probably; but no. RMS is referring to the fact that many authors of many pieces of xemacs haven't assigned copyright to the FSF, meaning that copyright remains with them, or possibly even their employer, depending on sticky employment contracts. Therefore, to be absolutely 100% anal about the `freeness' of the `GNU system', he is declaring that any code that hasn't been copyright-assigned to the FSF is not worthy of inclusion in the GNU system. You've got many correct facts there, but you're wrong. The issue isn't inclusion in the GNU system. The issue is inclusion in packages where FSF is the copyright holder. http://www.fsf.org/prep/standards_4.html#SEC4 or http://www.fsf.org/prep/maintain_3.html#SEC3 -- Raul
Re: Re^6: strange behavior of dh_dhelp
On Thu, Sep 30, 1999 at 07:31:00PM +0100, Marco Budde wrote: Ok, you#re right. But the classic http daemons (cern for example) used/use chroot() for security reasons. You#re right, the current apache package supports symlinks, but will all users use apache? Will all users use FollowSymLink (a dangerous feature?). Is a http daemon broken, because it doesn#t follow these symlinks? (1) If the daemon can serve /usr/anything when the docroot is /var/www chroot() is not happening. (2) Did you completely miss my post which pointed out that the server does not have to follow symlinks? You can construct the index page ahead of time. -- Raul
Re: bash package removing /bin/sh on upgrade
On Fri, Oct 01, 1999 at 03:00:51PM +0200, Torsten Landschoff wrote: If somebody could come up with a better method of handling this it would be most welcome. I'd suggest releasing a bash (which doesn't use #!/bin/sh scripts for install/remove) that, in postinst, divert's bash's /bin/sh. Leave the /bin/sh link alone, but create an extra link to occupy the position specified by the diversion. I've not tested this, but it seems like it should work. I'm not sure who should own the link in the long run. -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
On Wed, Sep 29, 1999 at 09:57:53PM +1000, Drake Diedrich wrote: One way to minimize the harm of unintentionally installed or misconfigured daemons would be to add a default ipchain/ipfwadm policy rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets except those from localhost. This approach (adding complexity to the active system) is a hack. There are situations where it's appropriate, but in most cases it's just one more thing to mess up, or one more thing where the user would have to wrestle with semi-automated configuration. The debconf solution is much better. -- Raul
Re: Re^2: strange behavior of dh_dhelp
On Tue, Sep 28, 1999 at 08:25:00PM +0100, Marco Budde wrote: ROTFL, why should I change dhelp to support a broken file format? ... dhelp supports all formats. ... These statements contradict each other. -- Raul
Re: mtools
On Wed, Sep 29, 1999 at 06:01:00PM +0200, Josip Rodin wrote: But who said mtools need to depend on floppyd package? $ dpkg -L mtools | grep floppyd /usr/bin/floppyd /usr/bin/floppyd_installtest /usr/share/man/man1/floppyd.1.gz -- Raul
Re: Can I have a package with no real name of upstream maintainer?
On Wed, Sep 29, 1999 at 10:08:39PM +0300, Antti-Juhani Kaijanaho wrote: Pseudonymes have been used throughout the history, so that's not a problem. For our protection, however, I'd recommend that you and tftp work out a agreement so that at least one Debian developer (you, for example) always knows who tftp is IRL, but he or she is forbidden to make this information public (or available to anyone else except when it is necessary to protect Debian from unfounded legal claims). PGP is legally classified in the same category as atomic weapons. [You know that the U.S. is in a state of emergency about this issue, and has been for a number of years, right?] -- Raul
Re: Can I have a package with no real name of upstream maintainer?
On Thu, Sep 30, 1999 at 08:46:38AM +0300, Antti-Juhani Kaijanaho wrote: On Wed, Sep 29, 1999 at 10:56:53PM -0400, Raul Miller wrote: PGP is legally classified in the same category as atomic weapons. No, it's not. Atomic weapons are controlled by international treaties, and AFAIK it would be a serious offence for me - or any other Finn - to have some in my possession [Scandinavia is a nuke-free zone, IIRC]. PGP is not regulated in Finland (except by ordinary copyright issues). Treaties are different from laws. But you're right, I should have ended that sentence with the clause in the U.S. -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
There is currently no default -- it varies on a per-package basis. On Thu, Sep 30, 1999 at 09:21:29AM -0400, Clint Adams wrote: I note that ### to run vtund as a server on port 5000, uncomment the following line: #--server-- 5000 isn't uncommented by default. Sure, but in the context of daemon processes that's not the one default: that's just one of many many. Are you saying you don't ever want any packages to change their default? [Sounds rather draconian to me.] Are you saying that there's some kind of debian default which you're trying to preserve? [If so, what is it? ... note that if this default is reasonable behavior then the definition of that default is almost always what we're discussing.] Or are you saying something else? -- Raul
Re: Can I have a package with no real name of upstream maintainer?
On Thu, Sep 30, 1999 at 07:23:53PM +0300, Antti-Juhani Kaijanaho wrote: On Thu, Sep 30, 1999 at 08:50:40AM -0400, Raul Miller wrote: Treaties are different from laws. On the contrary, ratified treaties are a binding part of the Finnish legislation, as if they were ordinary laws passed by the parliament. (IIRC) This may be different in the common law (sp?) system used in USA, though. IANAL, of course. Well, technically, there are no laws against encryption in the U.S.A. There are laws against exporting munitions. There's a regulation which classifies encryption as munitions (in the same category as atomic weapons). It's probably true that this executive decision doesn't have much bearing on treaty negotiations. Then again, treaty restrictions on the use of atomic weapons don't do anything to prevent the U.S. government from classifying encryption in the same fashion as atomic weaponry for the purposes what's legal to export from the U.S. The U.S.'s first ammendment does prohibit at least some of the current restrictions, but for the most part no one with enough authority to do much about this really cares. -- Raul
Re: ITR: intent to rename poc to objc
On Thu, Sep 30, 1999 at 09:05:43PM +0200, Marcel Harkema wrote: I am going to rename the poc (portable object compiler) package to objc if no-one objects. The upstream author requested this. Also, libgc4 (boehm gc) support is dropped. A new additional package will be introduced with libgc5 support. Does this mean that this compiler can deal with objective C? [Note: this isn't an objection, but if you do this and they're not the same thing you'll need to deal with the confusion somehow.] -- Raul
Re: mtools
On Tue, Sep 28, 1999 at 06:08:48PM +0200, Josip Rodin wrote: Correction: mtools in slink does *not* depend on anything but libc6, so there is still time to do it, cleanly. Maintainer, please do it. On Tue, Sep 28, 1999 at 12:28:08PM -0500, David Starner wrote: ... First, I believe this is against policy. Do not create two versions (one with X support and one without) of your package. I think the confusion is this: mtools 3.9.1-2 $ dpkg -L mtools | xargs ldd 2/dev/null| grep = | sort | uniq -c 24 /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) 24 libc.so.6 = /lib/libc.so.6 (0x4001a000) $ mtools 3.9.6-1 $ dpkg -L mtools | xargs ldd 2/dev/null| grep = | sort | uniq -c 27 /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) 1 libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x40024000) 1 libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x4001a000) 1 libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4003a000) 27 libc.so.6 = /lib/libc.so.6 (0x40031000) 27 libnsl.so.1 = /lib/libnsl.so.1 (0x4001a000) $ floppyd was recently added to mtools, and it's X-centric. I suspect xlib6g should be a recommendation rather than a dependency. -- Raul
Re: Re^2: strange behavior of dh_dhelp
On Tue, Sep 28, 1999 at 04:23:22PM -0400, Peter S Galbraith wrote: Then we'll have to agree where we register docs. I have the following directories on a fresh potato system (with few packages): /usr/share/doc/HTML/ /usr/doc/HTML/ And they are _not_ symlinks. They get created by different paths set in .menu files: ... Ugh. Oh well, the logical extrapolation of the symlink decision is that the contents of /usr/share/doc/HTML should be symlinked so that it's available in /usr/doc/HTML/. -- Raul
Re: pine in other distributions?
On Wed, Sep 29, 1999 at 01:18:43AM +0200, David Weinehall wrote: I suggest one of the guys on Debian-legal makes contact with UW and asks for their consent to distribute a Pine vx.yDebian binary. I do believe them to be pretty reasonable. Or you could. -- Raul P.S. you made this suggestion on debian-devel, not debian-legal.
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
[about a flat-file installation tool]. On Tue, Sep 28, 1999 at 07:58:02PM +0200, Remco Blaakmeer wrote: If you make such a tool and people start to use it on a large scale, you'd better be sure you get the package dependencies right. The context was data files which have no particular administrative requirements. Consider a tool which would install into a safe part of the namespace, and do something reasonable for a package-name [perhaps using some convention which is illegal for a debian package, to avoid any potential name conflicts.] There are complications -- for example, it's probably reasonable for a person to add documents to an existing collection (pseudo-package). It's also probably reasonable to define a mapping between some url and the local documents (allowing semi-automated or automated updating for frequently changing documents). [[I guess I'm currently describing something like a a cut down version of mirror, or maybe wget, with uninstall.]] But this idea probably needs to be fleshed out more (or shot full of holes) before it gets implemented. -- Raul
Re: Status of new packages in Incoming?
On Mon, Sep 27, 1999 at 11:22:32AM -0500, Steve Greenland wrote: I think the key difference is that if some one screws with the BTS or the Debian web site, it's not going to *me* any harm during the time it takes to discover and undo the damage. If someone installs a bad or malicious libc6 in the archive, a buncha people could get seriously screwed. Depending on mirror cycles and timing, I suspect it could take *days* to completely correct the damage in the archive and its mirrors, and who tells how long for the victims to correct their local situation. Which implies that we should validate packages against developer's key before install, and that we should have some kind of list indicating which developers are working on which package for which architecture which is maintained under tighter control than the mirrors. We probably don't want to forbid install if package is signed by the wrong key -- but we want to do everything we can to help the sysadmin examine the package under that circumstance. Also, we don't want to lock people in to just the Debian keyring. If they're getting packages from somewhere else they should be able to start trusting that source, if that's what they want. That, and people should be able to build up reputations. -- Raul
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, Sep 28, 1999 at 12:05:37AM -0400, Jaldhar H. Vyas wrote: Why even involve debhelper? At least in the case of the Project Gutenberg files some of which I have, they are just long ascii files so the rules file could just stick them into (for example) /usr/share/doc/etexts call doc-base and be done with it. AFAIK all the project Gutenberg files are public domain so one generic fill in the blanks copyright file would suffice. Voila you almost instantly have 2000 works containing more than a gig of text. I'd buy such a CD if it were offered. And I know plenty of people who would too. Works for me. Real question is: does anyone care enough to bother? Alternate question: why do we even have to package up flat text files? Why can't we just import them into debian in some regular manner? [I can see that naming convention is important, but are there any other issues beyond that? -- I mean, besides the issue of the current implementation of dpkg.] -- Raul
