lkml.org 
[lkml]   [2007]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: GPL vs non-GPL device drivers
    I sympathize with you, VJ, I really do, but you're going to have to do
    a lot more homework in order to understand what is happening to Linux
    in embedded space. Allow me to supply some worthless, non-lawyer,
    non-measurable-kernel-contributor observations, which are at least
    quite different from those of most people who will bother to respond
    in this thread. Let's start with: Don't believe everything you read
    on the Internet. That goes double for press releases and public
    mailing lists.

    On 2/14/07, v j <vj.linux@gmail.com> wrote:
    > This is in reference to the following thread:
    >
    > http://lkml.org/lkml/2006/12/14/63
    >
    > I am not sure if this is ever addressed in LKML, but linux is _very_
    > popular in the embedded space. We (an embedded vendor) chose Linux 3
    > years back because of its lack of royalty model, robustness and
    > availability of infinite number of open-source tools.

    That's not why you chose Linux. You chose Linux because it made your
    lives easy in the short term and you didn't know or care what the
    long-term consequences would be. You didn't have to interact with any
    human beings, cut any deals, make any business case, obtain any
    executive approvals, sign any contracts, or forecast any per-seat,
    per-unit, or per-incident costs. You did have to put work into making
    it work for you, but you chalked your salaries up to "investment" in
    an "IP asset". Now you're finding out that the difference between a
    sunk cost and an asset is that an asset produces a revenue stream, and
    that few of the people who actually work on the mainline Linux kernel
    care whether or not your investment in building things with Linux
    inside will continue to produce revenues. Live and learn.

    > We recently decided to move to Linux 2.6 for our next product, mainly
    > because Linux has worked so well for us in the past, and we would like
    > to move up to keep up with the latest and greatest.

    Don't kid a kidder. 2.6 was the latest and greatest three years ago.
    Now it's the only game in town if you want anyone to talk to you
    without a cash retainer up front. Mind you, 2.4 still runs great on
    anything it ran great on back then; but nowadays the sort of
    application coders who work cheap are dead in the water without the
    (relatively) inexpensive threads of NPTL/TLS. Even the most un-hip
    and non-showing-up-at-the-table of chip vendors realize that their
    price/performance slides will look better under 2.6 unless they are
    really, really memory constrained. Sticking to 2.4 would require a
    business case for carrying your own maintenance weight, and we've
    already established that proactive analysis of business cases is not
    your enterprise's strong point.

    > However in moving to 2.6, we noticed a number of alarming things.
    > Porting drivers over from devfs to udev, though easy raised a number
    > of alarming issues. Driver's no longer could dynamically allocate
    > their MAJOR/MINOR numbers. Doing so would mean they would have to use
    > sysfs. However it seems that sysfs (and the class_ interface) is only
    > available to GPL modules. This is very concerning. The drivers which
    > we have written over the last three years are suddenly under threat.
    > We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
    > We can do this and modify our user space applications too.

    Given all the technical and cultural changes in the Linux ecosystem
    since you last checked in, it's kinda funny you picked on device
    numbering. Do you really expect your customers to combine your
    drivers with someone else's closed-source special sauce that happens
    to pick the same major number? Or if you're concerned about sharing a
    major with other devices in the same conceptual class, do you really
    think there's a legal risk in using a standardized, published,
    arm's-length interface to interchangeable drivers, no matter what the
    symbols are labeled? Ask your lawyer to interpret Lotus v. Borland
    and Lexmark v. Static Control for you, and to show you parallels to
    the law in other markets that are relevant to you. Then ask yourself
    whether you really want to be calling EXPORT_SYMBOL_MOVING_TARGET
    entrypoints from your out-of-tree drivers anyway.

    > However we have a worrying trend here. If at some point it becomes
    > illegal to load our modules into the linux kernel, then it is
    > unacceptable to us. We would have been better off choosing VxWorks or
    > OSE 3 years ago when we made an OS choice. The fact that Linux is
    > becoming more and more closed is very very alarming.

    Illegal, shmillegal. What's it's becoming is pointless, because all
    the kernel "features" that matter in a modern embedded system (bounded
    preemption latency, effective power management, reliable I/O
    peristalsis with predictable system impact) can't be localized to
    "core code". I can tell you from experience that they're next to
    impossible to achieve when there's a big opaque lump of binary driver
    stuck in the platform integrator's craw. Fans of EXPORT_SYMBOL_GPL
    may be perversely motivated, but they're telling you in advance what
    any customer worth having will tell you next year: if you're trying to
    sell components into the embedded market, closed drivers are more
    trouble than they're worth.

    Back on the topic of crusaders: There's a tried-and-true way to get
    people to care about your revenue stream: cut them in on it, in a
    currency they find valuable. This isn't a moral issue, except in the
    sense that all ethics is economics and vice versa. There are,
    however, some people involved in Linux kernel development who try to
    make a moral issue out of it and claim not to be willing to cut deals
    in mere dollars. (Maybe you just couldn't pay them enough to put up
    with whinging about erratic system behavior when you've invited a bull
    into the ring 0 china shop.) A few of these are such valued
    contributors that Linus lets them get away with silliness like
    EXPORT_SYMBOL_GPL, and that chums the water for the bigger sharks at
    the SFLC.

    So you've put yourselves in harm's way, to the extent that you have
    become dependent on the ignorance, indifference, or goodwill of people
    you've never met, who derive no value from the continued viability of
    your business. Notwithstanding the vitriol poured out in this thread,
    there's actually more goodwill to go around than you might think; but
    to make use of it you'll have to put on your asbestos skivvies and
    show up to the table. Whether that's worth doing is a business issue
    about which I can't advise you, since I'm no more a psychic than a
    lawyer.

    Legal niceties are not, however, what's actually going to bite you --
    unless you do something really stupid like Fortinet did (dissemble
    about the presence of Linux inside the box, which is probably what
    induced a Munich judge to overlook Harald Welte's dubious claim to
    "authorship" in a copyright sense). That kind of stunt could easily
    lead to criminal charges under 17 USC 506, and more to the point, it
    makes you look terminally dim as well as dishonest -- not good viral
    marketing. Also totally unnecessary if you just come clean about any
    changes to GPL code you make and distribute -- although "derivative
    work" is not really the right term for this, it's clearly something
    you don't have the legal authority to do without accepting the offer
    of contract in the GPL. But I'll come back to that.

    In all probability, what's going to eat your revenue stream hollow is
    not pseudo-legal sniping from the cheap seats but the predictable
    converse of the very virtues you cited:
    because those infinitely available free-as-in-speech tools are
    also free-as-in-beer, you've taken them for granted and barely learned
    how to use them or even tested whether the sharper ones work on your
    platform;
    Linux is robust except when it's not, for instance when the
    underlying hardware has subtle bugs that trigger in wonderful new ways
    as code and toolchains evolve; and
    that enticing royalty-free model means that no one owes you a damn
    thing in return, and there's no paymaster around to curb certain
    people's congenital hostility to freeloaders and suits generally.

    Ever noticed that the only thing worse than a salesman who's on
    commission is a salesman who isn't on commission? That goes double
    for kernel hackers. It's hard to find one who's genuinely competent,
    not just at refining his subsystem but at pushing a Linux-dependent
    product up the steep part of the quality curve. It's even harder to
    outbid Nokia and Google for him and then get him to work on your
    actual priorities beyond the initial, fun phase. And even then, he
    doesn't control the evolution of the Linux mainline, unless his name
    is Linus Torvalds. So you had better hope he's also a master
    strategist when it comes to "stabilization" (forking by any other
    name) for embedded applications, which is playing with fire but
    unavoidable in the Brave New World of 2.6.x.y.

    Now, I have already glossed a dozen points here in terms different
    from the other flamers', and will doubtless be torn to pieces by those
    who don't choose to ignore me entirely. Yet one gloss of a legal
    nature is worth emphasizing anyway (but remember, I don't even play a
    lawyer on TV.) The aside about Linus is not entirely a jest; he does,
    in fact, control the evolution of the Linux mainline and is the only
    candidate for "authorship" in a copyright sense, to the extent that
    "the Linux kernel" is a well-defined work of authorship. Aalmuhammed
    v. Lee is good law and has analogues in other important jurisdictions,
    notwithstanding Harald Welte's efforts to establish independent
    copyright in netfilter and initrd. Google "Linus Torvalds estoppel"
    (omit quotes) for some of the reasons why this matters, even if Linus
    chooses to downplay the legal significance of his unique role.

    However, getting a correct judgment in a court of fact is always a
    crapshoot, and I suppose it's conceivable that a judge would buy the
    "GPL is a dark continent" story long enough to issue a preliminary
    injunction. Judge Saris wasn't fooled (she gave Eben Moglen's
    affidavit the brush-off that it deserved and dismissed MySQL's GPL
    claim according to routine contract law standards), but the judge
    _you_ get might have different sympathies, especially if your
    established pattern of behavior makes look like a conniving greedhead
    or a freeloading scriptmonkey. Even so, odds are that it'll get fixed
    on appeal if you bother; but in the meantime there's a new batch of
    disingenuous chest-pounding press releases from the usual suspects
    with your name filled in the blank. Again, not good viral marketing.

    What's the bottom line? Free the software! It's not the law, it's
    just a good idea. Assuming, of course, that:
    you are selling your hardware at a positive gross margin, and can
    therefore afford for it to become more popular among end users (sadly,
    this does not go without saying);
    the information content of your software does not totally reveal
    your hardware's internals, or at least does not make them so
    blindingly obvious that it is cheaper for cloners in poor countries to
    reengineer it than to make a backdoor deal with your own contract
    manufacturers;
    there is not an authentic, bona fide Prince of Heck from a
    regulatory agency warning you not to make it too easy for hobbyists to
    Pump Up The (RF) Volume;
    there have been at least two reorgs since the decision was made to
    "invest" in an "IP asset", so the bodies are decently buried and you
    can unload your albatross without getting fired by an embarrassed
    suit; and
    you, personally, can plausibly claim that the code was even worse
    before it entered your hands, just in case it comes back to haunt you
    in a future job interview.

    HTH, HAND, Cheers,
    - 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-15 16:21    [W:5.205 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site