Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Al Viro <viro@ftp.linux.org.uk>]

On Sun, Jun 17, 2007 at 02:56:24AM -0300, Alexandre Oliva wrote:
> Can you please acknowledge that it doesn't, such that I can feel I've
> fulfilled my goal of dispelling the myth that the GPLv3 changes the
> spirit of the GPL?

No.  I don't do metaphysics.  This thread alone has shown that the
notion is not well-defined *at* *all*, to the point of being useless
and seriously misleading.  I.e. the phrase about similar spirit
should be replaced with something far more explicit and very, very
hard to miss.  I don't think you need more proof that people *do*
interpret it in very different ways, with quite unpleasant results.
 
> > GPLv3, with your involvement in its development or not, sucks rocks,
> > thanks to what you call anti-tivoization section.
> 
> Is it correct to say that you share Linus' opinion, that the only
> problem with the GPLv3 is the anti-tivoization provision?

No.  If you want a basic splitup by sections compared to GPLv2,
	1	-	at least not better; attempts at being precise
			end up creating a no-common-sense-land *and*
			turn out to leave serious unanswered questions
			in that area.
	2	-	no opinion on actual changes
	3	-	more or less an improvement
	4,5	-	about on par with v2, modulo wording in (5)
	6	-	much worse
	7	-	if I want to give additional permissions, I don't
			want them stripped, for fsck sake!  There is a
			bog-standard mechanism for _that_ (dual-licensing),
			thank you very much.  I.e. that section looks like				a pile of dishonest PR games, pardon the redundance.
	8	-	on par
	9	-	on par, modulo piss-poor attempt to define "modify"
			backfiring here (e.g. prelinking constitutes
			modification according to it, so does running rdev(8),
			etc., etc.)
	10	-	no opinion on actual changes
	11	-	improvement
	12	-	on par (aside of basic bad writing, but there are
			much worse problems *not* with wording, so that's
			not interesting)
	13	-	special-case kludges are fun, aren't they (specifically
			"linking"?), but in any case, that's secondary.
			FWIW, I'm not fond of ideas behind Affero, so if
			anything, that's a point against v3.
	14	-	... and thank you very much for keeping such a lovely
			source of periodic clusterfucks in v3 as well.
			I think it's painfully obvious for everyone in this
			thread that reference to "spirit" is a recipe for
			massive disagreements down the road.  If you want the
			words you are using to be interpreted your way, use
			ones that have commonly agreed upon meaning.  The
			measure is "do other people read it differently?",
			not "how sure I am in deriving the meaning I want from
			the words I've used?".  Related problem is that
			version choice rules _must_ be stated in maximally
			unambiguous and hard to miss way.  Look through
			Bernd-produced parts of this thread and you'll see
			the reason why it is needed.
			Moving that into terms and conditions is a good step,
			but it's still not enough.  E.g. you really want
			to be explicit on the form (in)sufficient to specify
			the version of license.
	the rest	on par.

Overall: definitely worse than v2.  v2 + (3) + (11) would be an improvement,
provided that v2 section 9 is cleaned up.

> To make this more concrete, if there was a hypothetical GPLv2.9,
> consisting of GPLv3dd4 minus the "installation information"
> requirements for user products, (i) Would you consider it a better
> license than GPLv2?
	Negative, see above
 (ii) Better for Linux?
	Negative, for kernel as well as for userland
(iii) Enough to go through the trouble of switching?
	See above.

In other words, I don't see any chance for v3 to be a good choice
for anything I write, kernel or userland.  If I end up sending patches
to v3 projects, I'll put the patches under BSDL and let them convert
on merge.

Note that this is *not* about the problems with wording; those also exist,
of course (_that_ is a final draft?), but that's a separate story and it
interests me only inasmuch as it is caused by inherent problems with meaning
of section in question.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/