On Wed, Jan 28, 2004 at 09:23:50PM -0800, Don Armstrong wrote:
> > nor does it make a lot of sense to treat licenses differently when
> > they cover a free work to when they're included in the package for
> > other reasons (namely, they benefit users of the package in some
> > way, such as serving as an example).
> There is a large difference between a valid license and a chunk of
> text that happens to look like a license.
Well, no, there's not: if it's the same text, it's the same text. You know,
by definition.
Having a license in a file other than /usr/share/doc/*/copyright doesn't
change much. Having a license included in a package as an example,
rather than because it covers some trivial little program doesn't change
much either.
> I can personally think of a
> few dozen reasons why it would be usefull to be able to modify a chunk
> of text that happens to look like a license,
Sure, there are lots of reasons why it's useful to be able to modify
licenses too: that's why lots of people like BSD licenses instead of
the GPL. Not everything that could be useful can reasonably be guaranteed
by the social contract.
> but there is no way that
> I can modify the meaning of a valid license and have it remain valid.
If you're the copyright holder, of course you can. In Australia there's
even case law that indicates you can probably do that without the
agreement or consent of whoever you gave the license to.
> I presume that your position[4] is that there are a class of works to
> which it is not important to apply the DFSG to in addition to the
> valid licenses and copyright statements.
No, it's not. My position is that we should do what's practical now,
and aim to do what's desirable as soon as it becomes practical. I don't
believe it's practical to remove non free documentation from main, and
I am absolutely certain it's impractical to remove non-free licenses from
main.
That's not to say that I think it wouldn't be a good idea to have both
classes of works be made available under DFSG-free terms -- in both
cases I do think that's valuable. But it's not crucial to do now, nor
is it particularly possible.
And I don't see much point making the decision on whether we move
non-free documentation out of main (and keep it out) as part of the
social contract rather than doing it in the usual way: deciding we want
to do it, and having the appropriate delegates and maintainers decide
how to work towards that.
Basically, there are two paths to having a main that's completely free:
remove everything that's not free, and have an operating system that's
even more flakey (byebye to the Debian logo, byebye to glibc and gcc
documentation, byebye to RFCs, byebye to apps without clearly DFSG-free
data, byebye to everything licensed under the GPL potentially); or you can
accept that there's no real need to do this immediately, and work with
upstream to ensure that stuff is licensed as freely as possible.
What makes more sense? Keeping stuff our users rely on and expect
available, having productive relationships with upstream and helping
improve their software, or blindly adhering to an ideal, brooking no
exceptions and ignoring any negative consequences?
> While I personally disagree
> with this, could you (or someone else who holds this view) give an
> accounting of how we should discern between works to which we should
> apply the DSFG and works to which we should not?
The current rules are that programs don't get into main unless they appear
to have DFSG-free licenses, and get removed from main if it turns out that
there are some non-DFSG-free terms in there, and upstream isn't willing
to change them. DFSG-free licenses are preferred for documentation and
other data in main, but as long as its distributable, it's more or less
up to the maintainer's discretion.
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