Re: Request for GR: clarifying the license text licensing / freeness issue
Don Armstrong wrote: >I don't believe we need an amendment to the Social Contract to >specifically state this as the case, but a correctly worded one which >specifically amended the social contract and/or the DFSG appropriately >may be worth some thought. > >Unfortunatly, the currently proposed amendment does not >disambiguate between license texts in their capacity as a license under >which a work is distribute and random text which is labelled as a >license. Oops. My bad. It was definitely supposed to. The text was: "(There is a special exception for the license texts and similar legal documents associated with works in Debian;" I guess "associated with" is too vague. How about: "There is a special exception for the texts of the licenses under which works in Debian are distributed;" ? (Incidentally, given the number of important wordsmithing comments people have made, please nobody actually propose a GR until it's been through the peer-editing wringer.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
Ian Jackson wrote: >If this is forced to a GR we should have an option along these >lines: > > We note that many license texts are copyrighted works, licensed only > under meta-licenses which prohibit the creation of derivative > license texts. > > We do not consider this a problem. Although not my most-preferred solution, I would actually be very happy with something very close to this. Namely, something which specifies in addition: "We consider these to be free works for the purposes of the Social Contract. This GR will be linked prominently from the Social Contract's webpage." This would be clear, honest, and straightforward to Debian's users. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
MJ Ray wrote: >There may be a few licences that are buggy about this and to which we >want to grant a limited-time exception, but that is not unusual. Use >a GR for only that, not a permanent foundation document edit. >> Care to craft another solution? [...] >No, I've no interest You just did craft another solution. Thanks. Alternate suggested GR text: --- The Debian Project notes that many license texts are copyrighted works, licensed only under meta-licenses which prohibit the creation of derivative license texts. We consider this to be undesirable. License texts are functional works; reusing legal text from an earlier license makes a new license much easier to read and interpret, while brand new legal text is likely to have unexpected results. This is true even of preambles, which can have an effect on the interpretation of the license. We encourage all authors of license texts to allow the creation of derivative license texts. Currently several very important licenses for free software are licensed under such restrictive meta-licenses. These include the LaTeX Project Public License and the GNU GPL version 2. In addition, most license texts have no explicit meta-licenses, which makes their legal situation unclear; the worst case interpretation is that they have a restrictive meta-license. We have promised that Debian will remain 100% free. License texts which are under restrictive meta-licenses are not 100% free. While we could ship them alongside Debian rather than in Debian, we do in fact ship them in Debian as a matter of convenience. We wish to clearly inform our users of this temporary exception to the promise in our Social Contract. We will do our best to resolve this issue. Until this problem no longer applies to major licenses, license texts applying to works in Debian may be present in Debian even if they are not DFSG-free. We believe that this is the best choice to serve our users and the free software community. --- End alternate suggested GR Frankly I'd be happy with any honest solution. Currently the promise made in the Social Contract is very stark, very bold, and also untrue. The DFSG are very stark and bold about this as well. Lots of "must", "never" and "100%", which simply isn't what's going on. If the promise were, say, "Debian will remain 99 44/100% free", I wouldn't worry about this stuff! Here's a much more radical proposal, which I don't really support, but would still prefer over the present and ongoing situation. Radical proposed GR: Amend the Social Contract as follows: (1) Replace "Debian will remain 100% free" with "We will strive to make Debian 100% free" (2) Replace "We promise that the Debian system and all its components will be free according to these guidelines." with "We promise to do our best to make the Debian system and all its components free according to these guidelines, without crippling the system." (3) Replace "We will never make the system require the use of a non-free component." with "We will try to avoid making the system require the use of a non-free component, without crippling the system." (4) Replace 'We have created "contrib" and "non-free" areas in our archive for these works.', the following: "The most vital of these works are included in Debian, but we strive to replace all of them with free works. For the remaining works, we have created "contrib" and "non-free" areas in our archive.' -- -- Nathanael Nerode <[EMAIL PROTECTED]> "It's just a goddamned piece of paper." -- President Bush, referring to the US Constitution http://www.capitolhillblue.com/artman/publish/article_7779.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
>Nathanael Nerode <[EMAIL PROTECTED]> wrote: [...]
>> Without this exception, if the DFSG were followed literally, most
>> license texts could not be shipped in Debian and would have to be
>> shipped alongside Debian instead, which would be very annoying.
>
MJ Ray wrote:
>Most? I thought most licence texts were covered by themselves, being
>shipped as part of the software,
You're correct; although that is implicit permission, not explicit. I
was wrong; "most" is incorrect. That should be fixed. How about
"Several important license texts"?
> but we can't modify the ones shipped
>in debian because we need to accurately pass on the permissions given
>to users.
Right. I was very careful with my proposed text: the emphasis on
derivative works makes it clear that it's the ability to create new
license texts which is important here.
>AFAIK, the few which have different terms for modifying the licence
>rather than the rest of the software (such as the GPL) come with
>explicit permission to modify.
Here, you're *wrong*. The preamble to the GPL must be included with all
copies -- but the separate permission to modify does not extend to the
preamble. Likewise the LGPL. The Academic Free License does not have
permission to modify. The LaTeX Project Public License does not have
permission to modify.
>> Historically, this exception has been an unwritten assumption; [...]
>Has it? I've seen a few people write down this assumption, but I've
>usually disagreed with them.
There you go, Wouter. :-)
>We don't need this exception. It would allow another way for people
>to argue for including non-free software in debian ('but it's part of
>the licence'), just like some use the current non-free logo licences
>to argue for inclusion of their non-free logos.
We've already *got* non-free software in Debian, namely the license
texts above. In fact people are already arguing exactly what you said.
This would simply be more honest about it.
Care to craft another solution? I don't think we actually want to go to
the trouble of kicking those license texts out. (If however you'd like
to devise a technical scheme for detached licenses, living alongside
the .debs and .tar.gzs rather than in them, that would be great. It
would also require a change to policy, of course.)
I also think (from experience) that it's going to be a very long slog to
get the license text licenses changed (commentary on this is in the
GPLv3 comments system but being ignored), and that the opinion of Debian
that they should be changed, as expressed in the DFSG, would help with
that.
The current situation is dishonest (or, to be polite, "misleading") to
Debian's users, and it should be fixed. I have proposed a compromise
which I consider akin to the patch clause compromise.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing/freeness issue
I wrote: >> Historically, this exception has been an unwritten assumption; in most >> discussions, this exception has been agreed on by everyone involved. Wouter Verhelst wrote: >If that is the case, then why would it be necessary to write this down >in the DFSG? Personally, I don't think we need to go through all this Although most people agreed that there should be an exception, their mental ideas about the reason for the exception seem to have varied wildly. (For the extreme case, a lot of people honestly thought license texts were excepted because they were not executable binaries.) Only more recently has there been some sort of approximate-consensus rationale for it, which is the rationale I stated. >effort just so that nutcases can no longer use "But look, we do this >for license texts, too" as an argument. They're nutcases, anyway. I don't think they were all nutcases -- the difference between this exception and other proposed exceptions is not immediately obvious, though I think I explained it in the parent post. I think there's near-consensus on this -- but I also think it isn't so obvious that it can go without saying, and is so common that it cannot afford to be relegated to the DFSG FAQ. Your mileage may vary. Anyway, two other reasons were given in the parent post: (1) "However, unwritten exceptions are not really a good idea. It is more honest and straightforward to Debian's users to state the exception outright It is better to have all exceptions upfront, so that Debian's users know exactly what they are getting." Frankly I was surprised when I first noticed the "verbatim copying only" statements. I may be in a minority, but I don't think I'm unique. I think a "Social Contract" should be readable like a contract: well-written contracts don't have implied, unwritten exceptions to otherwise clear text. Again, your mileage may vary. (2) "However, Debian should encourage the licensing of license texts so that derivative license texts are allowed." Currently Debian takes no position on this. I think it should, much as it takes a position on patch clauses. A counterproposal might decide that Debian does *not* care about the licensing of license texts, period. Or might confirm that Debian takes no position on this (while still specifying that license texts have an exception). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request for GR: clarifying the license text licensing / freeness issue
This is a proposed text for a GR. I can't actually propose a GR (not a DD), so I request that someone else who cares propose it or a similar proposal. ---begin proposed GR--- Resolved: That the DFSG shall be amended, by inserting at the end of clause 3, in italics: (There is a special exception for the license texts and similar legal documents associated with works in Debian; modifications and derived works of these legal texts do not need to be allowed. This is a compromise: the Debian group encourages authors of legal texts to allow derived works.) Rationale: Debian is not in the business of shipping license texts; Debian does so only because this is necessary in order to ship other material. Many of these license texts do not have licenses allowing the creation of derivative license texts; the GPL is a prominent example. Without this exception, if the DFSG were followed literally, most license texts could not be shipped in Debian and would have to be shipped alongside Debian instead, which would be very annoying. Historically, this exception has been an unwritten assumption; in most discussions, this exception has been agreed on by everyone involved. However, unwritten exceptions are not really a good idea. It is more honest and straightforward to Debian's users to state the exception outright. Also, it prevents people from using this exception as an excuse to argue for other unwritten exceptions. It is better to have all exceptions upfront, so that Debian's users know exactly what they are getting. However, Debian should encourage the licensing of license texts so that derivative license texts are allowed. A license text which is a slight modification of an existing license text is substantially easier to analyse and deal with than a brand new license text. ---end proposed GR--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Anthony Towns wrote: > On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: >> The answer to the question in the subject is simple: NO. > > Thankyou for your opinion. I note you seemed to neglect to mention that > you're not a lawyer. Yes, I'm not a lawyer. Do not rely on anything I say as a legal opinion. Even if I *were* a lawyer, my postings here would not constitute legal advice. Please, I don't want to be sued for practicing law without a license! I'm just describing what little I've learned, which is far more than I should have to know under a sane copyright law system. :-/ Actually, you're the frickin' DPL. Go get a real legal opinion already. Call SPI's lawyer. I will be extremely surprised if he says "Yeah, sure, this stuff is totally legal to distribute", but who knows? > Cheers, > aj -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
The answer to the question in the subject is simple: NO. This is a matter of copyright law. If we do not have permission to distribute, it is illegal to distribute. GPL grants permission to distribute *only* if we distribute source. So, GPLed sourceless == NO PERMISSON. I will list the usual caveats so that nobody else brings them up. (1) Obviously if we have an alternate license (dual-licensing) which doesn't require source we can use that license. (2) If the material is so trivial it is uncopyrightable we can obviously distribute it. (The classic example is CRC tables, which contain no creative content beyond the CRC polynomial which is generally public domain.) Likewise if it was published prior to 1988 in the US without copyright notices, or is in the public domain for some other reason. (3) If the copyright holder for the firmware donated the firmware to Linux with the understanding that it would be redistributed by Debian and other distributors, this may constitute an implicit license to distribute. This would be a case of dual-licensing, but an unpleasant one because we'd be relying on an *implied* license. This requires tracing down the donation of the material to the Linux kernel and ascertaining the state of mind of the donor (perhaps by reading press releases). This clearly applies only to some of the firmware; other pieces have no such 'paper trail'. Also, this implicit license *does not* include a license to modify, because I've never seen any indication that any firmware donor intended that their firmware be modified. (4) If the hex lumps really are the preferred form for modification, then we have the source and this is not a case of 'sourceless firmware'. I have not yet seen a case where there is any evidence that this is true. It is, however, theoretically possible. If the firmware author came forward and said "Yes, that's the form in which we modify the firmware", this would be the case. Sven Luther wrote: > Hi debian-legal, ... > > It seems the firmware kernel issue has reached a deadpoint, as there is > some widely different interpretation of the meaning of the GPL over > sourceless code. > > For some background, the kernel/firmware wiki page includes both a > proposed GR, the draft position statement by the kernel team, as well as > an analysis of how we stand : > http://wiki.debian.org/KernelFirmwareLicensing. > > But this is beside the point. The real problem is that there are a certain > amount of firmware in the kernel, embedded in the drivers, which have no > license notice whatsoever, and as thus fall implicitly under the common > GPL license of the linux kernel. The audit from Larry lists some 40+ such > firmware blobs. Actually, I have to split this into two categories: * hex lumps explicitly licensed under the GPL by the copyright holder (e100 for instance) * hex lumps with no license notice - these may be implicitly under the common GPL license for the kernel - but they may also be present inappropriately, with stripped copyright notices and no license at all, if they were inserted into the kernel by someone other than the copyright holder. This has happened at least once already. > There is some claims that some of those blobs represent just register > dumps, but even then one could argue that the hex blobs doesn't in any way > represent the prefered form of modification, but rather some kind of > register name/number and value pair. (Well, perhaps the registers are numbered "0,1,2,3,4,5..." and the values are listed in that order) > So, the RMs are making claims that those sourceless GPLed drivers don't > cause any kind of distribution problem, This is a case of the RMs not thinking clearly, perhaps. > while i strongly believe that the > GPL clause saying that all the distribution rights under the GPL are lost > if you cannot abide by all points, including the requirement for sources. Yep. > Since i am seen as not trusthy to analyze such problems, i think to > deblock this situation, it would be best to have a statement from > debian-legal to back those claims (or to claim i am wrong in the above). > > Friendly, > > Sven Luther -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: > On Mon, Sep 18, 2006 at 10:09:14AM -0400, Nathanael Nerode wrote: >> I think you're wrong here, unless you're using an unusual definition >> of "distributable". The usual definition used by debian-legal is "We have >> explicit legal permission to distribute it." If you were right, we wouldn't >> have 46 undistributable files in Debian's Linux kernel packages today. >> >> Should Debian release with those files (again)? This is a very, very >> important question. Currently Debian is on track to release with 46 >> undistributable files. > > Indeed, but then, there are few issues to consider about this : Absolutely, these are things which should be considered. > - in some cases, like the acenic driver, the original copyright hholder as > well as the current copyright information is lost forever in some box > during one of the mergers. Likelihood of someone actually showing up and > saying this code belongs to them, and they can clarify the licencing, or > sue us, is very very small. Yep. This is frankly the situation with a lot of "abandonware". I'd love to distribute "Executive Suite", but who knows what happened to Grey Flannel Fun? Should Debian distribute abandonware? If so, which abandonware? Should the Linux kernel be held to laxer standards than everything else? > - in other cases, the original author is distibuting this sourceless > material themselves under the GPL, clearly a mistake or omission, which > they would be happy to fix, as the broadcom and qlogic case have shown. Yes. In this case, we have to actually track them down and fix it, which is incredibly tedious. But I agree that in this case we can usually assume that they *will* fix it. But how *long* do we give them to fix it before we conclude that we really haven't gotten it fixed and we should remove the software to be legally safe? A month? Five years? > Friendly, > > Sven Luther -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIcweRGZ0aC4lkIIRAserAKCODnIbWE50DDxoYbcVh+h1vIXkMQCfcfHk HRh6hp1QF19Yco7OqOoRhqY= =V4HJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Debian Project Secretaru wrote: > Hi, > > I have gone through the last couple of months of mail > archives, and came up with the current state of the proposals we have > before us. Thanks for going through this. I know you had to as secretary, but it must have sucked. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava wrote: > I don't care about just the proposers opinion, I want to > ensure that what the proposer is telling me is what the people and > the sponsors also agreed to. I suppose we could have a lengthy email > exchange, Oooh, "lengthy". Just email the damn sponsors and ask them to confirm the proposer's interpretation of the resolution text. > and assume that the sponsors are still paying attention to > every mail in the deluge that is -vote; or we can have an up front > process that does not depend on a culture of heroes for success. "Culture of people who are willing to send a few emails". Yes, indeed, we depend on that. Manoj, you're making mountains out of molehills. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Raul Miller wrote: > On 9/21/06, Nick Phillips <[EMAIL PROTECTED]> wrote: >> On which subject, does anyone else think that it would be useful to >> leave debian-vote for formal proposals/seconds (possibly moderated), and >> another list e.g. debian-vote-discuss (or even just -project) for the >> flame^Wdiscussions that follow? >> >> It would make it a lot easier to tell what was an actual proposal and >> what was not, what had been seconded and what had not (each proposal >> gets its own thread, to which the only responses are seconds). > > Except, that's solving the problem which did not occur. > > The question I see Manoj posing is not "was this message intended > to present a proposal, or not". > > The question I see Manoj posing is "which part of this proposal > message is the actual proposal". > > Personally, I'd say that if the situation is so ambiguous that it's not > clear whether what people are seconding is the same as what the > proposer has proposed that we are not dealing with a valid resolution. > > Consider a general case: Proposal message contains statements > A > B > C > D > E > > Some sequential fragment of this message is the proposal. That > means that the proposal might be A, AB, ABC, ABCD, ABCDE, > B, BC, BCD, BCDE, C, CD, CDE, D, DE, E. This might dilute > seconds by a factor as high as 15. > > In cases where the secretary feels the burden of interpretation is > too high, I think the secretary should ask that the proposal and > seconds be re-issued, with the ambiguities resolved. Totally reasonable. > In cases where the secretary's request is refused, I think the > secretary would be completely justified as treating each possible > resolution as a separate proposal. Though, to be fair, the > secretary might wish to present each plausibly seconded > possibility as having been seconded, even where this means > that a single "seconded" message seconds more than one > potential resolution. > > And if someone is tempted to claim "abuse of power" here, I think that > it's pretty obvious that the abuse would be on the part of those who > refuse to participate in resolving the ambiguities they themselves > presented. > -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava wrote: > Either it is preambulatory material, or it is part of the > resolution If it is preambulatory material, then it is part of the resolution. *There* lies the crux of the disagreement. (If it is not part of the resolution, it might be *supplementary* material, or *explanatory* material, or *reference* material, or *advocacy* material, or whatever.) > -- their lies the crux of the disagreement. I have no > objection to including the full text of a resolution. I am not going > to add other material not part of the resolution to the web page. > This is not subject to debate any more. (However, this might just be > a matter of semantics, lost now under accusations of gross and > egregious abuse of power). Yep, it's just semantics. You're using the wrong definition of preamble: a nonstandard one which nobody else uses. >> That is the state that <http://www.debian.org/vote/2006/vote_004> >> was in last time I looked at it; anything not preceded by a number >> had been elided, and each ballot option was prefaced by the >> prejudicial statement that "[t]he actual text of the resolution is >> as follows. Please note that this does not include preambles to the >> resolutions, [...]", implying that preambles are not part of the >> resolution and are not votable. > > I am going to reinstate that paragraph, for it is certainly > true. Actually, it's certainly false, as Branden Robinson has explained with Supreme Court citations. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Canonical list of proposal text
Manoj Srivastava wrote: > Could I ask the proposers to submit formated renditions of the > proposal for inclusion on the web page? Eeew, what abuse of > power. There is nothing in the constitution that allows the secretary > to impose such additional obstacles to getting a GR through. I think they'll all agree to do it voluntarily though. :-) So don't worry about whether it's an obstacle unless someone refuses. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Martin Schulze wrote: >> On Mon, 18 Sep 2006 18:46:50 -0700, Don Armstrong <[EMAIL PROTECTED]> said: >> > But just like the groundwork and foundation of a structure, the >> > non-actionable content of a resolutions can contain information on >> > how the actionable content is to be interpreted. As such, it is part >> > of the resolution, and needs to be included with the content made >> > available to voters. > > Umh, then I need to ask why the resolution is not clear enough > so that it does not need the preamble to know in which way the > author has intended its interpretation? Because it's often impossible to be as clear as you want to be, and you want to future-proof against your own mistakes? (That said, I think most of the preambles for the proposed GRs here make things *less* clear rather than more. The preamble to the GPL, on the other hand, is an excellent example of a legal preamble: by stating a clear intent, it means that if someone thinks they've found a convoluted "loophole" in the GPL text, they can probably be shot down.) > As Manoj pointed out > already, courts look at the resolution when *interpreting* it, > not at the preamble, so it seems pretty useles in that regard. Not really true, as noted: they look at the main text first, but if there's an ambiguity, they will look at the preamble. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava wrote: > On Mon, 18 Sep 2006 16:03:11 -0700, Steve Langasek <[EMAIL PROTECTED]> > said: > >> On Mon, Sep 18, 2006 at 05:32:10PM -0500, Manoj Srivastava wrote: >>> On Mon, 18 Sep 2006 12:36:17 -0700, Steve Langasek >>> <[EMAIL PROTECTED]> said: > >>> > For the record, this is not the full text of the votable >>> > resolution which I proposed; the preceding text was preambulatory >>> > text, not rationale, and was submitted as part of the resolution >>> > itself. > >>> Which is it, a preamble to the resolution, or the resolution >>> itself? > >> It is a preamble, and a preamble is a votable component of a >> resolution. > > Nope. The resolution is what ew resolve to do, and is the > only actionable part; the preamble is something that lays down the > groundwork, and is part of the support ensemble that lrsfd [rp[;r to > sgree to resolve to do whatever. > >> Or perhaps you think no one ever intended to ratify "We the people"? > > I can't help it if a bunch of dead white men got is all wrong > a couple of hundred years ago :) > > Look, I pledge allegiance to the flag and the constitution of > the US, not to the preamble and other related material to the > constitution of the US. The preamble is part of the Constitution. Maybe not one which gets used very often in court, but part of it. > The courts look at the GPL -- not the preamble to the > GPL. Incorrect. The preamble *may* have legal significance. It contains statements of intent which may color the reading of the rest of the GPL. If there is a clause with disputed interpretation, but one interpretation is compatible with the intent stated in the preamble and the other is contrary to it, a court would normally choose the compatible interpretation. Preamble-reading *does* happen in court, albeit rarely. Preambles are not mere surplusage. > When you derive a license from the GPL, you drop the preamble -- > and you modify and rename the rest to create your own license. > > Preambles are introductions to things and explanations of and > rationales for stuff. But they are not the stuff itself. They are normally part of the stuff. A preamble to a book is almost always part of the book. Preamble is almost a synonym for "introduction" or "foreword". -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava wrote: > On Tue, 19 Sep 2006 08:40:08 +0200, Sven Luther <[EMAIL PROTECTED]> > said: > >> On Mon, Sep 18, 2006 at 10:27:12PM -0500, Manoj Srivastava wrote: >>> Hi, >>> >>> Proponents of various various amendments to the GR should feel free >>> to send me a couple of paragraphs in HTML markup to >>> introduce/explain the resolutions they are proposing. Feel free to >>> include external links to more extensice body of supporting >>> material in the paragraphs you send me, but please keep theese >>> paragraphs short and to the point. >>> >>> I certainly don't want to include hundreds of lines of additional >>> material directly on the vote page. Please indicate if the content >>> is preambulatory or postambulatory. >>> >>> manoj > >> hi Manoj, ... > >> I wonder where Frederik's proposal fits in this ? > > Since it has been decreed that the secretary has no discretion > in putting up properly proposed and seconded text, this request is > now moot. > > We do have an issue now with people seconding extraneous text, > including signatures and extra material in the email; since if people > want a secretary with no powers to decide what is and is not > resolution text, People don't want that -- not in the case where anyone who can read could figure out what was resolution text and what wasn't, anyway. > then if person A seconds a proposal with > accompanying matter (someone just seconded Don Armstrongs proposal, > and did not elide the vote.d.o fragment); and person B carefully > edits and seconds a subset of the original email, then they are not > seconding the same sequence of bytes. > > Previously, I would have exercised judgement -- but I have > been informed a Debian delegate that that was gross and egregious > abuse of my power as a secretary. If the material seconded contains the statement "This is the text of the GR" or equivalent with a "boxed" piece of text, then the "second" should be considered a second of that boxed portion. There is nothing else rational to do. If any delegate objects to *that* , they're wrong and please call them out by name. On the other hand, if the material seconded does not contain 'boxed' text, the entire material seconded must be considered the seconded GR. So for Don Armstrong's proposal, the proposal with the intro material might well be considered different from seconding it without the intro material, and the secretary should conservatively accept only seconds of one of the two versions (Don's choice, obviously). But stupid differences which are very obviously not part of the GR, like the proposer's .signature, should not be considered significant. > At this point, I am unsure what to do --- technically, since > the proposals seconded are unlikely to be identical, byte for byte, If the above is done, only whitespace and decorative "cut here" material will differ. Resolutions are identical if they are identical word for word and punctuation for punctuation, not byte for byte. > unless people get less sloppy about the process, a secretary without > a brain can't count the seconds as belonging to the same proposal. How about a secretary with *half* a brain? :-) > manoj -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
Josselin Mouette wrote: > Le jeudi 21 septembre 2006 à 23:43 +0200, Loïc Minier a écrit : >> Obviously, some people jumped on the occasion because they dislike aj. > > There's some difference between "not liking aj" and "thinking aj is > hurting the project to the point he should be recalled". In fact, you can do the second without the first -- and you can do the first without the second. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: Preparing linux-2.6 2.6.18-1
Steve Langasek wrote: > If it is the consensus of the project that sourceless firmware doesn't > belong in main, this is a conscious regression in DFSG-compliance relative > to sarge. I don't think that's acceptable. We obviously do have the > means to remove this particular subset of non-free firmware from main > (technically imperfect though it may be), and of the firmware that was > removed for sarge the only one that was important enough to get me glared > at personally was qla2xxx -- so what are these other already-removed > firmwares that are so > important to have re-added now? (I did ask for a list, which no one has > provided yet; I can't find the pruning script in the kernel team's svn > repo, or I would look it up myself.) Here you go, Steve. drivers/media/video/dabfirmware.h drivers/net/acenic_firmware.h drivers/net/dgrs_firmware.c drivers/net/tokenring/smctr_firmware.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h The above are all undistributable: smctr_firmware.h under a use-only license, the others because they are "GPL" without source or have no license at all. drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa18x_fw.h drivers/usb/serial/keyspan_usa19_fw.h drivers/usb/serial/keyspan_usa19qi_fw.h drivers/usb/serial/keyspan_usa19qw_fw.h drivers/usb/serial/keyspan_usa19w_fw.h drivers/usb/serial/keyspan_usa28_fw.h drivers/usb/serial/keyspan_usa28xa_fw.h drivers/usb/serial/keyspan_usa28xb_fw.h drivers/usb/serial/keyspan_usa28x_fw.h drivers/usb/serial/keyspan_usa49w_fw.h drivers/usb/serial/keyspan_usa49wlc_fw.h These are all under a unique and annoying license: "redistributable as part of a Linux or other Open Source operating system kernel" Additional regressions relative to sarge: * tg3 was readded with the upstream firmware at some point after the release of sarge, despite the existing firmware loading patches, and is already in the 2.6.17 packages * The bnx2 driver was introduced upstream with sourceless, but distributable, firmware. * e100 and starfire acquired sourceless, undistributable firmware upstream between the sarge release and now (God only knows why) * New drivers were introduced upstream between the sarge release and now with the following sourceless, undistributable firmware: - drivers/net/cassini.h - drivers/scsi/ql1040_fw.h - drivers/usb/serial/ti_fw_3410.h - drivers/usb/serial/ti_fw_5052.h -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resolutions concerning dunc-tank
Loïc Minier wrote: > On Sat, Sep 23, 2006, Ian Jackson wrote: >> Third resolution `We do not want to state an opinion': >> -8<- >> 1. The Developers note the existence and activities >> of the dunc-tanc project. >> >> 2. We do not believe it appropriate for the Project as a whole to >> address dunc-tank in a General Resolution. >> ->8- > > So, if this resolution wins the vote, it will contradict itself since > we will have had a GR on Dunc yet we find it not appropriate to > have one? Technically it's not a contradiction: DDs can vote to behave inappropriately. :-) Still, it's poor wording. I suggest the following amendment to Ian: Replace clause 2 of third resolution with: 2. The Project as a whole chooses not to express any further opinion on dunc-tank at this time. This constitutes neither approval nor disapproval. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: Preparing linux-2.6 2.6.18-1
Sven Luther wrote: > On Fri, Sep 22, 2006 at 03:25:12AM -0700, Steve Langasek wrote: >> On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote: (someone, I'm not sure who, wrote:) >> > > Re-adding them at this stage >> > > 1) is against the current social contract >> >> > Yes, but then so is shipping the firmware actually still in main, >> >> So two bugs is better than one? > > Yes, because re-adding the drivers which used to be pruned, allow a > category of users to install, which they did not previously. Thus, your > arithmetic is wrong, because you don't count the "can't install" bug, and > if you do, it sorts out evenly, especially if you take in account that we > put non-free software and users equally in the SC. "Our users" cuts both ways. There are users who use Debian *because* the contents of main are (supposed to be) 100% free. I'm one. The two users complaining of Debian's "hypocrisy" on debian-legal recently are two more. Undoubtedly there are others, probably including many DDs. Those users are being mistreated in order to benefit some other users. (In some cases, nonexistent users. drivers/net/dgrs "was killed in place and never reached the market". No users were impacted by removing this driver, and we know that for a fact. Why readd it?) Meanwhile, "Debian will remain 100% free" doesn't really leave much room for argument. "Our users" is a priority, as is "free software", but "Debian will remain 100% free" is a *promise*. > Indeed, but then you also need to backport all the fixes that the kernel > team will put in 2.6.18 to 2.6.17, fine sharing of effort. Did you not > read Frederik's GR, where the kernel team states that kernel dev > ressources are rare, which is why we request a waival of the requirement > for etch, in order to be able to work on this issue in peace for etch+1, To be honest, if the release team was clearly making progress on removing the non-free firmware, you'd be a *lot* more likely to get a waiver. A good start would be the tg3 patches. Reintroducing the dgrs driver, which drives *no existing hardware at all*, would be a very bad move. Today I sent an email asking upstream to remove dgrs based on its uselessness; we'll see what happens. > without having to deal with the two new GRs a week over highly emotional > issues, not mentioning the remaining bullshit that is going on beside it > (RM payement, > duck stuff, Duck stuff? Quack, Quack? I have a wild turkey living in my front yard, but no ducks. > DPL recall, assorted GRs for various stuff). -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware and d-i
Geert Stappers wrote: > [ ] Just document how to (re)build with non free drivers. This is a good idea, of course. Is "building a custom d-i image" described anywhere? I think it *is*, because I seem to remember this being used for some custom distros, but I can't find the document right now. Anyone know where it is? Maximizing the number of systems which can be supported with the standard d-i image plus an additional disk/net repo/etc is still a good idea, which is why I'm working on it, and it's 90% done already. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft ballot for the assets constitutional GR
Manoj Srivastava wrote: > On Sun, 10 Sep 2006 21:56:02 +0100, MJ Ray <[EMAIL PROTECTED]> said: > >> Manoj Srivastava <[EMAIL PROTECTED]> >>> Note that this is a draft, voting is not yet open. Any comments >>> need to be in fast, though. > >> Could you name the amendment on the ballot, please? "Amend the >> constitution" is not descriptive enough. > > Since there is only one issue where voting is open, anyone who > can't figure out what is being voted upon probably should not be > voting. Especially since there was a link to the vote page. > > Does anyone themselves have had problems figuring out what > this was all about, or is it merely hypotheticals? It was pretty clear, but "Amend the Constitution (assets handling)" would have been better. Just in case someone mixed this up with some other constitutional amendment. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etchrelease
Frederik Schueler wrote: > Hello, > > On Mon, Sep 11, 2006 at 08:59:59PM -0700, [EMAIL PROTECTED] wrote: >> is to drop support (in whole or in part) for >> Broadcom NX2, Sun Cassini(+), Both nondistributable firmware anyway look, what list should this discussion be on? Can someone forward this to the right list if they ever figure it out? >> Intel PRO/100 (although some of those >> chips are also supported by the unaffected eepro100 driver), > > eepro100 is scheduled for removal upstream, not an option. Given that the e100 driver functions without firmware in earlier versions of the Linux kernel, I strongly suspect that most e100 cards do not need firmware loaded. Tearing out the firmware and the code loading it is likely to be an acceptable solution for most users. Since the firmware is nondistributable, it seems to me to be the only acceptable solution. >> and (maybe) five more members of the >> QL2xxx family. > > The firmware blobs are deprecated in 2.6.17 and have been removed in > 2.6.18-rc. You already need the non-free package containing the > firmwares to run these controllers with 2.6.17 and later, no need to > remove the drivers. Rocking. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
Steve Langasek wrote: > On Tue, Sep 12, 2006 at 01:47:18AM +0200, Frans Pop wrote: >> The project acknowledges that a lot of progress has been made with regard >> to the removal from the distribution (main) of "software" that could be >> considered non-free given the current wording of the Social Contract. >> However, in some cases for valid reasons, this work is not finished and > > > I suggest striking the above phrase, which adds nothing of substance to > the resolution. I assumed that it implied that in some cases it was not for valid reasons. Yes, definitely adds emotive content for no good reason. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
delays in the run-up to the release." In other words, no changes at all will be accepted. All changes pose risk. Some pose very low risk, but all changes pose at least a minimal risk. OK. > The initiatives started during the discussion on d-vote to implement some > kind of support are appreciated, but they are too late for Etch! > In my personal opinion they are also premature given the controversy that > exists over the question if firmware should really be treated as totally > non-free or rather be supported to some extend. Don't misrepresent the controversy, please. Too many people are already doing that. Of course sourceless MIPS binaries and the other stuff constituting this "firmware" are totally non-free; nobody's ever made a serious argument that it was free software. And it certainly should be supported, and everyone agrees. Just like other non-free software people need is supported. Namely, in the "non-free" section. The controversies are multiple: (1) Should Debian allow non-free material in main if it "doesn't really matter" for some reason that it's non-free, or if it's technically very desirable, or if it's not a traditional program, etc.? There are strong arguments for each of these; however, nobody arguing for this has yet been willing to propose an amendment the Social Contract to clearly say what they want it to. (It is *extremely* hard to write a clear amendment which allows non-free firmware and doesn't allow other non-free software, because there is no really clear distinction between a CPU on a peripheral and a "main" CPU. But if anyone manages to, it would be a good thing.) (2) Does it really matter that the firmware is non-free? (Many people argue that it doesn't, and they have some strong arguments, though they didn't convince me.) > Thanks for hearing me out, > FJP You're welcome. Thanks for listening to what I wrote: hopefully it will leave you with more understanding of the situation. *My* personal preference? - (1) Nondistributable material -- mostly "GPL without source" -- removed from the kernel packages and installer entirely, until it can be relicensed. Yes, this will hurt users. (The alternative is to come up with a coherent policy of trying to guess the intent of licensors rather than reading their actual licenses. It would be unfair to allow mislicensed material for the Linux kernel but not for other packages.) (2) tg3 firmware removed from kernel packaging, replaced with userland firmware loading and a firmware package in non-free. Tested and functional, y'know. (3) Testing done on loading udebs from an "extra" source, using the udebs from firmware-nonfree. In order to force firmware loading, the firmware udebs may need to rmmod and modprobe the relevant driver, since many drivers can't handle firmware loading at any time other than module loading, and udev may try to load drivers early. This isn't particularly pretty, but neither is non-free firmware. It will, however, work. If your CD-ROM needs non-free firmware to run, you need to netboot or boot from floppy or hard drive or USB stick. If your network card needs non-free firmware to run, you need to boot from CD or floppy or hard drive or USB stick. If your hard drive needs non-free firmware to run, you need to netboot or boot from CD or floppy or USB stick. If your USB stick needs non-free firmware to run, you need to netboot or boot from CD or floppy or hard drive. If your floppy drive needs non-free firmware to run (really only possible if it's connected to, say, a SCSI card which needs such firmware), then you need to netboot or boot from CD or hard drive or USB stick. If your SCSI card needs non-free firmware to run and your hard drive and CD and network card and floppy are all connected to it, you have a problem, and should be told to build your own custom installer CD. Or buy a better SCSI card. The two most common drivers which feature firmware loading are tg3 and e100. In both cases, the drivers do not require the firmware loading for the vast majority of actual cards on the market, so the above bootstrap problems will not come up for most tg3 or e100 users. (4) The above three can be done simultaneously. And started immediately. After they're done, work on moving the remaining 11 non-free distributable files moved to non-free and converting their drivers to firmware loading. (5) Long-term attempts to contact companies and get them to relicense their firmware so it's distributable. Having actually removed the nondistributable stuff might make it easier to get them to listen. Please feel free to forward this stuff to more appropriate lists. I really don't know what's most appropriate, so I'm responding where I read it. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
Thomas Bushnell BSG wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> Who is confident of this, and why? I'm not confident of this at all; I'm >> not sure that the idea of forcing sourceless firmware out of main is even >> an idea that the majority of developers agree with, Then do as Thomas suggests below and propose the honest GR. >> and Joey Hess has >> pointed out to us reasons why providing separate free/non-free install >> media might be a strategically poor use of our time in the *long term*, It won't be. Providing the ability to use "add-on" install media is very much a useful feature in the long term, particularly for (wait for it...) "added-value" redistributors. (Or perhaps you didn't mean add-on install media, and instead meant one monolithic "free" disk and one monolithic "non-free" disk. Indeed, that is not the preferred solution.) >> even if the work of splitting out this firmware proved manageable It is. >> and >> there were sufficient volunteers to do this work. There are. > So this gives me pause. > > I've been instructed that it's ok to vote for one of these > resolutions, because it's only a way to get etch out the door, and we > can come into real compliance with the Social Contract for etch+1. > > I have expressed some skepticism, being rather convinced that the > actual facts are that there are people who are happy to have the > kernel simply *never* come into compliance with the DFSG, for whatever > reasons, and that they have been dragging their feet in bringing it > into compliance. > > One of the people hinting at this has been Steve, who basically said > to me recently that for some packages, they would get booted from the > release for violating the DFSG, and for other packages, we just wink > and nod. > > Now we have it flat out: Steve thinks perhaps we will simply never > bring the kernel packages into compliance with the DFSG. > > So let's not hear about etch vs. etch+1; let's not hear about some > special thing for just this release. > > This is sounding like the behavior of the US Congress, which likes to > continually extend copyrights for one "limited" term after another, > thus producing the reality that copyright terms in the US are now > infinite. > > Just so, the claim that we are making temporary concessions so that we > can release is a cover for the real facts: some people simply do not > think the DFSG operates as an absolute bar to the inclusion of > non-free software in Debian. > > So, rather than dance around redefining "software" and telling us that > this is a just-this-once special-exception just-for-etch (never mind > that it is the second "just this once" special exception), can you > please propose the DFSG or SC amendentment you really want, the one > that clearly and unmistakably says "the following items can be > included in Debian even though they are not free software", and drop > the 100% promise that the Social Contract has always known? If I ever become a DD, I was going to propose GRs to this effect, probably one for each category. (There are only about four or five categories.) Even though I would vote *against* such GRs. (Well, with the exception of the license texts one. I'd vote for that one.) Because I'd prefer an up-or-down, yes-or-no, clear decision to the wink-and-nod business. While I'm not a DD, if anyone wants help drafting a GR to amend the Social Contract to *clearly allow* some particular thing which I consider non-free, I will be happy to help. I want such an amendment to be as crystal clear as possible, so that Debian is not deceiving anyone. (Unfortunately, I fear that perhaps some people really *like* the hypocrisy: such a person would want to keep non-free firmware in main but would not want the Social Contract to say so. I hope there are no such people but sometimes I fear that there are.) -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Diverting to -legal. Sven Luther wrote: > On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote: >> Sven Luther wrote: >> > Yeah, that is something which is needed. We need someone to go over >> > larry's list, which i have copiedto the debian wiki, and find out who >> > the copyright holder of those problematic firmwares are, and then we >> > can contact them, taking the broadcom original letter i wrote as a >> > sample. >> >> How optimistic you are. :-) After four or five attempts to find a >> contact address at Broadcom which would reply, I gave up; I'm glad >> someone else found one eventually. > > Actually, it was quite easy, i just wrote the linux driver support page, Hell, I did the same thing earlier. > and got a reply, but didn't get a reply. Which is why I was so impressed > it was fully CCed to debian-kernel, so you can look how i > did it. Hmm, maybe I will. Perhaps you used the "magic words" and I didn't. Let's try to figure out what the magic words are Or maybe it was simply a result of getting a *second* mail saying the same thing. > The reply was quite fast, altough the driver folk needed some time to > escalate it to the right people, and then find their legal team reply, it > took a couple of month or so. Compare that to all those who where shouting > that it was stupid, only lost time, and that broadcom, with their > anti-linux stance would never reply and stuff, so i have reasons to be > quite optimistic. :-) > The arsenic case was more problematic, since the copyright seems to have > landed at broadcom too, but they don't care since they don't sell it > anymore, Given this, we actually should have a decent chance of getting them to license it under a free software license (after all, what do they care about it?) provided we can talk to the right people. > and they probably are not even aware of the fact that they are > actually copyright holders. FYI, there is a way to deal with a copyright of unknown ownership. Get a license from everyone who *might* have the copyright. Of the form "*If* Broadcom holds any copyrights in this code, and we don't know whether we do, *then* Broadcom licenses its copyrights under license X. Broadcom does not license any copyrights which it does not hold as of ." Repeat with all other companies which might have some of the rights. Once you've gone through all of them, you have a proper license, even though you don't know who holds the copyright. This is essentially similar to getting "quitclaims" for contested land. > I had a similar problem with some ocaml library, which was developed > together byt the ocaml team and the digital labs, which ended up at HP, > and even asking bdale about it, did not help free that code, which is now > lost forever and upstream reimplemented it. At least we actually have the source for the acenic code, even though we don't have a free license for it. > I think the quote from bdale > was "i think i know in which set of boxes it may possibly be". > >> I think that throwing Debian's name around with 'offical' status may >> be helpful to get responses from some of these companies; I didn't do >> that, since I couldn't! > > Well, assuredly, but i think that another difference may have been the > more reasonable and well though-out mail with some legal analysis, and the > fact that what we demanded was quite easy for them to do. Also, the > timeline was maybe one of more maturity and sensibility on this subject, > and we had a rather huge thread on LKML when it happened. From your past > posts on the subject, i believe that maybe the wordings you chose where > not the best ones, but as i have not seen said mails ... Probably not the best words. I was very polite to them, since I really figured it was just an honest mistake (which it was), but I probably came across as an "unimportant nobody" and they figured it wasn't worth wasting their time. > Friendly, > > Sven Luther -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Anthony Towns wrote: > On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote: >> Actually, this is what is wrong with the polls at the debian user forums >> which AJ pointed people to. Etch can release on time either free (with >> less hardware support) or non-free (with more hardware support). >> Making "Release etch on time" top priority doesn't really answer the >> question of what to do. > > No, it doesn't, which is why there's a second poll on what should actually > be done: > > http://forums.debian.net/viewtopic.php?p=31128 > > The results are currently: > > ] Since it appears Debian has to make a choice, which would you prefer we > ] do for etch? > ] > ] 108 / 64% - Allow sourceless firmware in main > ]31 / 18% - Delay the release of etch > ](so that we can support loading firmware from > non-free) > ]29 / 17% - Drop support for hardware which requires sourceless > firmware > > I don't know that 170 or so votes is that impressive, given what I'd > estimate as the total number of Debian users. No, it's not. Popcon has counts in the thousands. OK, that poll is kind of useful. :-) I was wrong; correction noted. > It's also worth noting there are a few comments along the lines: > > ] I've voted to allow the firmware in main, but I also want to add > ] the remark that I hope the modifications to the debian installer > ] will be high on the priority list for the next debian release. > > Cheers, > aj -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
Anthony Towns wrote: > On Tue, Sep 05, 2006 at 12:53:50PM +0100, MJ Ray wrote: >> There are people interested. I think us mere mortals have been hindered >> by the slowness of the DPL and SPI on these topics. > > You might like to consider replying to: > > Subject: Re: Presumably-unauthorized Open Logo use > Date: Sat, 1 Jul 2006 18:30:28 +1000 > To: [EMAIL PROTECTED] > > then. > >> We could GR it, but there doesn't seem much objection - just inaction. > > When I asked in April about a week after my term began, Greg (the SPI > lawyer) replied: > > "I don't think there has been a great deal of interest in registering > the Debian logo. This is irrelevant. (1) Trademarks are established by use, not by registration. (2) We have been interested in establishing it; he's just wrong. He's wrong because the people who care have not been allowed to talk to him, as far as I can tell. Obstructionism, and you're helping obstruct. > On the one hand, the open use logo is not very > strong as a trademark, and it seems to get independently re-created > by various third parties around the world from time to time -- > therefore it would be terribly difficult to police. This is an argument for creating an entirely different logo. The trademark strength is irrelevant to the copyright license. Also, the logo is clearly at least as strong as the word "Debian" (since it contains the word). We need a proper trademark policy for the word as well. These *have been proposed* as MJ Ray noted, and have fallen into the black hole of "can't get legal advice and DPL won't do anything without it". "Pseudo-trademark" enforcement through copyright is a mistake, and doesn't achieve Debian's trademark goals. It has to be stopped. If the current logo gets independently recreated repeatedly, then the copyright-based pseudo-trademark protection is *useless*; it's worth less than even a weak trademark enforcement. > The official > logo does not seem to be very widely used or widely recognizable." > > The last mail on the spi-trademark was in May on a not-particularly > related matter. > >> On the logo copyright, the DPL needs to instruct SPI to change the >> licence. > > Changing the copyright license without establishing a proper trademark > would seem irresponsible and inappropriate to me. Yet you refuse to work on "establishing a proper trademark", and you haven't given those people who are interested in doing so access to the SPI lawyer. The copyright license doesn't achieve its stated goals. It prevents uses we approve of and allows uses we want to stop. It's quite irrelevant whether the current logo would be a "strong" trademark or a "weak" trademark; it's certainly stronger than the bare word "Debian", and treating it exactly the same way will lose us *nothing*. >> So, would this DPL like to be the one to take active leadership and >> fix the dumb debian logo bug? > > I haven't seen any interest whatsoever in dealing with this from other > developers, In other words, "I haven't been listening, so I've assumed nobody's talking". Yes, people have been quiet about it *during your term*. We got frustrated and burnt-out by throwing ourselves against a wall during the *two previous* DPLs' terms. > so I've deprioritised it. If that changes, It's "changed". Please make this a high priority. > I'll be happy to > put it back on my list of things to deal with. Thank you. Please tell the SPI lawyer to talk to start an email conversation with MJ about this; I'm sure he can keep anyone else (such as me) who is interested in the loop. MJ, are you OK with taking lead on this? AJ, I presume you will have no problem doing this if this really was a matter of miscommunication. Sorry I'm so irritable. Oh. Please feel free to forward my comments to the SPI lawyer, too. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Amendment - allow hardware support from non-free into the debian system
MJ Ray wrote: > So, the full position statement proposed is: > > > THE DEBIAN PROJECT: > 1. reaffirms its dedication to providing a 100% free system to > our users according to our Social Contract and the DFSG; and > 2. encourages licensors of all works to make those works > available not only under licenses that permit modification, but also in > forms that make such modifications practical; and > 3. as a special exception to help users who have vital hardware > without free software drivers yet, the Debian system and official CD > images may include hardware-support packages from the admin section of > the non-free archive area which conform to all Debian Free Software > Guidelines except guideline 2 (Source Code), or an archive section/area > with equivalent requirements. > > Sounds great. It still has very little effect as long as we have no official position on the distribution of *mislicensed* code. But it sounds great. I'd second, but I'm waiting for DAM approval. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
project can take that into account. If people think that point is
> worth adding to any of the other proposals that defer the free-firmware
> issue to post-etch, that's fine by me.
>
> It's fair to ask whether interpreting "software" to not cover all sorts
> of other things we distribute is a sensible thing to do, whether on a
> principled level ("but we *want* those other things to be free too"),
> a logical level ("what about postscript, or self-extracting zip files of
> documentation?") or a semantic level ("software means bits, it doesn't
> mean executables").
It should cover them all, for all three reasons. :-/
> But it seems to me that the current answer we have
> to that question is not working -- and given the length of time we've
> already had, I don't think there's a great likelihood that that will
> fundamentally change any time soon.
I can only attribute this to obstructionism. Practically, this is happening
because a small minority of developers have been staunchly opposed to fixing
any such legal issues. This is the definition of "obstructionism".
> I think it would be a waste of time
> giving it yet another chance instead of spending the time coming up with
> something better.
Watch out. It's pretty clear what the majority thinks, and what the
majority thinks is that the current answer is correct in the long run, even
if it's not currently achievable. :-/
> So personally, I think we really do need to start this
> debate afresh, hence (f).
>
> TTBOMK the Debian, Firefox and Thunderbird [3] logos all currently have
> non-free copyright licenses acting as trademark protection,
Which we all agree is BAD BAD BAD.
> hence the
> specific exception for logos, given images are mentioned previously.
> To
> date, no one else has been particularly interested in helping work out
> what we want to do about protecting the Debian logo by trademark instead
> of (non-DFSG) copyright provisions.
100% FALSE. Trademark licenses have been designed and proposed. We have
been trying to get a legal opinion from SPI's lawyer. We can't. The
previous DPL and other people of "authority" in Debian have been unwilling
to change the licenses until we get such an opinion. More obstructionism.
Perhaps you can help by getting me a direct hotline to SPI's lawyer.
> I believe that 5.1(5) of the constitution allows the project leader to
> propose draft resolutions/amendments without requiring the usual seconding
> process (cf [4]). I'm not intending to exercise that power here; please
> consider the above to be my personal view as a developer.
>
> Seconds and comments appreciated.
When you wrote this, you were clearly not fully aware of the situation, so
please try again.
--
Nathanael Nerode <[EMAIL PROTECTED]>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical limitations
Sven Luther wrote: > I heard claims of buginess in the patch, The buggy one was my radeon patch. It's rather hard to get right because of the complex interaction between X and the kernel, and because the DRI trunk doesn't like Linux-specific things, and we never did track down the problem. I'm not going to tackle that one again for a while -- I think it needs someone who is both good at Linux kernel development *and* understands the exact structure of the DRI system. There was one bug in the tg3 patch which Herbert Xu spotted and fixed related to having multiple tg3 boards present at once. As an aside, the tg3 driver is an ugly piece of work, because nearly the whole thing is in a single spinlock. > due in big part for the missing > upstream support for proper firmware loading Actually, kernel support was pretty much there by the time I wrote the tg3 patch. The userland tools weren't quite mature, however, which they are now. Back then not everyone was using hotplug (which was required), but now everyone uses udev. That probably makes a difference. Also, initially the firmware could only be loaded from /usr, which obviously irritated a lot of people; now it can be loaded from the root partition. > and probably the absense of > initramfs support, as we have now. Yes, there was some complaint about the lack of easy support for installing the firmware in the initrd. Which is not technically a bug, but the lack of a feature (netmounted root for those boards which need firmware loading). Isn't this still an issue? :-/ Doesn't it require udev to run in the initramfs, and isn't that not-yet-ready? (Although desired upstream, from what I remember -- this is the "early userland" stuff) Frankly, people who netmount root and use network cards requiring firmware loading are a pretty small group. But it would be nice to make it work for them. > Friendly, > > Sven Luther We are getting way off topic for -vote. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther wrote:
> On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> http://www.debian.org/devel/debian-installer will give you all the links
> you want, but for the lazy :
> svn://svn.debian.org/svn/d-i/trunk/packages/anna
Thank you very much.
Oddly, finding the d-i repo was impossible for me until you provided this
link. It's not linked from the above page (it is linked from the Wiki page
linked from the above page, but I hadn't wandered that particular path) and
I didn't guess its name, so I couldn't find it at http://svn.debian.org/ .
> Also, it is in the main/debian-installer section of the debian archive,
> even with source and all.
I found it shortly after posting this. ::embarassed::
I had done dozens of searches, but I didn't think to look for a package
which existed only in the debian-installer section of the archive.
Ended up finding it via google; I managed to put in just the right search
terms finally.
'Course, it looks like 'anna' doesn't need any changes :-/
>> > and we do not
>> > want to depend on that (and even then, we still would have non-free
>> > firmware, see above). But since there is lots of hardware which needs
>> > firmware for correct operation, the installer would not work for
>> > mainstream hardware otherwise.
>> >
>> > There are two ways how to deal with it:
>> > 1. Accept these issues as transitional issues for now; or
>> > 2. Delay etch for some serious time.
>>
>> Like a month or two, maybe. If people actually bother to work on it, or
>> to accept other people's work on it.
>
> Current estimates place this between 6 month and a year. The fact is the
> d-i team need at least a month or two of testing for this,
Yeah, testing is an issue.
On the other hand, releasing a fully free etch by simply removing hardware
support would be fast and trivial, and etch wouldn't be delayed *at all*.
(Obviously the priorities of 'our users' and 'free software' come into
conflict there.)
If etch will be released in a hurry ("Debian releases before it is
ready"), I'd rather see an etch weak on hardware support and strong on
freedom; I guess others would prefer the other way around.
Actually, this is what is wrong with the polls at the debian user forums
which AJ pointed people to. Etch can release on time either free (with
less hardware support) or non-free (with more hardware support).
Making "Release etch on time" top priority doesn't really answer the
question of what to do.
> even if the
> change was instantaneous, there are loads of packages which will trigger
> NEW, and so on.
Yeah, that could slow things down.
> Also, finding, approaching and convincing people to clarify the licence of
> the problematic ones, is something which will take some serious time.
Years. Decades. Centuries. OK, I'm a bit pessimistic on this.
>> > In our social contract, we promised that the users and the free
>> > software community are our priorities. We firmly believe that our users
>> > profit very much from releasing etch in time, and that this is
>> > important enough that we can accept the transitional status with having
>> > a few firmware
>> > images left in main that should belong somewhere else. Of course,
>> > everyone who wants to make the number of such firmware images as small
>> > as possible is welcome to help converting old firmware loaders to the
>> > new standard, and working on the Debian installer. We are happy if this
>> > issues become smaller or even vanishes, but we do not want this to be a
>> > release blocker.
>>
>> OK, this is good. :-) Does this mean that the patches converting the
>> tg3 driver to use firmware loading will be reaccepted?
>
> What is the position of the upstream author of the tg3 driver about this,
I recall little but emotional hostility, but I haven't asked in a while.
Maybe I'll try again when the patch is ready against the latest upstream.
> and even if he is still (i think it was him) strongly opposed, is your
> patch upstream-quality ?
It was used for months without complaints by many people; it's minimally
invasive; the one identified bug was fixed by Herbert Xu, although I
currently don't have a copy of his bugfix.
Currently other people are working on updating it to the current kernel,
which suits me fine. :-)
>> Note that I am not comfortable personally working on the drivers
>> containing improperly licensed firmware. (Except for working on getting
>> a
>> proper license, that is.) You may well find that the other volunteers
>> for
>
> Yeah, that
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: >> Actually, letting an overworked team of four with (to my knowledge) zero >> legal expertise settle questions of legal liability is pretty absurd too. > > They are the team responsible for vetting the legality of what's > distributed > on the mirrors. None of them have any legal expertise to my knowledge; > but they do know where the lawyers are if they have questions, Well, that's good! Do they really have the hotline to the lawyers? Excellent! I hope they actually use it occasionally; I've never heard of them doing so, so if they have gotten any legal opinions, they've kept them secret. (Dammit, when Debian developers attempted to get legal advice on trademark policy, it sunk into a black hole. The advice never really came back, after several years.) > and they > *are* the ones in the hot seat(s). Meaning that they are personally liable and the rest of the Debian developers aren't? :-) I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. It seems to me that the developers have entrusted the ftpmasters with the responsibility of guarding Debian's funds and property against a copyright infringment lawsuit. Is that the general feeling of the developers? Are the ftpmasters comfortable with that responsibility? If so, my proverbial hat is off to them. >> Should the ftpmasters, who have even less legal expertise, > > Judging by some of the nonsense that debian-legal is typically riddled > with, if I were an ftpmaster I would find that claim insulting. There is at least one laywer who posts regularly. Which counts as some legal expertise, and which is exactly what I was referring to when I said "very little". > The only claim to expertise that debian-legal has is in the area of > analyzing license terms and how they stack up against the requirements of > the DFSG. That is an important function, but it is *not* legal expertise. See above. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Wilcox wrote: > On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: >> On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: >> > I think the key distinction (as far as I'm concerned) is that Debian >> > isn't producing a distribution for the microcontroller in my >> > fibrechannel card, it's producing a distribution for my computer. >> > In order to make my fibrechannel card work, it has to poke some bits >> > in a documented way. Even if there happens to be an ARM onboard that >> > card that's running a program, that ARM isn't running Debian. >> >> One of the purposes of having access to the prefered form of >> modification, is to be able to fix bugs. > > Certainly, it's one of the purposes. But I don't think we've *lost* > anything by distributing binary firmware. Certainly not. That's what non-free is for, and I am in full support of distributing binary-only firmware in non-free. As long as it's properly licensed, which most of the stuff at issue isn't. :-/ > Consider the cases: > > 1. Everything in hardware. You're not able to fix anything without a >soldering iron ... and good luck to you with that. > 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a >good deal of skill to fix anything. Again, best of luck. > 3. Binary-only firmware in the driver. Slightly better chance of trying >to figure out what's going on, but still low. > 4. Firmware source in non-preferred form. Modifications probably >possible, but when the next round of changes come out from the >vendor, you probably have to ditch your mods. > 5. Firmware source in preferred form. Can send changes back to vendor, >everybody wins. > > (and I'm sure people can think of other finer distinctions). > > You seem to want to disallow cases 3 and 4 ... in main. Non-free exists for this. > which makes sense from a > "here are the rules of data freedom, now i must follow them" point of > view, but really don't make sense to the vendor, nor to the user. It > seems like an all-or-nothing approach. Well, if you don't realize that non-free exists to make exactly this compromise. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical limitations
Josselin Mouette wrote: > I propose the following amendment to Steve's proposal. > >> THE DEBIAN PROJECT therefore, >> >> 1. reaffirms its dedication to providing a 100% free system to >> our >> users according to our Social Contract and the DFSG; and >> >> 2. encourages authors of all works to make those works available >> not >> only under licenses that permit modification, but also in forms that make >> such modifications practical; and >> >> 3. supports the decision of the Release Team to require works >> such as >> images, video, and fonts to be licensed in compliance with the DFSG >> without requiring source code for these works under DFSG #2; and > > 4. determines that as a special exception to DFSG #2, the source code > for device firmwares contained in the kernel packages will not be > required as long as there are no other technical means to install and > run the Debian system on these devices. Seems reasonable One practical result of this: * The tg3 driver would have two of the three embedded firmware images removed from 'main'. They are not necessary for installation or runtime; they do add some performance. The one image which is necessary for certain rare, old tg3 boards would remain. (Most tg3 boards don't need any firmware loaded.) Because of stuff like this, this amendment would in fact have a different result from all previous proposals. > Rationale: most of us want to release etch ASAP, and most of us want to > remove the firmwares from the kernel ASAP. This is a way that shouldn't > stop the ongoing work on both of these issues. The wording makes it > clear that as soon as the kernel and d-i are able to use split out > firmwares, the migration will have to be done. This way we won't > discourage the work from Nathanael Nerode and other people who worked > hard so far to remove the non-free blobs, Actually, the only thing which seriously discouraged me was when Debian reverted the patch to convert tg3 to firmware loading and resumed shipping the BLOBs. I understand why it was done (the loadable firmware was not being shipped, because the license hadn't been fixed yet), but it was very discouraging. Adding BLOBs which weren't in the previous release is very discouraging. (Frankly, I'm waiting until those BLOBs are out of 'main' again before trying to work on anything else -- sort of waiting for a sign of good faith, if you will.) Anything else is not really that discouraging. > and we won't hold etch > development because of that issue. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
MJ Ray wrote: > I think the idea that refusing to ship non-free firmware in main will > strengthen demand for free firmware is worthy of consideration. Debian > helps users to take control of their operating system. Increasing the > demand for free firmware might also help users to take control of their > hardware, or at least highlight that there's this crap which their > operating system uses to support their hardware but doesn't have its > normal freedoms. > > However, I'm undecided whether it's a good idea to exclude them from the > distribution CDs and so on. How big is the problem of vital hardware > which won't work without firmware being copied to it? Complete list at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html, with details. What that list does *not* show is that certain drivers only need firmware loaded for some of their supported cards. In the case of tg3, only a few rare (and old) cards actually need the firmware loaded. > Should we split > non-free into non-free-hardware and non-free, allowing non-free-hardware > packages onto the CDs? Should we allow certain non-free material onto the installation CDs? Actually, that would be an compromise OK with me: the installation CDs only get used the once, and the material would be clearly separated out into the non-free section during and after installation. Doesn't address the legal issue of whether material without a proper distribution license should be included. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Garrett wrote: > Bernhard R. Link <[EMAIL PROTECTED]> wrote: > >> We are giving a promise here, that with the stuff in our distribution >> you have the freedom to use it, to give it to others and to fix it. >> This means the missing of legal obstacles and the possibility to do so. >> For this discussion "preferred form of modification" is perhaps not the >> best definition. It's good for licenses as it is not easily to work >> around. I think here the difference is between the source being in >> a form practical to edit or not. Without a practical form there is >> no possibility to change it. And this is a limitation we have to >> make clear to people and not lock them into by claiming all is good >> and well and it could be part of our free operating system. > > We never included non-free applications in main because we felt that > there was no need to. And, indeed, even in 1993 it was possible to use a > computer without any non-free applications. > > That doesn't hold with the firmware argument. With applications, we had > the choice between "Free but less functional" and "Non-free but more > functional". With firmware we have the choice between "Non-free but on > disk" and "Non-free but in ROM". There isn't a "Free" option at all yet. Except for those cases where there is, such as adaptec, ser_a2232, ixp2000, wanxlfw, atmel, 53c700, 53c7xx, aic7xxx, sym53c8xx_2, and keyspan_pda. Yes, that includes a very common SCSI card and a very common NIC. > So I think the real question is "How does us refusing to ship non-free > firmware help free software?". WE'RE NOT CONSIDERING DOING THAT. I hate to shout, but *have* you heard of non-free? It was mentioned in the post you're replying to! well, we are considering doing it in the cases where the firmware is *improperly licensed*. There, the benefit is (a) not getting sued and protecting downstream from liability, (b) clearly respecting copyright holders and respecting their stated desires. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
in
> the kernel itself as part of Debian Etch, without further conditions.
This ("without further conditions") would seem to promise that firmware will
be included even if it doesn't actually carry a license which permits
redistribution (as is the case for over 50 BLOBs in the upstream Linux
kernel). Is this correct? Are you specifically ordering the ftpmasters to
carry material which is technically improperly licensed?
If so, that's OK by me (it doesn't give me any legal liability), and it has
the substantial benefit of actually addressing the status of the majority of
upstream BLOBs in etch. But it should be *very clear* that this is what is
happening: that this GR is making a *legal liability* decision for Debian.
Note that I am not comfortable personally working on the drivers
containing improperly licensed firmware. (Except for working on getting a
proper license, that is.) You may well find that the other volunteers for
converting drivers to firmware loading are not comfortable working on them
either. This is bound to be a problem, given that the number of BLOBs with
good, clear licenses is quite small.
> We want to emphasize that the success of this GR is considered as
> necessary by the kernel and release team for successfully delivering etch
> in time (and to allow us a successful planning of that).
This is actually a reasonable GR which I could support, except for the
misleading prologue.
> on behalf of the kernel- and release team
> Frederik Schueler
>
--
Nathanael Nerode <[EMAIL PROTECTED]>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther wrote: > Since the firmware blobs are not derivative works of the kernel, but > constitute mere agregation in the same binary format, the authors of other > pieces of GPLed code fo the linux kernel cannot even sue us for > distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal >> minefield. That is higher priority than the entire discussion going on >> right now, because it determines whether Debian will distribute these 53 >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > liability. It's the domain of the ftp team to determine whether we can > legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. I know this is Debian tradition, but it's worth thinking about whether it really makes sense. Debian-legal has very little legal expertise, and as a result the consensus errs on the side of caution at essentially all times with regard to copyright. Probably too much caution, but without getting an actual legal opinion, that seems like the right thing to do. Should the ftpmasters, who have even less legal expertise, ever take the risk of erring on the side of recklessness? (This risk is currently being taken with the mislicensed 'firmware' BLOBs.) Does this expose anyone but the ftp team to legal liability? Now, if the rest of Debian has repeatedly disavowed all responsibility, it may be that the ftp team and only the ftp team are *personally* liable if Debian makes an illegal distribution, and in that case it would make sense for them to determine such things. I'm not sure the ftpmasters are actually comfortatble with assuming personal legal liability for every package in Debian though. I wouldn't be! -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The bigger issue is badly licensed blobs (was Re: Firmware poll
Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Luk Claes wrote: >> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- >> 6c557439-9c21-4eec-ad6c-e6384fab56a8 >> [ 1 ] Choice 1: Release etch on time >> [ 3 ] Choice 2: Do not ship sourceless firmware in main >> [ 2 ] Choice 3: Support hardware that requires sourceless firmware >> [ ] Choice 4: None of the above >> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > [Non-DD opinion] > > [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source > drivers like nvidia) that can be legally > redistributed, do not ship BLOBs that can > not be legally redistributed. It's worth noting for purposes of discussion the actual numbers here. >From http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html we find: * 14 free pieces of firmware with source code (great) * 46 drivers requesting BLOBs from userland (OK) * 47 BLOBs which can't be legally redistributed (bad) * 6 addditional BLOBs removed from Debian which can't be legally redistributed (bad) * at least 2 BLOBs (radeon and r128) which appear to be shipped with false copyright statements (bad), but if not, then are distributable. * the 12 keyspan BLOBs, removed from Debian, which have a unique license which makes them distributable in the linux kernel package, but makes it unclear whether they can be legally distributed as an addon package! * 1 BLOB in Debian (emi26) with a license like the keyspan BLOBs. * 9 BLOBs which can definitely be legally redistributed (in five drivers: mga_warp, tg3, typhoon, advansys, qla2xxx). So frankly the output of this entire discussion isn't going to cover very many BLOBs: exactly seven drivers will definitely be allowed to go into or stay in main for etch if 'sourceless firmware' is allowed without other changes. Of those, one (tg3) functions without the BLOBs for most cards and has been converted to userland firmware loading, and one (qla2xxx) has firmware loading code included upstream but disabled -- so those two are among the very easiest cases for moving the BLOBs to non-free. I've also volunteered to work on converting advansys to userland firmware loading, and to test anyone else's advansys conversion. The majority of the BLOBs have serious licensing problems, which won't be addressed by any decision regarding free, non-free, source, or sourceless material. Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. However, presumably the manufacturers who (in nearly all cases) provided the BLOBs intended them to be distributed -- although they never granted a proper license. (Of course, for all I know perhaps some of the manufacturers were evil geniuses and knew perfectly well they weren't granting a proper license, intending to cause trouble later.) Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, and Debian continues to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy up the copyrights to them from the original companies, and then I'd have a real case for a lawsuit. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Poole wrote: I'm not going to argue with your previous points, which are all basically accurate. > Related to (a), current programmable hardware cannot run *any* CPU at > speeds that most users would accept for desktop use. However, solving > that issue simply requires training users to expect even less > function[1]. There is a rather subtle, but vital, point here which you appear to be missing. Debian supports users of non-free software, and will continue to. The goal is to make it *possible* to run Debian on a fully free system. The goal is certainly *not* to make a fully free system a *requirement* for Debian. In other words: If Debian is running on *one* fully free system, then the Debian system doesn't require the use of non-free components. You may prefer to use non-free components, however, and the Debian system should retain compatibility with/support for them as long as developers are willing to do so. > It seems like this option is more palatable to Debian > than helping users get the most function for their hardware and time > investment. That statement is a strawman given what I just pointed out above. We understand that at any given time before the utopian free software world of the far future, there will probably be components where the free alternatives perform worse than the non-free ones. Most users will use a combination of the Debian system and a few non-free components, as they do now. If they start getting irritated with the non-free components, they may switch to the free alternatives, and/or try to improve them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9M9jRGZ0aC4lkIIRApOZAJ90zk7TlcKU11FV1muKTa63XZUZawCcCNLf dMpFEZyGbeo50SMf6Wclwfw= =IPMP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Manoj Srivastava wrote: > On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek <[EMAIL PROTECTED]> > said: >> 4. determines that for the purposes of DFSG #2, device >>firmware shall also not be considered a program. > > This would require us to amend the foundation document of the > DFSG, and define that what Debian defines as software program > is different from the common definitions of the term > > In order for us to have a meaninglul foundation document, we > can't debate and use our own "special" definitions of common terms, > since the definition in turn uses words that can be "defined" in a > "special" fashion. > > So, unless otherwise stated, the foundation document terms > refer to commonly understood meanings of words; looking to > dictionaries, encyclopedias, and common references. > > Calling firmware not programs is our own "special" definition > of firmware, and or program, and hence must be defined explicitly in > the DFSG. If we want to state that we only consider certain programs > to be free, we ought to be upfront and clear about it in our > foundation document. 110% in agreement with Manoj. Q: How many legs does a dog have, if you call the tail a leg? A: Four. Calling the tail a leg doesn't make it one. (Attributed to Abraham Lincoln.) I fail to see any way in which an executable MIPS binary is not a "program", by any definition. If you want to amend the DFSG to state "3. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, this requirement does not apply to firmware, defined as ." I would strongly oppose such a change, but it would be a legitimate, reasonable GR (requiring 3:1 supermajority of course). In contrast, clause 4 of Steve Langasek's proposal is a backhanded and not very forthright way of trying to change the DFSG without changing them. Steve, you're better than this: please fix your proposal to do the straightforward thing. > > manoj -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Improving keyring maintenance (was Re: question for all candidates)
If you don't want to read the rant, skip to the bottom where I volunteer to help Anthony Towns wrote: >In the mail to the DPL I mentioned above, James outlined three fairly >significant technical changes that could be implemented to make the >job easier, and could be done by anyone, without requiring any special >priveleges; Why on EARTH didn't he outline these needed changes to *debian-devel*, or put them on the Debian wiki, or in some other way let *everyone* know what needed to be done? Nobody's going to volunteer to do them if nobody knows *what they are*. On the other hand, if he publicized what he needed, I promise he'd get volunteers writing code almost immediately. *This* is what's wrong with James's communication skills. Apparently it's also a problem with the *DPL*, who could equally well have publicized the same needed changes. --- Anyway, thank you for finally describing the issues (in http://lists.debian.org/debian-vote/2006/03/msg00275.html). If I could be pointed to the existing scripts for managing debian-keyring.gpg, I can start work on making them componentised, simple, obviously correct and secure, and fast. That sort of work is what I'm especially good at. I could start an alioth project for "keyring-manangement-scripts" if anyone else is interested in working on this. Hmm, this is going off topic for -vote Replies to -devel please. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR: Amendment: invariant-less in main v2
> > I *hope* that this amendment is simply supposed to mean that the Developers > > don't believe that the DRM clause imposes such restrictions (despite the fact > > that reading it literally, it does). But at the moment, which of these two > > positions is being pushed by the amendment is not clear to me. Adeodato? > > The latter. From the last paragraph in my mail: Thanks for replying on the public mailing list and making this clear to everyone including me. That eases my worries about this. Because it means that if a copyright holder actually does start talking about enforcing the GFDL on a work in a literalistic way which includes all the restrictions we find unacceptable, Debian *will* remove that work. Which is what really matters. :-) -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR: Amendment: invariant-less in main v2
<[EMAIL PROTECTED]> wrote: > - several people expressed the view that they interpreted the wording > differently, as in "it states that some GFDL-licensed works meet > the DFSG, and thus are suitable for main", for which a 1:1 > majority would be enough. ... > All the relevant information about the > invariant sections problem is in the first paragraph anyway, and I > don't see much point in carrying details about the other two issues, > when they don't affect us at all. (This has been discussed elsewhere, > but if somebody does still have concerns over the DRM clause, or the > Transparent Copies one, I guess we can go over them again.) I just want to be clear on this. This proposal, if adopted, is a statement by the developers that the "DRM clause" and "Transparent Copies" clause, and any identical clauses stuck into other licenses, are presumed DFSG-free. Right? No comment or criticism was made in version 1 or 2 of this amendment on the problems found with these clauses. The list of which were included verbatim in version 1 of this amendment, and included bits such as: (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permission So, does this mean that if this amendment is passed, outlawing storing a copy of a document with non-world-readable permission is considered an acceptable, free restriction by the Developers? Really? I *hope* that this amendment is simply supposed to mean that the Developers don't believe that the DRM clause imposes such restrictions (despite the fact that reading it literally, it does). But at the moment, which of these two positions is being pushed by the amendment is not clear to me. Adeodato? -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
aj@azure.humbug.org.au wrote: > Actually it's the opposite claim -- it's not about the spirit of the license > that Nick's talking about, it's the spirit of the DFSG. True, that is what he said, so I guess my comment was off-point. Of course, everyone agrees that we should adhere to the spirit of the DFSG -- the people who consider the GFDL non-free are perhaps the most ardent advocates of this. We tend to believe that for a license to be Free, it must not impose any restrictions, intentional or unintentional, which are contrary to the spirit of the DFSG. Simply claiming that something adheres to the spirit of the DFSG doesn't make it true. I believe that my description of the arguments of the people who want to ignore the problems with the text of the GFDL remains accurate: they want to look at the spirit of the license rather the actual text. It's a tenable position, though I don't agree with it. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
> On Thu, Feb 02, 2006 at 01:02:54PM +0200, Kalle Kivimaa wrote: > > Actually, I think that both FSF and DFSG define "free software" pretty > > similarily. The problem arises from the fact that our Social Contract > > applies DFSG to all works, not just software, whereas FSF considers > > software a special case. Exactly. (Except that we've also argued about the meaning of "software". The FSF considers "software" to mean "computer programs", while some of us with more respect for linguistic history use the old meaning of software: "any collection of bits", or "anything in the computer that's not hardware".) > > Do note that (eg.) the invariant sections are > > _not_ present in the GPLv3 draft. Anton Zinoviev <[EMAIL PROTECTED]> wrote: > They are not present because this would make some useful modifications > impossible. As I have noted elsewhere (debian-legal, just this week), the Invariant Sections in the GCC Manual make some very useful modifications impossible. Perhaps you're not an essayist. As a writer of essays, I understand the value of free licenses for essays; it's just as large as the value for free licenses for programs, if not larger. A good piece of rhetoric is a lot harder to replace by rewriting than a good piece of code. Availability of source code is not an issue, but rights to create derivative works are a *HUGE* issue. Consider, for example, some famous derivative works of the Declaration of Independence: the Declaration of Sentiments and the Declaration of the Rights of Man. Good thing the Declaration of Independence was freely licensed. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL [was: Anton's amendment]
Anton Zinoviev <[EMAIL PROTECTED]>: > If the project secretary decides > that my proposal (for GFDL) requires 3:1 supermajority, this would > mean that the project secretary decides on behalf of the whole project > that our notion of "free software" differs from the notion of FSF. This is not correct. The FSF, through RMS, has officially claimed that documentation does not need the same freedoms as programs, and furthermore has stated that the GFDL is not a free software license (they appear to be using "software" to mean "programs"). If Debian decides that the GFDL is not a "free software" license, then it is *agreeing* with the FSF. On that one point. -- Nathanael Nerode <[EMAIL PROTECTED]> "It's just a goddamned piece of paper." -- President Bush, referring to the US Constitution http://www.capitolhillblue.com/artman/publish/article_7779.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Nick Phillips <[EMAIL PROTECTED]> wrote: > Now, the amendment (Adeodato's) itself. I've just noticed that it's a > complete waste of space as presented at > http://www.debian.org/vote/2006/vote_001 -- the second paragraph of > point 2) of the first (un-headed) section reads as follows: > > Formally, the Debian Project will include in the main section of its > distribution works licensed under the GNU Free Documentation License > that include no Invariant Sections, no Cover Texts, no > Acknowledgements, and no Dedications, unless permission to remove > them is granted. > > Can you read that carefully and tell me (with a straight face) that it > says what its author intended it to say? I don't think you can -- and > that single error (if it is indeed presented as proposed) in what is a > critical part of the document renders that entire amendment > ridiculous. You're right, this is misdrafted in such a way that the "unless permission to remove them" clause can't be correctly parsed to mean anything. But what do you expect from people who are essentially requesting that we pay attention only to the spirit of licenses, and ignore the letter? This strikes me as exactly what you should expect; they're being true to their belief that the actual wording doesn't matter. It should say: > Formally, the Debian Project will include in the main section of its > distribution works licensed under the GNU Free Documentation License > that include no Invariant Sections, no Cover Texts, no > Acknowledgements, and no Dedications; and works licensed under the GNU Free > Documentation License where permission is granted to remove any Invariant > Sections, Cover Texts, Acknowledgements, or Dedications. That's clearly what the author meant, and that's clearly not what the GR says. Note how similar this situation is to the GFDL's DRM clause and opaque/transparent clauses, which clearly do not say what the author meant. Those exact clauses where this GR is proposing to allow works under them into Debian. Interesting, eh? -- Nathanael Nerode <[EMAIL PROTECTED]> "It's just a goddamned piece of paper." -- President Bush, referring to the US Constitution http://www.capitolhillblue.com/artman/publish/article_7779.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
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. Well, um. That depends if you want the GR-as-amended to actually *do* anything other than spark a giant flamewar, doesn't it? See below: There's a good argument that a GR which contradicted the Social Contract without the supermajority authority would be null and void. > In fact, Adeodato's amendment is clear in its explanation that "we > believe that the GFDL does meet the spirit of the DFSG (so long as you > have no invariant sections)". If, therefore, that particular amended > version of the GR were to pass, it would be clear that a majority of > developers *did not* believe that it required or constituted a > modification to either the Social Contract or the DFSG. This argument-to-the-spirit is interesting: it is the claim that Debian should accept works where we believe that the intention of the license is satisfactory, even if the actual letter of the license is not and we have no clarification from the copyright holder. This is a very unwise thing to do in my opinion; I don't think it serves Debian's users to accept such software when the licensor could easily decide to enforce the license as written. But it is a tenable position, I suppose: a "don't be legalistic or excessively careful, even in matters of the law -- just accept anything that looks OK at first glance" position. If it is the consensus view of Debian Developers (and I'm pretty sure it isn't), then I will go along with it. Just as long as it's made clear to the users (preferably with a note attached to the Social Contract or something). If it does pass, I will likely request that bsdgames-nonfree and xsnow be included in 'main' because it looks like the intention of these licenses is as free as the GFDL, although the letter of the licenses isn't and we have no clarification from the copyright holder. Again if it does pass, I will *definitely* request the same for povray, as we know for sure that the intention of the license is free (thanks to the current relicensing effort), although the letter of the license isn't and we have no clarification from many of the copyright holders. These actions would be in keeping with the new interpretation of the Social Contract, which I would be honor-bound to support. Perhaps this viewpoint would be better for Debian all around. I don't think so, but I would bow to the will of the developers and see how it works out. > Even if for some reason that I am unable to fathom you do fervently > believe that I am wrong in the above paragraph, then there is *still > nothing* to say that we can't happily pass GRs that contradict each > other. It would be foolish, sure, and perhaps reflect poorly on our > ability to work through these things, but democracies pass laws like > that the whole time and the courts seem to manage to resolve the > contradictions. Debian doesn't have courts. The closest we've got is debian-legal, and there's a group of people who deny the legitimacy of debian-legal. (They are usually the same people trying to put or keep random unmodifiable junk in main.) If Debian passed a GR which contradicted the Social Contract -- without being an "implicit amendment" -- I would assume that the Social Contract would win and the GR would be void. That's normally how analagous situations are dealt with in real courts. That seems particularly undesirable. > Note that the alternative to this process is for someone (usually a > General, it seems) to stand up and tell the parliament not to be so > damn silly, and to follow his interpretation of the constitution, or > else. This usually ends badly for all concerned. So with no courts, that's the only alternative, then? :-( -- Nathanael Nerode <[EMAIL PROTECTED]> [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
Margarita Manterola <[EMAIL PROTECTED]> wrote: > What would be the point of your proposal? I mean, if this proposal > won, it would be exactly the same as if the "no GFDL in main at all" > proposal won. So, why have yet another option? Peter Samuelson <[EMAIL PROTECTED]> wrote: > The point is to explain to the world what is wrong with the GFDL. If > someone still wants to use it, on works which are not yet written, or > whose license can still be changed (all the copyright holders are still > around and can agree on this), Nathaniel's option gives clear steps > for what they need to do. Yes, that was the only point of it. *However*, I withdraw my proposal, because I have realized that we never worked out whether the "Acknowledgements and Dedications" requirements in the GFDL were free restrictions or not. (These restrictions are significantly weaker restrictions than the other, non-free restrictions; but they're significantly stronger restrictions than similar ones in any determined-free license.) Accordingly, my proposal may not actually represent consensus views. So don't propose it as an alternative -- unless you're sure what you want to do about the "Acknowledgements and Dedications" business, which would hopefully involve at least one more round of discussion on debian-legal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
Anton Zinoviev wrote:
>Derived Works
>
>The license must allow modifications and derived works, and must allow
>them to be distributed under the same terms as the license of the
>original software.
>
> Notice that DFSG do not say "arbitrary modifications".
The general interpretation we've taken of this is "must allow modifications in
general, with restrictions allowable if they do not prevent reasonable use
cases".
"Invariant sections" prevent several reasonable use cases, which is why
they're generally considered non-free.
("Must allow X" is usually interpreted in law and ordinary English, IIRC, as
"must allow X in general". You could interpret it as "must allow at least
one X", but that's clearly not what the DFSG writers intended, and more
importantly, the "in general" interpretation is the normal interpretation of
the text.)
> For example GPL says
>
>If the modified program normally reads commands interactively when
>run, you must cause it, when started running for such interactive
>use in the most ordinary way, to print or display an announcement
>including an appropriate copyright notice and a notice that there
>is no warranty (or else, saying that you provide a warranty) and
>that users may redistribute the program under these conditions, and
>telling the user how to view a copy of this License.
It's worth noting that many people consider this clause non-free, but it's
generally rendered free by the important line you omitted:
> (Exception: if the Program itself is interactive but does not normally print
such an announcement, your work based on the Program is not required to print
an announcement.)
> If we want to decide whether some particular restrictions in the
> license make the license non-free or not, we have to use external to
> DFSG arguments. For example everybody is free to decide that the
> invariant sections make the document non-free but this can not be a
> consequence from DFSG.
Well, it's true that it can't be a pure, logical consequence. There is
*interpretation* (of the DFSG, of the Social Contract, of the license)
involved. It is not a matter totally separate from the DFSG either, however.
> My personal addition to DFSG is this: the license must allow us to
> improve the program and/or the documentation.
Ah. You've omitted an absolutely vital freedom, which the FSF seems to have
forgotten about when writing the GFDL: the freedom to adapt the work for
another purpose.
Many of us care very strongly about this freedom. This freedom is one of the
primary reasons why free software has been successful. Licenses which deny
or severely restrict this freedom must IMNSHO be considered non-free. The
major limits it places on this freedom are the fundamental practical reason
why the GFDL is a bad license.
--
Nathanael Nerode <[EMAIL PROTECTED]>
A thousand reasons. http://www.thousandreasons.org/
Lies, theft, war, kidnapping, torture, rape, murder...
Get me out of this fascist nightmare!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
In the interests of completeness (sigh), I believe that a GR should be proposed which states: (portions copied from the GR by [EMAIL PROTECTED] -- hope he won't sue me for copyright infringement) The Debian Project asserts that Works licensed under the GNU Free Documentation License, version 1.2, as published by the Free Software Foundation (GNU FDL), are free in accordance with the Debian Free Software Guidelines (DFSG), if and only if (1) the work is licensed using the following options of the license: no Invariant Sections, no Front-Cover Texts, no Back-Cover Texts, (2) all copyright holders state that the requirement "You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute" in section 2 is waived with respect to copies you make and do not distribute, (3) all copyright holders state that the requirements of paragraph 3 of section 3 (regarding transparent and opaque copies) are waived, and (4) all copyright holders state that the requirements of section 4.I (requiring preservation of an entirely arbitrary History section) are waived. This amounts to what those of us who have actually bothered to take a close look at the license agree on. I'm still in NM, so I request that some DD propose this. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
[EMAIL PROTECTED] wrote: > The license is an agreement that regulates one action: the distribution, > right? No, unfortunately. Under copyright law, creating private copies, or private modified copies, is one of the exclusive privileges of the copyright holder. You need permission from the copyright holder (or one of the special exemptions such as 'fair use') in order to do so. For a license to be considered DFSG-free, debian-legal believes that it should not restrict anything but distribution. (In fact most of us believe that copyright should restrict nothing but distribution.) However, under the current law in every country I know of, a copyright license can restrict other things, including private copies. (And if you look at the EULA licenses of most proprietary software, they do restrict them.) > Is this clause enforcable to your private copies (considering it > as a bug)? Yes. > or just to the copies you distribute... No. > > I mean, I know the license says "the copies you make or distribute", > but, by definition, wouldn't it apply only to the act of distribution? No. And there's the problem with this clause, in a nutshell. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Sunday 22 January 2006 16:45, Anton Zinoviev wrote: > > In fact, the license says only this: > > > >You may not use technical measures to obstruct or control the > >reading or further copying of the copies you make or distribute Did any of you actually *read* this? Read it. What it actually *says*, means that storing a copy on a multiuser machine with UNIX permissions set so that it can't be read by everyone is *prohibited*. The permissions are clearly a "technical measure". They clearly obstruct and control the reading or further copying of that copy. > > It is not supposed to refer the use of encryption or file access > > control on your own copy. And yet it does, clearly, refer to that. This is what we call "bad drafting". We have repeatedly asked the FSF to revise the GFDL to fix this drafting error. They have refused. (Note that if it only applied to "copies you distribute", it would be fine and free. The problem is that it explicitly applies to copies you make and do not distribute.) When a license clearly says one thing, we do not say "Well, it's OK because they probably didn't really mean it." Doing this is OK if we actually have the written, explicit agreement of the copyright holder that s/he didn't really mean it. But it is not a reasonable thing to do for a license applied by many disparate copyright holders, or indeed one where the license author refuses to fix an obvious drafting error. Both are the case for the GFDL. A vote for Anton's GR is a vote to ignore the actual text of licenses entirely when determining DFSG-freeness, in favor of some nebulous guess as to what we think the license is supposed to mean. Trust me, if it passes, I will use the same argument to get xsnow into main, since the author probably didn't intend to restrict modification. -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
Anthony Towns wrote: > (2.1) Invariant Sections > > The most troublesome conflict concerns the class of invariant sections > that, once included, may not be modified or removed from the documentation > in future. Modifiability is, however, a fundamental requirement of the > DFSG, which states: > > 3. Derived Works > > The license must allow modifications and derived works, and > must allow them to be distributed under the same terms as the > license of the original software. > > Invariant sections create particular problems in reusing small portions > of the work (since any invariant sections must be included also, > however large), and in making sure the documentation remains accurate > and relevant. Please note the following: "Cover Texts create the same problems as Invariant Sections." -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: GFDL statement
Ian Jackson wrote: > Also, >> (4) How can this be fixed? > > This section should be clarified and strengthened. In particular, we > should encourage documentation authors to (at the moment) dual-licence > GDFL/GPL. The recommendation is: "License your documentation under the same license as the program it goes with. If you need to license under the GFDL for some reason, dual-licence." I think -legal came to a very definite consensus that licensing the documentation under the exact same license as the program was always the right thing to do. It saves *so* much trouble. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Discussion - On proposal E (Transition Guide)
Robert Millan wrote: > > I'm concerned about proposal E. I believe it essentialy means that any > changes that are made to the DFSG or SC won't have any effect if they make > them more strict, but they will have effect if they relax them. Is that > the intended in "[..] for a limited time, Debian will not be compliant > with the new Social Contract"? > > Seems like the use of the word "limited" is ambigous. Any amount of time > is "limited" by a greater one. > Any comments on this? The US Supreme Court used this unfortunate definition when interpreting the US Constitution to allow arbitrarily long copyright periods. Please change it to read "a limited time, not more than XXX", whether XXX is "two releases" or "two years" or whatever. -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal to modify DFSG
Paul M Foster wrote: > I couldn't agree with this more. > > On the binary kernel drivers issue, well maybe > > But specifically on the issues of documentation and licenses, it's > patently obvious that this isn't "software" and shouldn't be treated as > such. You can't go around randomly modifying RFCs and the GPL. That's > the whole point of them. And yet, because you can't, they don't satisfy > part of the DFSG, and thus must be removed? You've missed the point in the same way as many other people. The word "modifying" is used as shorthand for "creating derivative works". (Although I'm going to stop using that shorthand since it seems to confuse people.) You should be able to make a derivative work of an RFC (under a different name, of course), in order to define a different standard. Prohibiting this is not "the whole point" of the RFCs by any means. I could use your argument on programs with the same validity: "You can't go around randomly modifying a program which does X so that it does something different. That's the whole point of the program." See the missing distinction? -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
Michael Banck wrote: > On Thu, May 06, 2004 at 03:01:29AM -0400, Nathanael Nerode wrote: >> Michael Banck wrote: >> > In contrast, having the possibilty to modify $APPLICATION's stock >> > 'File->Open' icon in its native form, i.e. gimp layers or whatever >> > seems to be of less importance by several orders of magnitude, as long >> > as we can *somehow* fix it by e.g. replacing it with another one, or >> > fixing it by gimping it up or so. I mean, very few of us are graphic >> > designers or so. >> Well, I suppose the graphic designers among Debian should comment. :-) > > How many are there? How often do you have to modify graphics when > packaging stuff? How often do you 'have to' modify programs? It's not just about when you 'have to', it's also about when you *want to*. I *want to* modify graphics and sounds rather often. I believed that Debian was supposed to free software, not merely "software which you have the right to modify for the limited purposes of making it run on your computer". >> > Same goes with fonts. >> Likewise. > > You'd find even less people who'd design fonts. And I don't know how > many would just modify a given font or rather create a new one from > scratch. Most would prefer to modify preexisting fonts. I've talked to people who do make typefaces, and almost all of them are based on other typefaces. > >> > Even less so with "You've got mail" sounds or >> > so, what's the use in having the Cubase samples for that or something? >> > We could still edit the waveform somehow, even if that would be a bit >> > more tedious >> Ow. A lot more tedious. > > Sure. But how often do you have to modify sounds when packaging stuff? > Compared to modifying Makefiles or C source code? > > I agree that programs shipping sounds for the sake of *creating* music > (like samples for a tracker) should be capital F free so that people > making music can use them in a useful way. But I don't believe the same > holds for a 'You've got mail' sound from e.g. Evolution. While there's definitely an important distinction here, this is a deeply problematic and difficult distinction to pin down. License texts are currently exempted partly based on a somewhat similar argument; but they fall much further on one side of the line. I think that the right to *repurpose* a derived work is important; just having the right to modify and use it for the original work's original purpose is not enough. Also, the right to *replace* the "You've got mail" sound is clearly essential. Given that, if the sound is not legally modifiable -- but you have the right to remove it and replace it -- isn't it easier all around, and clearer to users and modifiers, to use a modifiable sound? > Perhaps the crucial part is to look whether the file in question can be > reasonably/typically used to create new art/software as opposed to just > accompain a bigger package. Well, I haven't found one which couldn't be. > Source code is fundamentally different, > because that's in the scope of our core business. Um. Is this really a good, valuable distinction? Then perhaps Debian should put all graphics in 'non-free', since they're not 'core', but merely added value. -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
Manoj Srivastava wrote: > Umm, I have nothing but proprietary hardware. Never had any > non-proprietary Hardware. most people don't. Indeed, is there such > a thing as non-proprietary hardware? Yes. It's not at *all* common, but if you have completely freely implementable/modifiable specs for the hardware, and they also aren't patent-encumbered, you can build non-proprietary hardware. Some really old pre-computer electronics hardware undoubtedly qualifies. -- There are none so blind as those who will not see.
Re: Amendment to the Constitution: Add a new foundation document
Michael Banck wrote: > However, it is very hard to determine and carve in stone the 'point of > no return' for a release, especially as we are still experimenting with > the way we do releases. But I guess we could have the release manager > officially declare a point somewhere in the middle of the release cycle > which marks the change from 'developping randomly' to 'working towards > the release'. At this point, changes to the SC would only be applied to > the next stable release after the one worked on by the time. Would this also apply to * changes in the interpretation of the SC * newly identified DFSG-compliance problems when applying an unchanged interpretation of the SC ? I'd suggest that it should. The untimely late discovery of an improperly licensed file in the middle of XFree86, the Linux kernel, or any other major program in the Debian system, can wreak just as much havoc as a change to the SC. And as we've seen, a change in interpretation may do the same thing. A "freeness freeze" for each release would be a practical accomodation to the problems of release coordination, although a somewhat radical change from the current assumptions. > This > declaration could be accompanied by the policy freeze or whatever other > the devices the RM will have at his fingertips at that time. > > This would make it more reliable for everybody to judge the implications > of the changes, and lift off the burden of decision after a vote off the > shoulders of the Release Manager. > > > What do you all think of this? > > > Michael > -- There are none so blind as those who will not see.
Re: First Draft proposal for modification of Debian Free Software Guidelines:
Michael Banck wrote: > Having the full source code (and not something obfuscted beyond > recognition) for a computer program so we are able to fix bugs and, if > necessary, fork it, seems to be essential to what we're doing, namely > providing the world with a operating system that rocks (and is free, > yada, yada). Hmm. How about an image provided as a binary pixmap dumped as hex and embedded into a C source file? :-) (Yes, I found one.) Would that qaulify as sufficiently removed from the native form to be an incredible pain in the neck? > In contrast, having the possibilty to modify $APPLICATION's stock > 'File->Open' icon in its native form, i.e. gimp layers or whatever seems > to be of less importance by several orders of magnitude, as long as we > can *somehow* fix it by e.g. replacing it with another one, or fixing it > by gimping it up or so. I mean, very few of us are graphic designers or > so. Well, I suppose the graphic designers among Debian should comment. :-) > Same goes with fonts. Likewise. > Even less so with "You've got mail" sounds or > so, what's the use in having the Cubase samples for that or something? > We could still edit the waveform somehow, even if that would be a bit > more tedious Ow. A lot more tedious. > IMHO, we should be pragmatic here in the limits the social contract and > the DFSG allow. Be liberal in what you accept and conservative in what > you give. We should be ruled by the concern whether included that > particular array of bits will (i) improve our distribution, (ii) improve > the Free Software community and (iii) do not impose unreasonable > restriction on the aggregated package. Well, this set of priorities is arguable. But suppose we accept it. It all depends on the interpretation of (ii). Some people would say that including bitmaps for fonts without their outline sources hurts the free software community. Others would say that including xsnow in 'main' helps the free software community. There is no way to objectively test this: partly because the 'free software community' is pretty nebulous; and partly because it's very hard to predict the results of such actions (Will the lack of xsnow drive people to use Red Hat? Will the removal of sourceless fonts encourage people to supply fonts with source?) It's not really a very good test because it can be used by anyone to argue any which way (and it is). > I'm not sure whether the other developers think alike and if so, whether > we should clarify on this or whether that is the standard reading of the > social contract. -- There are none so blind as those who will not see.
Re: First Draft proposal for modification of Debian Free Software Guidelines:
Buddha Buck wrote: > OK, rip it to shreds. Thank you for making such a proposal. If I were a DD, I would second it to get it on the ballot -- because I think it's a clear proposal worth voting on -- and then I would vote against it because I think it's the wrong way to go. :-) -- There are none so blind as those who will not see.
Re: Social Contract GR's Affect on sarge
Manoj Srivastava wrote: > Umm, I have nothing but proprietary hardware. Never had any > non-proprietary Hardware. most people don't. Indeed, is there such > a thing as non-proprietary hardware? Yes. It's not at *all* common, but if you have completely freely implementable/modifiable specs for the hardware, and they also aren't patent-encumbered, you can build non-proprietary hardware. Some really old pre-computer electronics hardware undoubtedly qualifies. -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to the Constitution: Add a new foundation document
Michael Banck wrote: > However, it is very hard to determine and carve in stone the 'point of > no return' for a release, especially as we are still experimenting with > the way we do releases. But I guess we could have the release manager > officially declare a point somewhere in the middle of the release cycle > which marks the change from 'developping randomly' to 'working towards > the release'. At this point, changes to the SC would only be applied to > the next stable release after the one worked on by the time. Would this also apply to * changes in the interpretation of the SC * newly identified DFSG-compliance problems when applying an unchanged interpretation of the SC ? I'd suggest that it should. The untimely late discovery of an improperly licensed file in the middle of XFree86, the Linux kernel, or any other major program in the Debian system, can wreak just as much havoc as a change to the SC. And as we've seen, a change in interpretation may do the same thing. A "freeness freeze" for each release would be a practical accomodation to the problems of release coordination, although a somewhat radical change from the current assumptions. > This > declaration could be accompanied by the policy freeze or whatever other > the devices the RM will have at his fingertips at that time. > > This would make it more reliable for everybody to judge the implications > of the changes, and lift off the burden of decision after a vote off the > shoulders of the Release Manager. > > > What do you all think of this? > > > Michael > -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
Michael Banck wrote: > Having the full source code (and not something obfuscted beyond > recognition) for a computer program so we are able to fix bugs and, if > necessary, fork it, seems to be essential to what we're doing, namely > providing the world with a operating system that rocks (and is free, > yada, yada). Hmm. How about an image provided as a binary pixmap dumped as hex and embedded into a C source file? :-) (Yes, I found one.) Would that qaulify as sufficiently removed from the native form to be an incredible pain in the neck? > In contrast, having the possibilty to modify $APPLICATION's stock > 'File->Open' icon in its native form, i.e. gimp layers or whatever seems > to be of less importance by several orders of magnitude, as long as we > can *somehow* fix it by e.g. replacing it with another one, or fixing it > by gimping it up or so. I mean, very few of us are graphic designers or > so. Well, I suppose the graphic designers among Debian should comment. :-) > Same goes with fonts. Likewise. > Even less so with "You've got mail" sounds or > so, what's the use in having the Cubase samples for that or something? > We could still edit the waveform somehow, even if that would be a bit > more tedious Ow. A lot more tedious. > IMHO, we should be pragmatic here in the limits the social contract and > the DFSG allow. Be liberal in what you accept and conservative in what > you give. We should be ruled by the concern whether included that > particular array of bits will (i) improve our distribution, (ii) improve > the Free Software community and (iii) do not impose unreasonable > restriction on the aggregated package. Well, this set of priorities is arguable. But suppose we accept it. It all depends on the interpretation of (ii). Some people would say that including bitmaps for fonts without their outline sources hurts the free software community. Others would say that including xsnow in 'main' helps the free software community. There is no way to objectively test this: partly because the 'free software community' is pretty nebulous; and partly because it's very hard to predict the results of such actions (Will the lack of xsnow drive people to use Red Hat? Will the removal of sourceless fonts encourage people to supply fonts with source?) It's not really a very good test because it can be used by anyone to argue any which way (and it is). > I'm not sure whether the other developers think alike and if so, whether > we should clarify on this or whether that is the standard reading of the > social contract. -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First Draft proposal for modification of Debian Free Software Guidelines:
Buddha Buck wrote: > OK, rip it to shreds. Thank you for making such a proposal. If I were a DD, I would second it to get it on the ballot -- because I think it's a clear proposal worth voting on -- and then I would vote against it because I think it's the wrong way to go. :-) -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
Craig Sanders wrote: > On Fri, Apr 16, 2004 at 09:59:36AM +0100, MJ Ray wrote: >> On 2004-04-16 04:32:57 +0100 Craig Sanders <[EMAIL PROTECTED]> wrote: >> >> >On Thu, Apr 15, 2004 at 09:19:39AM +0100, MJ Ray wrote: >> >>Even if not "decided" unanimously, the "jury" doesn't seem to be in >> >>much doubt on it >> >where's the GR and the vote? hasn't happened. where's the policy >> >decision? doesn't exist. >> >> Now you're just being silly: > > no, it's the loony extremists who want to throw out good software just > because they don't have carte-blanche to modify the documentation that are > being silly. some (as in "some, but NOT all") restrictions on modification > of docs are perfectly reasonable, just as some restrictions on > modification of software are reasonable (e.g. don't remove any copyright > notices or changelog history. > don't steal credit for someone else's work. these ARE restrictions on the > freedom to modify, but nearly everyone agrees that they are reasonable and > do not present a problem). Yes. We accept the same restrictions on documentation as we do on programs. Go look it up. The complaints are about other restrictions, which we definitely do not accept on programs. >> where are the GR for all other licensing decisions? If you want to change >> how things are done, you probably need to write a GR (or you could just >> convince nearly everyone, but I can't that happening from such a low >> base). Until then, the DFSG apply to all software, not just programs. > > and clause 4 applies too, which explicitly allows a > modification-by-patch-only > restriction. errata sheets are "patches" for documentation. Deletion sheets? Such as "Section 9 is lies, don't read it?" It's an idea, albeit a very annoying and impractical one. But we aren't granted explicit permission to make such deletion sheets for GFDL Invariant Sections, anyway; and that doesn't deal with any of the *other* problems with the GFDL, either. -- There are none so blind as those who will not see.
Re: GR: Alternative editorial changes to the SC
Craig Sanders wrote: > On Fri, Apr 16, 2004 at 09:59:36AM +0100, MJ Ray wrote: >> On 2004-04-16 04:32:57 +0100 Craig Sanders <[EMAIL PROTECTED]> wrote: >> >> >On Thu, Apr 15, 2004 at 09:19:39AM +0100, MJ Ray wrote: >> >>Even if not "decided" unanimously, the "jury" doesn't seem to be in >> >>much doubt on it >> >where's the GR and the vote? hasn't happened. where's the policy >> >decision? doesn't exist. >> >> Now you're just being silly: > > no, it's the loony extremists who want to throw out good software just > because they don't have carte-blanche to modify the documentation that are > being silly. some (as in "some, but NOT all") restrictions on modification > of docs are perfectly reasonable, just as some restrictions on > modification of software are reasonable (e.g. don't remove any copyright > notices or changelog history. > don't steal credit for someone else's work. these ARE restrictions on the > freedom to modify, but nearly everyone agrees that they are reasonable and > do not present a problem). Yes. We accept the same restrictions on documentation as we do on programs. Go look it up. The complaints are about other restrictions, which we definitely do not accept on programs. >> where are the GR for all other licensing decisions? If you want to change >> how things are done, you probably need to write a GR (or you could just >> convince nearly everyone, but I can't that happening from such a low >> base). Until then, the DFSG apply to all software, not just programs. > > and clause 4 applies too, which explicitly allows a > modification-by-patch-only > restriction. errata sheets are "patches" for documentation. Deletion sheets? Such as "Section 9 is lies, don't read it?" It's an idea, albeit a very annoying and impractical one. But we aren't granted explicit permission to make such deletion sheets for GFDL Invariant Sections, anyway; and that doesn't deal with any of the *other* problems with the GFDL, either. -- There are none so blind as those who will not see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Craig Sanders wrote:
| On Sun, Apr 04, 2004 at 01:38:15PM -0400, Nathanael Nerode wrote:
|
|>Craig Sanders wrote:
|>
|>
|>>On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote:
|>>
|>>>This would clarify the main point that has been spawning endless
attempts
|>>>by occasional maintainers to sneak non-free stuff into "main".
|>>
|>>what "endless attempts" would these be? have there been any incidents in
|>>the real world (i.e. outside of your fevered imagination)?
|>
|>Oh, let's see, "firmware" in the kernel, GFDL docs, boot sectors,
RFCs, and
|>that's off the top of my head. Mindi/mondo (which contained, among other
|>things, pico). Those enough "incidents" for you?
|
|
| actually, NONE of them are incidents of maintainers *attempting* to
*sneak*
| non-free stuff into main.
|
| "attempt" and "sneak" indicate a deliberate and active deception, when
all of
| the "incidents" you mention are actually cases of either a)
insufficient care
| and attention being paid to license issues, or b) trusting the upstream
| developers (e.g. the kernel). i.e. sloppiness and/or trust rather
than deceit.
Herbert Xu knows of non-free firmware in the kernel sources and is
leaving it in main until someone else finds it. That's certainly
deliberate and active, if not deception.
Mindi-kernel was put in with a "source" tar.gz consisting entirely of
unsourced binaries; it's hard to imagine how the maintainer could
possibly have missed that, or thought that it was OK.
Admittedly, many of the others are due to confusion on the part of
maintainers who think (presumably because of the nonsense puffed out
over the years) that the DFSG doesn't apply to documentation.
| as for RFCs and other documentation, the jury is still out on whether
they can
| be included in main. no final decision has been made. you shouldn't
pre-empt
| that decision by declaring them to be an attempt to sneak non-free
stuff in
| main. for years (since the start of Debian), they HAVE been
considered free
| enough to go in main.
AJ Towns actually referred me to a thread from 1999 in which Joey Hess
disagreed strongly
http://lists.debian.org/debian-legal/1999/debian-legal-199910/msg00099.html
| it's only the loony exteremists who have been trying to
| kick out GNU documentation in the last few years to make a stupid
point (and,
| presumably, to prove that they are Holier Than Stallman).
Nope, it's not to 'make a stupid point'. There are straightforward,
practical reasons for concluding that they are non-free (and furthermore
a pain in the neck). I came to this originally because the GCC manual
contains an Invariant Section which is really inaccurate for GCC
("Funding Free Software", which is rather obsolete, and describes some
theoretical funding method totally different from that actually used to
pay for GCC) -- and it can't be changed.
|>>you bigots lost the vote (you didn't even come close) - can't you please
|>>just shut up and go away?
|>
|>Um, I have nothing against having "non-free", I'm against having non-free
|>stuff in "main". Hello?!? Not the same thing.
|
|
| they're the same old lies, though, and we've heard them over and over
again.
No lies; I have evidence for everything I said. *sigh*
| the actual "incidents" that have occurred are so trivial that they
have to be
| sexed-up (to use a currently fashionable term) to make them seem
relevant and
| interestingit's hard to get people outraged over trivial and boring
| mistakes, so they have to be turned into "sneaky attempts"
Feel free to call them "trivial" if you like; I disagree.
|>> do you really have to try to continue the
|>>"discussion", by any desperate means possible?
|
|
| obviously you do.
|
| please don't. it's boring.
Obviously not to you, or you wouldn't keep replying. ;-)
| craig
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAdgwXRGZ0aC4lkIIRAmerAJ9GAmjv9yYwuvx3fa226372VS0/4ACeN+Lf
1V97Og+9bUxTY+A71U4ac9k=
=XsSN
-END PGP SIGNATURE-
Re: GR: Alternative editorial changes to the SC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Craig Sanders wrote:
| On Sun, Apr 04, 2004 at 01:38:15PM -0400, Nathanael Nerode wrote:
|
|>Craig Sanders wrote:
|>
|>
|>>On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote:
|>>
|>>>This would clarify the main point that has been spawning endless
attempts
|>>>by occasional maintainers to sneak non-free stuff into "main".
|>>
|>>what "endless attempts" would these be? have there been any incidents in
|>>the real world (i.e. outside of your fevered imagination)?
|>
|>Oh, let's see, "firmware" in the kernel, GFDL docs, boot sectors,
RFCs, and
|>that's off the top of my head. Mindi/mondo (which contained, among other
|>things, pico). Those enough "incidents" for you?
|
|
| actually, NONE of them are incidents of maintainers *attempting* to
*sneak*
| non-free stuff into main.
|
| "attempt" and "sneak" indicate a deliberate and active deception, when
all of
| the "incidents" you mention are actually cases of either a)
insufficient care
| and attention being paid to license issues, or b) trusting the upstream
| developers (e.g. the kernel). i.e. sloppiness and/or trust rather
than deceit.
Herbert Xu knows of non-free firmware in the kernel sources and is
leaving it in main until someone else finds it. That's certainly
deliberate and active, if not deception.
Mindi-kernel was put in with a "source" tar.gz consisting entirely of
unsourced binaries; it's hard to imagine how the maintainer could
possibly have missed that, or thought that it was OK.
Admittedly, many of the others are due to confusion on the part of
maintainers who think (presumably because of the nonsense puffed out
over the years) that the DFSG doesn't apply to documentation.
| as for RFCs and other documentation, the jury is still out on whether
they can
| be included in main. no final decision has been made. you shouldn't
pre-empt
| that decision by declaring them to be an attempt to sneak non-free
stuff in
| main. for years (since the start of Debian), they HAVE been
considered free
| enough to go in main.
AJ Towns actually referred me to a thread from 1999 in which Joey Hess
disagreed strongly
http://lists.debian.org/debian-legal/1999/debian-legal-199910/msg00099.html
| it's only the loony exteremists who have been trying to
| kick out GNU documentation in the last few years to make a stupid
point (and,
| presumably, to prove that they are Holier Than Stallman).
Nope, it's not to 'make a stupid point'. There are straightforward,
practical reasons for concluding that they are non-free (and furthermore
a pain in the neck). I came to this originally because the GCC manual
contains an Invariant Section which is really inaccurate for GCC
("Funding Free Software", which is rather obsolete, and describes some
theoretical funding method totally different from that actually used to
pay for GCC) -- and it can't be changed.
|>>you bigots lost the vote (you didn't even come close) - can't you please
|>>just shut up and go away?
|>
|>Um, I have nothing against having "non-free", I'm against having non-free
|>stuff in "main". Hello?!? Not the same thing.
|
|
| they're the same old lies, though, and we've heard them over and over
again.
No lies; I have evidence for everything I said. *sigh*
| the actual "incidents" that have occurred are so trivial that they
have to be
| sexed-up (to use a currently fashionable term) to make them seem
relevant and
| interestingit's hard to get people outraged over trivial and boring
| mistakes, so they have to be turned into "sneaky attempts"
Feel free to call them "trivial" if you like; I disagree.
|>> do you really have to try to continue the
|>>"discussion", by any desperate means possible?
|
|
| obviously you do.
|
| please don't. it's boring.
Obviously not to you, or you wouldn't keep replying. ;-)
| craig
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAdgwXRGZ0aC4lkIIRAmerAJ9GAmjv9yYwuvx3fa226372VS0/4ACeN+Lf
1V97Og+9bUxTY+A71U4ac9k=
=XsSN
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
Craig Sanders wrote: > On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote: >> >> This would clarify the main point that has been spawning endless attempts >> by occasional maintainers to sneak non-free stuff into "main". > > what "endless attempts" would these be? have there been any incidents in > the real world (i.e. outside of your fevered imagination)? Oh, let's see, "firmware" in the kernel, GFDL docs, boot sectors, RFCs, and that's off the top of my head. Mindi/mondo (which contained, among other things, pico). Those enough "incidents" for you? > you bigots lost the vote (you didn't even come close) - can't you please > just > shut up and go away? Um, I have nothing against having "non-free", I'm against having non-free stuff in "main". Hello?!? Not the same thing. > do you really have to try to continue the > "discussion", by any desperate means possible? > > craig > -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Alternative editorial changes to the SC
Craig Sanders wrote: > On Sat, Mar 27, 2004 at 05:05:57PM -0500, Nathanael Nerode wrote: >> >> This would clarify the main point that has been spawning endless attempts >> by occasional maintainers to sneak non-free stuff into "main". > > what "endless attempts" would these be? have there been any incidents in > the real world (i.e. outside of your fevered imagination)? Oh, let's see, "firmware" in the kernel, GFDL docs, boot sectors, RFCs, and that's off the top of my head. Mindi/mondo (which contained, among other things, pico). Those enough "incidents" for you? > you bigots lost the vote (you didn't even come close) - can't you please > just > shut up and go away? Um, I have nothing against having "non-free", I'm against having non-free stuff in "main". Hello?!? Not the same thing. > do you really have to try to continue the > "discussion", by any desperate means possible? > > craig > -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Michael Banck wrote: > On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: >> Raul Miller wrote: >> > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: > >> >> No, trust me, we parsed this one very carefully and took an excessive >> >> amount of time on this in debian-legal. There are two possible >> >> interpretations, but both come out to an "and". > >> > That's so bogus I don't know where to start. ^^^ >> Start by learning English better? > > I would be *really* grateful if you could limit /this/ discussion to > something civil. > > So either drop your usual insults or drop -vote from your mailbox. I presume this is addressed to Raul, for his insulting statement above? Given that most of the rest of my message was devoted to explaining precisely why his "and/or" interpretation was impossible for someone with sufficient understanding of English, I think my comment was actually appropriate and to-the-point. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Hamish Moffatt wrote: > On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: >> Raul Miller wrote: >> > * There are people in Debian. >> Fine, there are a bunch of silly interpretations as well. The context >> indicates that "Debian" means "the Debian system" or "the Debian >> distribution". You could interpret it as meaning "the Debian Project", >> but that would be silly, because it would make the whole Social Contract >> make >> no sense whatsoever. (Are you software? Are you free software?) > > I think you are being too quick to dismiss Raul's comments. He has > pointed out in the past that "Debian" means a lot of different things; > it's a project, an OS, among others. > > So "Debian will remain 100% Free Software" is not entirely clear, > given that Debian is a bunch of people in certain contexts. > Why not spell out the context? Quite right and perfectly reasonable -- spelling out the context is a fine idea. But it's essentially a different topic from the message Raul was replying to, which was explaining that there are only two possible ways to interprent the "...will remain 100% Free Software" part of the sentence, and that his "and/or" interpretation simply wasn't one of them. > Hamish -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Hamish Moffatt wrote: > On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: >> Raul Miller wrote: >> > * There are people in Debian. >> Fine, there are a bunch of silly interpretations as well. The context >> indicates that "Debian" means "the Debian system" or "the Debian >> distribution". You could interpret it as meaning "the Debian Project", >> but that would be silly, because it would make the whole Social Contract >> make >> no sense whatsoever. (Are you software? Are you free software?) > > I think you are being too quick to dismiss Raul's comments. He has > pointed out in the past that "Debian" means a lot of different things; > it's a project, an OS, among others. > > So "Debian will remain 100% Free Software" is not entirely clear, > given that Debian is a bunch of people in certain contexts. > Why not spell out the context? Quite right and perfectly reasonable -- spelling out the context is a fine idea. But it's essentially a different topic from the message Raul was replying to, which was explaining that there are only two possible ways to interprent the "...will remain 100% Free Software" part of the sentence, and that his "and/or" interpretation simply wasn't one of them. > Hamish -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Michael Banck wrote: > On Mon, Mar 29, 2004 at 01:21:33AM -0500, Nathanael Nerode wrote: >> Raul Miller wrote: >> > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: > >> >> No, trust me, we parsed this one very carefully and took an excessive >> >> amount of time on this in debian-legal. There are two possible >> >> interpretations, but both come out to an "and". > >> > That's so bogus I don't know where to start. ^^^ >> Start by learning English better? > > I would be *really* grateful if you could limit /this/ discussion to > something civil. > > So either drop your usual insults or drop -vote from your mailbox. I presume this is addressed to Raul, for his insulting statement above? Given that most of the rest of my message was devoted to explaining precisely why his "and/or" interpretation was impossible for someone with sufficient understanding of English, I think my comment was actually appropriate and to-the-point. -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Raul Miller wrote: >> >> >> 1. Debian Will Remain 100% Free Software > >> >> This states that everything in Debian is software, and futhermore that >> >> everything in Debian is free. > >> > :%s/and furthermore/and\/or/ > > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: >> No, trust me, we parsed this one very carefully and took an excessive >> amount >> of time on this in debian-legal. There are two possible interpretations, >> but both come out to an "and". > > That's so bogus I don't know where to start. Start by learning English better? > I'll limit myself to two observations: > > * There's more than two interpretations. Yeah, but some of them are not possible -- they're just plain wrong, because they are based in not understanding English well enough. Your interpretation above is one of the ones which is just plain wrong -- there's no possible interpretation with an "or" in it. > * There are people in Debian. Fine, there are a bunch of silly interpretations as well. The context indicates that "Debian" means "the Debian system" or "the Debian distribution". You could interpret it as meaning "the Debian Project", but that would be silly, because it would make the whole Social Contract make no sense whatsoever. (Are you software? Are you free software?) > If you want to supply a reasoned argument, feel free. OK, I'll repeat the *same* explanation for the hundredth time, and I'll put in lots of detail, because you're being silly. First, accept that "Debian" means "The Debian system" here. Second, accept that the statements in the Social Contract are true only to the best of people's knowledge and ability -- the fact that non-free things have gotten in by accident does not materially affect the meaning. >> >> >> 1. Debian Will Remain 100% Free Software I think we both know that the words at issue here are "100% Free Software". The sentence can be parsed in only two ways. I can't do sentence diagramming in ASCII very well, so I'll just show the grouping: (1) (Debian) ((will remain) (100% (Free Software))) This means that "100%" of Debian "will remain" Software, and that that software will be "Free". (2) (Debian) ((will remain) ((100% Free) Software))) This means that Debian "will remain" software, and that that software will be "100% Free". Either way, Debian will be Software, and that software will be Free. That's the English language meaning. When I say "I will remain a male human", it doesn't mean "I am human and/or male", it means "I am human and male". Deal with it. (I suppose there might be some subtle difference between interpretations 1 and 2 -- in particular, interpretation 2 might theoretically allow for Debian to be "software" but not "100% software"; maybe only 99% software. It doesn't affect things materially.) -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Raul Miller wrote: >> >> >> 1. Debian Will Remain 100% Free Software > >> >> This states that everything in Debian is software, and futhermore that >> >> everything in Debian is free. > >> > :%s/and furthermore/and\/or/ > > On Sat, Mar 27, 2004 at 05:27:34PM -0500, Nathanael Nerode wrote: >> No, trust me, we parsed this one very carefully and took an excessive >> amount >> of time on this in debian-legal. There are two possible interpretations, >> but both come out to an "and". > > That's so bogus I don't know where to start. Start by learning English better? > I'll limit myself to two observations: > > * There's more than two interpretations. Yeah, but some of them are not possible -- they're just plain wrong, because they are based in not understanding English well enough. Your interpretation above is one of the ones which is just plain wrong -- there's no possible interpretation with an "or" in it. > * There are people in Debian. Fine, there are a bunch of silly interpretations as well. The context indicates that "Debian" means "the Debian system" or "the Debian distribution". You could interpret it as meaning "the Debian Project", but that would be silly, because it would make the whole Social Contract make no sense whatsoever. (Are you software? Are you free software?) > If you want to supply a reasoned argument, feel free. OK, I'll repeat the *same* explanation for the hundredth time, and I'll put in lots of detail, because you're being silly. First, accept that "Debian" means "The Debian system" here. Second, accept that the statements in the Social Contract are true only to the best of people's knowledge and ability -- the fact that non-free things have gotten in by accident does not materially affect the meaning. >> >> >> 1. Debian Will Remain 100% Free Software I think we both know that the words at issue here are "100% Free Software". The sentence can be parsed in only two ways. I can't do sentence diagramming in ASCII very well, so I'll just show the grouping: (1) (Debian) ((will remain) (100% (Free Software))) This means that "100%" of Debian "will remain" Software, and that that software will be "Free". (2) (Debian) ((will remain) ((100% Free) Software))) This means that Debian "will remain" software, and that that software will be "100% Free". Either way, Debian will be Software, and that software will be Free. That's the English language meaning. When I say "I will remain a male human", it doesn't mean "I am human and/or male", it means "I am human and male". Deal with it. (I suppose there might be some subtle difference between interpretations 1 and 2 -- in particular, interpretation 2 might theoretically allow for Debian to be "software" but not "100% software"; maybe only 99% software. It doesn't affect things materially.) -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > * Nathanael Nerode ([EMAIL PROTECTED]) [040325 00:55]: >> > Well, IMHO the old version is much nicer. The social contract _should_ >> > in my opinion have some nice, not too technical start. A promise is a >> > very good start, and I'd like to keep that there. >> You have a point. Andrew's version is clearer, but less stylish. How >> about this? > > Wouldn't it be good to have a stylish and clear text? In my opinion we Yes. :-) > shouldn't lose the stylish in trying to get a clearer text. (And, BTW, > we don't have any real hard problem with the current text. But - the > SC is more a "political" text then a real contract. Nobody could sue > Debian for not following the SC, but the SC is one important part of > Debians attractivity. > > >> > In the second sentence, I'd like to keep the word "below", as the DFSG >> > _are_ a part of the SC. >> Today's debate over matters of total insignificance: Are the DFSG part of >> the SC or are they a separate document? Why do people care, given that >> the same modification rules apply to both of them if they're separate, >> and the same importance is given to both of them? > > Why do people try to change this, if there is no need? Yeah. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Alternative editorial changes to the SC
Andreas Barth wrote: > * Nathanael Nerode ([EMAIL PROTECTED]) [040327 23:10]: >> How about "...entirely free software. This includes programs, >> documentation, data, and any other works which are part of the Debian >> system (except possibly license texts which are distributed only for >> legal >> reasons). We provide the guidelines..." > > The idea is definitly good. However, I'm not satisfied with the > wording and the place in the text. OK, me neither, really, but it's the best I've come up with at the moment. Hopefully others will provide better, more stylish solutions. :-) >> > 3.: keep the word "immediately" instead of "promptly" (as this is, at >> > least in my opinion, easier to understand for non-native speakers). > >> It means something different; "promptly" is as soon as is reasonable; >> "immediately" is *right this minute, before you go downstairs*. > > Well, I consider it of much more importance that the intention is > clear for as many people as possible, even if it is not 100% exact. > But perhaps there is a better way to express it both clear and > more precise. Probably. :-) > Cheers, > Andi Productive discussion is cool, isn't it? :-) -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > * Manoj Srivastava ([EMAIL PROTECTED]) [040325 00:25]: >> On Wed, 24 Mar 2004 21:07:27 +0100, Andreas Barth <[EMAIL PROTECTED]> >> said: >> >> > Ji, I'm not entirly happy with this proposal. One change is a large >> > change: Is all in Debian Software or not? This of course has impact >> > on the whole document, but is a seperate issue from the wording. > >> I think so. When you talk about computers/Operating systems, >> stuff is one of >> a) Software, >> b) Hardware, or >> c) Wetware. >> >> Everything on a Debian CD is software, and must meet the DFSG. > > Well, if everything is software, than there is no need to remove the > software of the different clauses. Clarity. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Raul Miller wrote: > On Wed, Mar 24, 2004 at 06:44:57PM -0500, Nathanael Nerode wrote: >> The current statement is: >> >> >> 1. Debian Will Remain 100% Free Software >> This states that everything in Debian is software, and futhermore that >> everything in Debian is free. > > :%s/and furthermore/and\/or/ No, trust me, we parsed this one very carefully and took an excessive amount of time on this in debian-legal. There are two possible interpretations, but both come out to an "and". -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Alternative editorial changes to the SC
Andreas Barth wrote: > Hi, > > I herby propose the following editorial changes to the SC, as > alternative to Andrews proposal: > > | 1. Debian Will Remain 100% Free Software > | > | We promise to keep the Debian system and all its components entirely OK, while we're proposing changes How about "...entirely free software. This includes programs, documentation, data, and any other works which are part of the Debian system (except possibly license texts which are distributed only for legal reasons). We provide the guidelines..." This would clarify the main point that has been spawning endless attempts by occasional maintainers to sneak non-free stuff into "main". > | free software. We provide the guidelines that we use to determine if > | a work is "free" in the document entitled "The Debian Free Software > | Guidelines" below. We will support our users who develop and run > | non-free software on Debian, but we will never make the system depend > | on an item of non-free software. > | > | 2. We Will Give Back To The Free Software Community > | > | When we create new components of the Debian system, we will license > | them as free software. We will make the best system we can, so that > | free works will be widely distributed and used. We will communicate > | bug fixes, improvements, user requests, etc. to the "upstream" authors > | of works included in our system. > | > | 3. We will not hide problems > | > | We will keep our entire bug report database open for public view at > | all times. Reports that people file online will immediately become > | visible to others. > | > | 4. Our priorities are our users and free software > | > | We will be guided by the needs of our users and the free software > | community. We will place their interests first in our priorities. We > | will support the needs of our users for operation in many different > | kinds of computing environments. We will not object to non-free works > | that are intended to be used on Debian systems, or attempt to charge a > | fee to people who create or use such works. We will allow others to > | create distributions containing both the Debian system and other > | works, without any fee from us. In furtherance of these goals, we will > | provide an integrated system of high-quality materials with no legal > | restrictions that would prevent such uses of the system. > | > | 5. Works that do not meet our free software standards > | > | We acknowledge that some of our users require the use of works that do > | not conform to the Debian Free Software Guidelines. We have created > | "contrib" and "non-free" areas in our archive for these works. The > | packages in these areas are not part of the Debian system, although > | they have been configured for use with Debian. We encourage CD > | manufacturers to read the licenses of the packages in these areas and > | determine if they can distribute the packages on their CDs. Thus, > | although non-free works are not a part of Debian, we support their use > | and provide infrastructure (such as our bug tracking system and > | mailing lists) for non-free packages. > > Changes to Andrews proposal: > 1.: More or less the current SC, with the second sentence replaced > with the first sentence of Andrews proposal and added the word "below" > to it. > 2.: More or less the current SC; only replaced the word "write" with > "create". > 3.: keep the word "immediately" instead of "promptly" (as this is, at > least in my opinion, easier to understand for non-native speakers). It means something different; "promptly" is as soon as is reasonable; "immediately" is *right this minute, before you go downstairs*. > 4.: Same as Andrews proposal > 5.: Same as Andrews proposal, except that in the last sentence the > words "for non-free packages" have been moved to the end to prevent > the mis-interpretation that the BTS is not free. > > > Cheers, > Andi -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > * Nathanael Nerode ([EMAIL PROTECTED]) [040325 00:55]: >> > Well, IMHO the old version is much nicer. The social contract _should_ >> > in my opinion have some nice, not too technical start. A promise is a >> > very good start, and I'd like to keep that there. >> You have a point. Andrew's version is clearer, but less stylish. How >> about this? > > Wouldn't it be good to have a stylish and clear text? In my opinion we Yes. :-) > shouldn't lose the stylish in trying to get a clearer text. (And, BTW, > we don't have any real hard problem with the current text. But - the > SC is more a "political" text then a real contract. Nobody could sue > Debian for not following the SC, but the SC is one important part of > Debians attractivity. > > >> > In the second sentence, I'd like to keep the word "below", as the DFSG >> > _are_ a part of the SC. >> Today's debate over matters of total insignificance: Are the DFSG part of >> the SC or are they a separate document? Why do people care, given that >> the same modification rules apply to both of them if they're separate, >> and the same importance is given to both of them? > > Why do people try to change this, if there is no need? Yeah. -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
Andreas Barth wrote: > * Nathanael Nerode ([EMAIL PROTECTED]) [040327 23:10]: >> How about "...entirely free software. This includes programs, >> documentation, data, and any other works which are part of the Debian >> system (except possibly license texts which are distributed only for >> legal >> reasons). We provide the guidelines..." > > The idea is definitly good. However, I'm not satisfied with the > wording and the place in the text. OK, me neither, really, but it's the best I've come up with at the moment. Hopefully others will provide better, more stylish solutions. :-) >> > 3.: keep the word "immediately" instead of "promptly" (as this is, at >> > least in my opinion, easier to understand for non-native speakers). > >> It means something different; "promptly" is as soon as is reasonable; >> "immediately" is *right this minute, before you go downstairs*. > > Well, I consider it of much more importance that the intention is > clear for as many people as possible, even if it is not 100% exact. > But perhaps there is a better way to express it both clear and > more precise. Probably. :-) > Cheers, > Andi Productive discussion is cool, isn't it? :-) -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > * Manoj Srivastava ([EMAIL PROTECTED]) [040325 00:25]: >> On Wed, 24 Mar 2004 21:07:27 +0100, Andreas Barth <[EMAIL PROTECTED]> >> said: >> >> > Ji, I'm not entirly happy with this proposal. One change is a large >> > change: Is all in Debian Software or not? This of course has impact >> > on the whole document, but is a seperate issue from the wording. > >> I think so. When you talk about computers/Operating systems, >> stuff is one of >> a) Software, >> b) Hardware, or >> c) Wetware. >> >> Everything on a Debian CD is software, and must meet the DFSG. > > Well, if everything is software, than there is no need to remove the > software of the different clauses. Clarity. -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Raul Miller wrote: > On Wed, Mar 24, 2004 at 06:44:57PM -0500, Nathanael Nerode wrote: >> The current statement is: >> >> >> 1. Debian Will Remain 100% Free Software >> This states that everything in Debian is software, and futhermore that >> everything in Debian is free. > > :%s/and furthermore/and\/or/ No, trust me, we parsed this one very carefully and took an excessive amount of time on this in debian-legal. There are two possible interpretations, but both come out to an "and". -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Alternative editorial changes to the SC
Andreas Barth wrote: > Hi, > > I herby propose the following editorial changes to the SC, as > alternative to Andrews proposal: > > | 1. Debian Will Remain 100% Free Software > | > | We promise to keep the Debian system and all its components entirely OK, while we're proposing changes How about "...entirely free software. This includes programs, documentation, data, and any other works which are part of the Debian system (except possibly license texts which are distributed only for legal reasons). We provide the guidelines..." This would clarify the main point that has been spawning endless attempts by occasional maintainers to sneak non-free stuff into "main". > | free software. We provide the guidelines that we use to determine if > | a work is "free" in the document entitled "The Debian Free Software > | Guidelines" below. We will support our users who develop and run > | non-free software on Debian, but we will never make the system depend > | on an item of non-free software. > | > | 2. We Will Give Back To The Free Software Community > | > | When we create new components of the Debian system, we will license > | them as free software. We will make the best system we can, so that > | free works will be widely distributed and used. We will communicate > | bug fixes, improvements, user requests, etc. to the "upstream" authors > | of works included in our system. > | > | 3. We will not hide problems > | > | We will keep our entire bug report database open for public view at > | all times. Reports that people file online will immediately become > | visible to others. > | > | 4. Our priorities are our users and free software > | > | We will be guided by the needs of our users and the free software > | community. We will place their interests first in our priorities. We > | will support the needs of our users for operation in many different > | kinds of computing environments. We will not object to non-free works > | that are intended to be used on Debian systems, or attempt to charge a > | fee to people who create or use such works. We will allow others to > | create distributions containing both the Debian system and other > | works, without any fee from us. In furtherance of these goals, we will > | provide an integrated system of high-quality materials with no legal > | restrictions that would prevent such uses of the system. > | > | 5. Works that do not meet our free software standards > | > | We acknowledge that some of our users require the use of works that do > | not conform to the Debian Free Software Guidelines. We have created > | "contrib" and "non-free" areas in our archive for these works. The > | packages in these areas are not part of the Debian system, although > | they have been configured for use with Debian. We encourage CD > | manufacturers to read the licenses of the packages in these areas and > | determine if they can distribute the packages on their CDs. Thus, > | although non-free works are not a part of Debian, we support their use > | and provide infrastructure (such as our bug tracking system and > | mailing lists) for non-free packages. > > Changes to Andrews proposal: > 1.: More or less the current SC, with the second sentence replaced > with the first sentence of Andrews proposal and added the word "below" > to it. > 2.: More or less the current SC; only replaced the word "write" with > "create". > 3.: keep the word "immediately" instead of "promptly" (as this is, at > least in my opinion, easier to understand for non-native speakers). It means something different; "promptly" is as soon as is reasonable; "immediately" is *right this minute, before you go downstairs*. > 4.: Same as Andrews proposal > 5.: Same as Andrews proposal, except that in the last sentence the > words "for non-free packages" have been moved to the end to prevent > the mis-interpretation that the BTS is not free. > > > Cheers, > Andi -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q: guidelines for post-campaign period?
Thomas Bushnell, BSG wrote: > Anthony Towns writes: > >> And? You are aware there are other countries in the world, right? You're >> also aware that "common" doesn't mean universal, and that whether it >> happens in 10% of cases or 90% doesn't make any difference to the point >> of my mail? If you're not sure whether to accept someone else's word >> that things happen differently elsewhere, at least take the time to have >> a quick look at google to see if such things are possible. Yeesh. > > I think it's pretty much common only in Australia. I think NZ is even more severe, actually. > I'm pretty sure > it's rare in Europe as well. I thought restrictions or bans on campaigning on the actual *day* of the election were fairly common in contintental Europe, actually. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > Ji, > > I'm not entirly happy with this proposal. One change is a large > change: Is all in Debian Software or not? This of course has impact on > the whole document, but is a seperate issue from the wording. This is, in Andrew's proposal, basically an issue of wording. (Admittedly, it's a separate issue from the *rest* of the wording, and it's a rather important piece of wording given the arguments it caused.) I'll take this opportunity to repeat the reason I call it a matter of wording. The current statement is: >> 1. Debian Will Remain 100% Free Software This states that everything in Debian is software, and futhermore that everything in Debian is free. >> 1. Debian will remain 100% free This states that everything in Debian is free. Software is a contested word; does it mean "programs", "programs and accompanying documentation", or "any stream of bits" (i.e. "not hardware")? The third definition is * the historically accurate one * what the writers of the Social Contract meant * the only one which allows packages such as anarchism to be in Debian * the only one which avoids the impossible problem of determining what's a "program" and what's not (since there are far too many things which are unclear, and even ASCII files are in some sense 'programs'). If you accept the third definition, then the only substantive change is that we allow for the possibility that at some time in the future the Debian distribution may contain hardware. (And why not?) Whether or not you accept the third definition, however, you still get to this same conclusion: everything is either (1) software, in which case it must satisfy the DFSG to be in Debian (2) not software, in which case it must be removed from Debian Either way, everything in Debian must satisfy the DFSG currently, and that doesn't change with Andrew's amendment; it just eliminates all the stupid arguments over the meaning of "software". Since it's all about a word, it's a matter of wording. Approximately the same analysis applies to every other place where "software" was removed; there are precisely the same requirements for things in Debian as there used to be. (Except that theoretically someone might somehow add free hardware to Debian.) Unfortunately, there have been a *lot* of these stupid arguments over the meaning of "software", and they've occasionally been used as an excuse for including non-DFSG-free works in "main". Or, on the other hand, for removing the King James Bible text from Debian. I would not be surprised if an alternative proposal was made to specifically *allow* non-DFSG-free works in Debian if they're not "programs". (I would find this very disappointing -- a betrayal of Debian's principles.) It would also be quite unsurprising to see a alternative proposal to declare explicitly that Debian will never contain anything but "programs". (This would be disappointing because so much useful DFSG-free stuff would be thrown out of Debian. These would also both be bad proposals because of the lack of clarity as to what is a 'program'.) Those are the alternative interpretations I've heard -- I think they're both definitely wrong, for the reasons given above, and most people who've listened to the reasons seem to agree (which is why there is debian-legal consensus on the issue), but they are alternative (wrong) interpretations. Codifying one of the interpretations -- one supported by a 3:1 supermajority of developers -- is the only way to prevent this particular class of flamewars from going on forever. That is, to put it simply, the "must-change" case for the amendment -- to stop these stupid arguments. >> We provide the guidelines that we use to determine if a work is "free" >> in the document entitled "The Debian Free Software Guidelines". We >> promise that the Debian system and all its components will be free >> according to these guidelines. We will support people who create or >> use both free and non-free works on Debian. We will never make the >> system require the use of a non-free component. > > Well, IMHO the old version is much nicer. The social contract _should_ > in my opinion have some nice, not too technical start. A promise is a > very good start, and I'd like to keep that there. You have a point. Andrew's version is clearer, but less stylish. How about this? We promise that the Debian system and all its components will be free; we provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. > In the second sentence, I'd like to keep the word "below", as the DFSG > _are_ a part of the SC. Today's debate over matters of total insignificance: Are the DFSG part of the SC or are they a separate document? Why do people care, given that the same modificatio
Re: Q: guidelines for post-campaign period?
Thomas Bushnell, BSG wrote: > Anthony Towns <[EMAIL PROTECTED]> writes: > >> And? You are aware there are other countries in the world, right? You're >> also aware that "common" doesn't mean universal, and that whether it >> happens in 10% of cases or 90% doesn't make any difference to the point >> of my mail? If you're not sure whether to accept someone else's word >> that things happen differently elsewhere, at least take the time to have >> a quick look at google to see if such things are possible. Yeesh. > > I think it's pretty much common only in Australia. I think NZ is even more severe, actually. > I'm pretty sure > it's rare in Europe as well. I thought restrictions or bans on campaigning on the actual *day* of the election were fairly common in contintental Europe, actually. -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR: Editorial amendments to the social contract
Andreas Barth wrote: > Ji, > > I'm not entirly happy with this proposal. One change is a large > change: Is all in Debian Software or not? This of course has impact on > the whole document, but is a seperate issue from the wording. This is, in Andrew's proposal, basically an issue of wording. (Admittedly, it's a separate issue from the *rest* of the wording, and it's a rather important piece of wording given the arguments it caused.) I'll take this opportunity to repeat the reason I call it a matter of wording. The current statement is: >> 1. Debian Will Remain 100% Free Software This states that everything in Debian is software, and futhermore that everything in Debian is free. >> 1. Debian will remain 100% free This states that everything in Debian is free. Software is a contested word; does it mean "programs", "programs and accompanying documentation", or "any stream of bits" (i.e. "not hardware")? The third definition is * the historically accurate one * what the writers of the Social Contract meant * the only one which allows packages such as anarchism to be in Debian * the only one which avoids the impossible problem of determining what's a "program" and what's not (since there are far too many things which are unclear, and even ASCII files are in some sense 'programs'). If you accept the third definition, then the only substantive change is that we allow for the possibility that at some time in the future the Debian distribution may contain hardware. (And why not?) Whether or not you accept the third definition, however, you still get to this same conclusion: everything is either (1) software, in which case it must satisfy the DFSG to be in Debian (2) not software, in which case it must be removed from Debian Either way, everything in Debian must satisfy the DFSG currently, and that doesn't change with Andrew's amendment; it just eliminates all the stupid arguments over the meaning of "software". Since it's all about a word, it's a matter of wording. Approximately the same analysis applies to every other place where "software" was removed; there are precisely the same requirements for things in Debian as there used to be. (Except that theoretically someone might somehow add free hardware to Debian.) Unfortunately, there have been a *lot* of these stupid arguments over the meaning of "software", and they've occasionally been used as an excuse for including non-DFSG-free works in "main". Or, on the other hand, for removing the King James Bible text from Debian. I would not be surprised if an alternative proposal was made to specifically *allow* non-DFSG-free works in Debian if they're not "programs". (I would find this very disappointing -- a betrayal of Debian's principles.) It would also be quite unsurprising to see a alternative proposal to declare explicitly that Debian will never contain anything but "programs". (This would be disappointing because so much useful DFSG-free stuff would be thrown out of Debian. These would also both be bad proposals because of the lack of clarity as to what is a 'program'.) Those are the alternative interpretations I've heard -- I think they're both definitely wrong, for the reasons given above, and most people who've listened to the reasons seem to agree (which is why there is debian-legal consensus on the issue), but they are alternative (wrong) interpretations. Codifying one of the interpretations -- one supported by a 3:1 supermajority of developers -- is the only way to prevent this particular class of flamewars from going on forever. That is, to put it simply, the "must-change" case for the amendment -- to stop these stupid arguments. >> We provide the guidelines that we use to determine if a work is "free" >> in the document entitled "The Debian Free Software Guidelines". We >> promise that the Debian system and all its components will be free >> according to these guidelines. We will support people who create or >> use both free and non-free works on Debian. We will never make the >> system require the use of a non-free component. > > Well, IMHO the old version is much nicer. The social contract _should_ > in my opinion have some nice, not too technical start. A promise is a > very good start, and I'd like to keep that there. You have a point. Andrew's version is clearer, but less stylish. How about this? We promise that the Debian system and all its components will be free; we provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. > In the second sentence, I'd like to keep the word "below", as the DFSG > _are_ a part of the SC. Today's debate over matters of total insignificance: Are the DFSG part of the SC or are they a separate document? Why do people care, given that the same modificatio
Re: Q: guidelines for post-campaign period?
Thomas Bushnell, BSG wrote: > Anthony Towns writes: > >> It's reasonably common in real life voting to limit campaigning in the >> days before the actual election. > > Huh? In this country it's certainly not. In the US, campaigning is prohibited within 50 feet of a polling place on election day, and no alcoholic beverages can be served on election day in most states. Those are very small limits compared to other countries, but they are intended as limits on abusive campaigining during the voting period. -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: Candidate questions/musings
Anthony Towns wrote: > No, a leader's not a dictator. Let's delve into this some more: I spent > a fair bit of time advocating what I thought was the appropriate course > of action on non-free. I prepared a resolution, and it even won the day. > For my involvement in this debate, I've been called a hypocrite [0], To be fair, I called a huge group of people hypocrites in that posting. To be fairer, that subthread *wasn't* about action on non-free (so it wasn't directly due to your involvement in *that* debate), it was about action on *main*. > [0] > [http://lists.debian.org/debian-vote/2004/debian-vote-200401/msg01914.html -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: Q: guidelines for post-campaign period?
Thomas Bushnell, BSG wrote: > Anthony Towns <[EMAIL PROTECTED]> writes: > >> It's reasonably common in real life voting to limit campaigning in the >> days before the actual election. > > Huh? In this country it's certainly not. In the US, campaigning is prohibited within 50 feet of a polling place on election day, and no alcoholic beverages can be served on election day in most states. Those are very small limits compared to other countries, but they are intended as limits on abusive campaigining during the voting period. -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
