On Thu, Jan 29, 2004 at 09:48:52PM -0800, Don Armstrong wrote:
> On Fri, 30 Jan 2004, Anthony Towns wrote:
> > On Thu, Jan 29, 2004 at 09:58:34AM -0800, Don Armstrong wrote:
> > > Neither does including a small little non-free utility in main for
> > > which we don't have source.
> > Sure it does: it means people who don't have non-free in their
> > sources.list can get at it, rather than only people who have main in
> > their sources.list.
> I'm lost here. Do you mean to say that it's perfectly ok for us to
> ignore the DFSG for small little non-free utilities in main?
No, not remotely. Not trimming so quickly might help.
Distributing stuff in main, and distributing stuff in non-free is a
signficant difference. main goes on our CDs, non-free doesn't. Stuff in
non-free is harder to get at that stuff in main, and is gotten at by
fewer people.
By contrast, having some text in /usr/share/doc/foo/copyright versus
having it in /usr/share/doc/foo/example-license.txt isn't a significant
difference.
It makes sense to worry about the former distinction -- putting stuff
in non-free causes problems for people, and to some extent the converse
is true too. It doesn't make sense to worry about the other distinction
though; at least as long as the FHS and so forth isn't being violated.
> 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.
If the license wasn't "relevant" in the first place, it wouldn't have
been in the package. But there are a few ways a license can be relevant
-- it can cover a program you're using, it can serve as an example text,
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. 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.
> > > Probably, but when it is a usefull act upon a work in main covered by
> > > the DFSG, it seemingly is guaranteed by the Social Contract.
> > Some people probably think it'd be useful if they could take the
> > Linux kernel in main, rip out a bunch of subsystems, then include it
> > in the next release of Windows. Unfortunately they can't, and we
> > certainly don't make any promises that they will be able to.
> 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. 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.
> > Then, again, that's not an issue: what is an issue is whether you
> > can take a valid license, modify it, and apply it to new works
> > legally.
> That's something that would be nice to have, and a necessary freedom
> for licenses that are included outside the context of enabling us to
> distribute a work of Free Software.
*sigh*
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.
> > Well, no, it's not. They have to read the license that comes with
> > any package that they want to modify. Of course, they should do that
> > anyway, since we've made mistakes before, and probably will again,
> > and don't offer any indemneties to protect them from problems caused
> > by our mistakes.
> I agree that users should read the licenses to a work before they
> modify the work, but 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.
I'm not sure what you think argument by assertion is meant to achieve, but
hey, if that's the rules, I can play too.
> 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.
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.
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