On Fri, Jan 30, 2004 at 12:37:03AM -0800, Don Armstrong wrote: > 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.
Uh, the reason you might want to use a non-DFSG free program doesn't matter; it goes in non-free. I'm saying the reason you might want to use non-DFSG-free license text shouldn't much matter either. Want it to cover some software? Fine. Want it to be an example? Fine. Want to include it in your info documentation? Fine. > > 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? Why? I don't think the social contract is being violated as is. > > 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... I've completely forgotten what we were discussing here now. > > 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? I've no idea what revised Social Contract you're talking about. Odds on I don't support it, so I don't have to reconcile it :) > 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. I don't think we should be making amendments to the social contract to deal with trivialities like how we put license texts in packages in main. > > > 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. I don't believe we have anything in main that people are likely to automatically violate the license (by burning it on a CD, or mirroring it, or installing it for a company, or whatever). There's plenty of ways of violating free licenses when modifying things though -- consider if you remove the GPL announcement that gdb displays when you start it up, eg. So I don't think their interests are significantly affected. > 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] > 2: The examples included in libc.info documentation, for example, are > quite clearly source, yet the work itself is (apparently) considered > documentation. Uh, no, they're examples, included as part of some documentation. I'm not sure why you find that confusing. (And the issue isn't source v documentation, it's programs v documentation. Documentation can have its own source, obviously enough.) > Either way, who should be making this distinction between source and > documentation? People who're able to, obviously... </ObShot> > 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? The social contract isn't something that should be modified regularly. Never would be the ideal. > > 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, Well, no. The Debian system doesn't include non-free. Personally, I think an operating systems needs to be documented almost as much as it needs to boot; if it isn't or doesn't, we've failed in a far more substantial way than if we have some imperfectly free stuff in it, like, say the preamble to the GPL, or one of RMS's manifestos. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004
signature.asc
Description: Digital signature
