Re: Summary : ocaml, QPL and the DFSG.
On Wed, Jul 21, 2004 at 09:19:51AM +1000, Matthew Palmer wrote:
> I think that this issue might be enough to get a change or two to the DFSG
> made. Compelled unrelated distribution and compelling the grant of a
> separate licence are both issues that I think need specific mention. The
> latter can probably be accomodated by a rewording of DFSG #3, but I think
> we're going to need a DFSG #11 for the former problem.
Compelling unrelated distribution is a restriction on modification and/or
distribution (depending on the license). That's certainly the usual
rationale connecting this problem to the DFSG. DFSG#1 says "may not restrict
any party from selling or giving away the software ..."; saying "in order to
distribute this, you must XXX" is a restriction.
Of course, XXX = "you must distribute source, too" is also a restriction.
Again, guidelines. (If the complaint is that these guidelines can't be
used without interaction with Debian and having the same result, then it's
just a complaint that they're guidelines--this can't be "fixed" without
turning it into something other than guidelines.)
I don't see what's special about this particular restriction that doesn't
apply to many other non-free restrictions as well. DFSG#1 and #3 could
certainly mention this case specifically, eg. "The license may not require
distribution to the original author as a condition for distribution", but
that would seem to imply that we also need to mention that requiring click-
wrap before distributing isn't free, requiring that modifications adhere to
some standard isn't free, and so on. (People are thinking up new ways to
restrict freedom all the time.)
(I don't really see a need for an entire new guideline, but it's the same
whether it's a new guideline or a part of other guidelines.)
In short, I don't see why this particular issue is special. It's one non-free
requirement among multitudes.
> > People seem very leery of trying to
> > update the DFSG, and it's not clear why.
>
> Several reasons that I've come up with:
>
> 1) A fuckup in wording could very easily see a lot of software thrown out or
> brought in.
>
> 2) The stability of the DFSG is a very major rock we stand on. As Sven
> Luther has mentioned, upstreams kind of rely on us not to go changing our
> minds every couple of weeks, and a change to the DFSG could see some pretty
> major upheavals.
>
> 3) To be thorough, after any DFSG change, we should check every package in
> the archive and throw anything out which doesn't comply with the new! shiny!
> DFSG. That's a lot of work.
>
> 4) Nobody's been real keen to do the work for it, considering that we've
> been quite happy in our little world.
5) See the recent GR, modifying the SC. It was editorial; it wasn't intended
to (and, in my opinion, did not) modify the meaning of the SC. It was
certainly much more minor than adding a new guideline--and it still kicked up
a huge amount of mud, resulting in another GR to put the changes on hold.
The reasons for the mud flinging aren't relevant; the point is that any
modifications to founding documents run a better than even chance of having
unintended consequences.
--
Glenn Maynard
Reply to: