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 <[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
