lkml.org 
[lkml]   [2007]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
    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/

    \
     
     \ /
      Last update: 2007-06-19 00:19    [W:3.698 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site