On Thu, Jan 29, 2004 at 09:58:34AM -0800, Don Armstrong wrote:
> On Thu, 29 Jan 2004, Anthony Towns wrote:
> > On Wed, Jan 28, 2004 at 09:23:50PM -0800, Don Armstrong wrote:
> > > 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.
> The text might be the same, but one is a valid license, and the other
> is just text.
Well, no: in both cases it's a valid license. In one case it's possible
you don't have anything covered by the license, though. But hey, that's
possible even if the text is in /usr/share/doc/*/copyright, and you just
rm everything else that was in the .deb.
> > 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.
> 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.
By contrast, deciding whether to put a piece of text in
/usr/share/doc/*/copyright or /usr/share/doc/*/free-patent-license.txt
isn't really a big deal to anyone. If it'd normally go in the latter
location, but Debian forbids it, then it's trivial to include some stupid
little utility that's covered under the license, then move it into the
copyright file instead, and reference it there. The same people have access
to it; the same text is on the same systems.
> > Not everything that could be useful can reasonably be guaranteed by
> > the social contract.
> 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.
> > > 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.
> Hopefully it's obvious that I am refering to a case where I am not the
> copyright holder.
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.
You wouldn't claim that apache was non-free because you can't make
modifications that affect random other sites that use it to serve their
websites; why do you think you need the right to modify licenses so
they affect random other programs that make use of them, rather than
just your own?
> > 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.
> I would imagine that making the decision as part of the SC would be
> equivalent to "deciding we want to do it".
No, that's making the decision that we will do it now, and damn the
consequences. Deciding we'll do something is one thing, working out how
we'll do it is another. If we decide something is violating the social
contract, though, we only have one choice in what to do: whichever one
fixes the violation in the least amount of time.
> > 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?
> There are negative consequences to both courses of action.
There often are. That's not an excuse to avoid the question, however.
> I would hope that most proponents of removing non DFSG free works from
> main are well aware of the consequences.
I'm not sure why you think it's a matter of "removing non-DFSG-free
works from main". I'm a proponent of that too. The issue is how we do it,
and over what timeframe, not whether we do it at all.
> > 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.
> The problem with this tack is that it is very difficult for our end
> users to know what works in main they can exercise their rights
> preserved by the DFSG upon, and which works in main they cannot.
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.
> That being said, I'm still interested in an answer to the original
> question: How do I dicern between works to which I apply the DFSG and
> works to which I do not?[1]
Are you just trying to be a pompous twit and demonstrate how much
holier-than-thou you are, or would you like to rephrase your question
so that it's obvious how my answer didn't address whatever it is you're
apparently actually asking?
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