lkml.org 
[lkml]   [2007]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: GPL vs non-GPL device drivers
    This screed is the last that I am going to pollute LKML with, at least
    for a while. I'll write again if and when I have source code to
    contribute, and if my off-topic vitriol renders my technical
    contributions (if and when) unwelcome, I'll understand. FSF
    skulduggery is not very relevant to the _engineering_ of the kernel,
    but it is (or ought to be) relevant to people's beliefs about whether
    EXPORT_SYMBOL_GPL is the right thing to do.

    On 2/17/07, Trent Waddington <trent.waddington@gmail.com> wrote:
    > On 2/18/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
    > > If you can
    > > read that and still tolerate the stench of the FSF's argument that
    > > linking against readline means they 0wn your source code, you have a
    > > stronger stomach than I.
    >
    > Such a strange attitude.. to go to all this effort to quote carefully
    > and correctly one set of people and to then total misconstrue the
    > words of another.

    Dammit, the world at large has been far too nice to these people for
    far too long. There's no sin in people getting rich and/or famous,
    but how they did it deserves some scrutiny. The FSF is leading
    thousands of idealistic young people all over the world up the garden
    path by bullshitting about the nature of US law, and if Moglen at
    least isn't making bank doing it, it isn't for lack of trying. For
    starters, read http://lists.debian.org/debian-legal/2005/07/msg00531.html
    (another self-reference that doesn't need flowing in). Google around
    for his letters of opinion (not pro bono, I assure you) to Fluendo and
    Vidomi. How do they smell to you?

    The GPL is big money, folks; the FSF General Counsel's designing "GPL
    circumvention" schemes for other people's software -- and estopping
    away his ability to contest them in court, one letter of opinion (and
    one hefty lump-sum fee) at a time -- isn't a tenth of it. Ask the
    OSDL, who (I am very sorry to report) funneled $4M of certain hardware
    makers' money to the SFLC to bankroll the expansion of Moglen's
    protection racket. Yes, protection racket. What other phrase could
    possibly describe the Software Freedom Conservancy?

    Speaking of protection rackets, how about Moglen's plaintive comments,
    back in the day, to the effect of (not a direct quote): "The
    conditions of the GPL can't touch Red Hat's new trademark policy,
    subscription agreement, and ISV support lock-ins because they aren't
    about copyright. The GPL, as we all know, is a creature of copyright
    law. Even though the GPL says plainly, 'You must cause any work that
    you distribute or publish, that in whole or in part contains or is
    derived from the Program or any part thereof, to be licensed as a
    whole at no charge to all third parties under the terms of this
    License', that can't possibly be taken as an 'entire agreement'
    clause, because the GPL isn't an offer of contract. Don't like having
    to pay per seat for RHEL? Sorry, we can't help you."

    This would be the same Red Hat that bought Cygnus Solutions in 1999 at
    an estimated price of 674 MILLION dollars (in stock, of course). That
    made some individual Cygnus stockholders rich; see
    http://www.salon.com/tech/feature/1999/11/18/red_hat/print.html. Want
    to bet Moglen held a Cygnus share or two, along with (via the FSF)
    control over all the source code Cygnus had ever produced? How does
    it smell now?

    There's yet more money in the toolchain oligopoly that Moglen and
    Redmond tacitly share, and in embedded targets generally. (Have you
    ever asked yourself how the XCode and Tornado IDEs happened? Have you
    ever tried to obtain their source code? Now do you understand why the
    FSF fetishizes the fork/exec boundary?) Redmond is not the FSF's
    enemy; the phantom menace called "software patents" is, because they
    protect other software makers from the FSF's volunteer army of reverse
    engineers. All those crocodile tears over TiVo, just because they
    forked GCC, put the lower layers of MPEG into silicon, and wrote their
    own damn DRM in RTL, instead of toeing Moglen's line on "give me naked
    ripped media or give me death". (No, I don't have first-hand
    knowledge of any of these dealings; do your own research if you want
    the sordid details.)

    The FSF doesn't bother with kernels. The HURD (nee Alix) is RMS's pet
    project, and there are some charming young fellows who truly believe
    it's going to win time trials and cure cancer someday, but I doubt
    anyone in the know ever put cash money into it. Some kernels are
    better than others but once they work they're pretty interchangeable
    for desktop and low-grade network server workloads. They do, however,
    take more engineering skill than the world's most prolific cloner of
    other people's interfaces (RMS, in case that isn't blindingly obvious)
    has ever been able to muster. (RMS's skill exceeds mine, or used to;
    but not by the light-years that Linus's, or even Theo's, does.)

    However, the FSF is very careful not to let kernel authors' peanut
    butter into _their_ chocolate, because the money is in supporting
    toolchains for _proprietary_ kernels (VxWorks, anyone? Darwin?
    whatever the iPod is running?). Someday they're going to screw Linus,
    and all of us, over big-time with artful text in LGPL v3. Have you
    ever done the gcc / glibc / kernel-headers dance? Has it ever
    occurred to you to wonder what's going to happen when gcc's and
    glibc's licenses are no longer "compatible" with the v2-only kernel?
    (Thank God and Linus the kernel is v2-only; see
    http://lists.debian.org/debian-legal/2005/05/msg00122.html, again a
    self-reference.) Do /usr/include, libc.so.6, and libstdc++ become
    "undistributable"? How are you going to like being forced to fork the
    entire GNU corpus in whatever state it's in the day before the v3
    conversion hits SVN? Xorg is going to look like a cakewalk by
    comparison.

    > The FSF's argument in regards to readline is that you may not
    > distribute readline with proprietary software linked to it. They
    > don't claim they "0wn" your source code.

    Let us deconstruct the most polished and redacted variant I can find
    of Stallman's readline saga, found at
    http://www.oreilly.com/catalog/opensources/book/stallman.html:

    <RMS>
    The GNU Library GPL

    The GNU C library uses a special kind of copyleft called the GNU
    Library General Public License (LPGL), which gives permission to link
    proprietary software with the library. Why make this exception?

    It is not a matter of principle; there is no principle that says
    proprietary software products are entitled to include our code. (Why
    contribute to a project predicated on refusing to share with us?)
    Using the LGPL for the C library, or for any library, is a matter of
    strategy.

    The C library does a generic job; every proprietary system or compiler
    comes with a C library. Therefore, to make our C library available
    only to free software would not have given free software any
    advantage--it would only have discouraged use of our library.

    One system is an exception to this: on the GNU system (and this
    includes GNU/Linux), the GNU C library is the only C library. So the
    distribution terms of the GNU C library determine whether it is
    possible to compile a proprietary program for the GNU system. There is
    no ethical reason to allow proprietary applications on the GNU system,
    but strategically it seems that disallowing them would do more to
    discourage use of the GNU system than to encourage development of free
    applications.

    That is why using the Library GPL is a good strategy for the C
    library. For other libraries, the strategic decision needs to be
    considered on a case-by-case basis. When a library does a special job
    that can help write certain kinds of programs, then releasing it under
    the GPL, limiting it to free programs only, is a way of helping other
    free software developers, giving them an advantage against proprietary
    software.

    Consider GNU Readline, a library that was developed to provide
    command-line editing for BASH. Readline is released under the ordinary
    GNU GPL, not the Library GPL. This probably does reduce the amount
    Readline is used, but that is no loss for us. Meanwhile, at least one
    useful application has been made free software specifically so it
    could use Readline, and that is a real gain for the community.

    Proprietary software developers have the advantages money provides;
    free software developers need to make advantages for each other. I
    hope some day we will have a large collection of GPL-covered libraries
    that have no parallel available to proprietary software, providing
    useful modules to serve as building blocks in new free software, and
    adding up to a major advantage for further free software development.
    </RMS>

    On second thought, let's not deconstruct this. It's too much work,
    and it's a waste of time. Because if you can't read "anything other
    people wrote is fair game, but what we write is sacred; our strategy
    is to cajole when we can and strong-arm when we can't, and the law be
    damned" into that, no amount of verbiage from me is going to change
    your mind.

    I will end with something I wrote to debian-legal a year and a half
    ago. A pretty decent guy said it constituted "character
    assassination" and "destroys my credibility". It distresses me that
    he should have reacted that way, and it distresses me that chastising
    me for "misconstruing" the FSF's attitude and public statements should
    take precedence in your mind over assessing the evidence I bring to
    bear on the legal issues at hand. Distresses, but does not surprise;
    they've gotten away with it on sheer holier-than-thou effrontery for
    almost twenty years now, and that seems unlikely to change until
    someone with deep pockets grows the cojones to challenge them in court
    with a winnable fact pattern.

    <me, back then, exasperated>
    > Let me try again. Eben Moglen has a J. D. from Yale. He has been
    > admitted to the bar in New York and before the Supreme Court. He has
    > clerked in district court and for Justice Thurgood Marshall. He has
    > held a professorship of law and legal history at Columbia for over a
    > decade. He is not ignorant of the law. It is my opinion that he
    > knows damn well that there is no such thing as "copyright-based
    > license" and never has been.
    >
    > It's very useful as a propaganda device to make it appear that there
    > is some rich vein of unmined law in this area, and therefore some
    > difficulty in applying the mountain of case law relevant to any given
    > fact pattern involving the GPL. But the truth as I see it (and I am
    > not alone) is that the GPL is a somewhat unconventionally drafted but
    > otherwise completely routine contract of adhesion. If this is in fact
    > the truth, then many of the things that he, and other attorneys
    > closely associated with the FSF, say in public about the GPL are
    > untrue, perhaps even deliberately misleading. That doesn't inspire my
    > respect.
    </me, now, no less exasperated>

    - Michael
    -
    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-02-18 07:59    [W:2.421 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site