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 <aj@humbug.org.au> <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
Attachment:
signature.asc
Description: Digital signature