On Fri, 30 Jan 2004, Anthony Towns wrote: > On Thu, Jan 29, 2004 at 09:48:52PM -0800, Don Armstrong wrote: > > Sure, but the license has now been made relevant in the context of > > distributing the "stupid little utility" instead of just being a > > chunk of license like text. > > But there are a few ways a license can be relevant it can inform you > about things worked historically, it can be a default to cover > things that you're publishing using software covered under another > license, or something else.
Sure, as can non-DFSG free source... but we generally hold that the relevance of such a work isn't enough for it to be included in main. > Requiring maintainers to include some irrelevant thing that's > covered under the license just to distribute it for some other > purpose is pointlessly bureaucratic and stupid. Then may I suggest that a supporter of this argument propose a Social Contract amendment that specifically excluding licences like text from needing to satisfy the DFSG? > > I hope we'll agree that such a useful (heh) act isn't covered by > > the DFSG. > > Err, weren't we talking about works covered by the DFSG not acts? > That's how I read your comment. Ugh. Sorry if that wasn't clear. Yes, I'm refering to DFSG protected or enabled actions upon works in main. > I don't know that it's really meaningful to talk about acts covered > by the DFSG. "Enabled" might work, though. But then the "useful" > distinction doesn't matter, which I think was the point I was > making. The "useful" was there to indicate that someone could plausibly want to take the action... > It'd be a useful freedom to have. But it's more useful to have for > licenses that are useful enough to cover works we want to > distribute, though; which means discriminating against licenses that > don't need the freedom as urgently is non-sensical. How can this position be reconciled with the revised Social Contract? While I can understand allowing licenses which are mentioned specifically by a valid copyright statement of a work in Debian being allowed,[1] I don't see how we can allow works that happen to look like licenses (which are not mentioned specifically by a valid copryight) to not be governed by the SC as proposed by Andrew. If a significant number of Developers feel that the former doesn't follow logically, then I would imagine that an amendment could be made to specifically allow it. [Hopefully it's clear that we wouldn't have a distribution if we were unable to distribute the GPL itself.] > > in cases where we know that a work is not licensed in a manner > > that is DFSG Free, failing to move the work out of main (or taking > > steps to have the work relicensed appropriately) is not acting in > > the best interest of our users. > > Well, no, in general that's not the case. It's at least not acting in the best interest of a subset of users who happen to fall afoul of the license terms with are incompatible with the DFSG. > > If we decide that there is a class of works to which the DFSG does > > not apply, how do we tell the difference between them? For > > example, if we decide that documentation (or ...) does not have to > > follow the DFSG, we need to be able to tell the difference between > > documentation (or ...) and things that are not documentation (or > > not ...). > > It's generally pretty obvious, and that's why we have people to make > the distinction, not programs. I'm not sure why you think it's > difficult to tell the difference between documentation and programs > in 99% of the cases, or why you think the difficulty in the > remaining 1% of cases represents any sort of insurmountable > difficulty. Heck, running file(1) on the damn thing will give you > that sort of precision. Perhaps, but the few bits of non-DFSG Free documentation and data that we have in main actually cross the border between source and documentation.[2] Either way, who should be making this distinction between source and documentation? Furthermore, if this really is the viewpoint of a significant number of Debian Developers, perhaps Developers with this viewpoint should propose it as an amendment to the Social Contract and define a separate set of DFSG analogues to cover documentation? > If you're asking what the properties of documentation are that make > it worthwhile to treat them differently, that's simple: there's not > enough DFSG-free documentation that's packaged to serve our needs > for documenting the Debian system. Hopefully that won't last for > very long. That may be an appropriate argument to keep them packaged in non-free, but it doesn't follow that they should be given a free ride in main. (I personally don't have much of a problem, for the time being, with GFDLed documentation being left in main while we work with the FSF to effect a change in the GFDL... but I've argued strongly against keeping non-free documentation whose upstream isn't at least discussing licensing it appropriately.) Don Armstrong 1: I personally don't understand why licenses like the GPL need to be specifically protected from modification. While I'm aware of the FSF's arguments on this issue, I would as soon see them modifiable. 2: The examples included in libc.info documentation, for example, are quite clearly source, yet the work itself is (apparently) considered documentation. -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu
signature.asc
Description: Digital signature
