Letters to the editor

InfiniBand

I just read the coverage of Greg K-H's concerns about the InfiniBand
licensing in last week's kernel section (which just became freely
available).  As one of the main developers of free InfiniBand
software, there are a few things I wanted to clarify.

First, we just got rid of the dumb new $9500 charge for the spec (and
will retroactively refund anyone who actually paid that amount).

There seem to be two objections raised in your article.  First is the
restrictive language used for non-member access to the specification.
Since pretty much every company on the IBTA steering committee is
actively involved in the OpenIB effort, we should be able to get that
sort of issue resolved soon as well.  In the meantime, everyone
working on the code is affiliated with an IBTA member company, which
means we received our copies of the spec without any such
restrictions.

The second objection that was raised was about patent licensing.
However, sadly enough, the IBTA patent terms are pretty much par for
the course.  For example, the PCI SIG has nearly word-for-word the
same patent licensing terms (see below), but we don't see anyone
asking for the removal of drivers/pci or saying, "the end result is
that PCI looks like a closed, proprietary standard, and not something
which can be supported in free software."

In any case, no matter what the IBTA member agreement patent language
is, the fact remains that there are far more patent holders who are
not members than IBTA members (most notably Microsoft, who are no
longer IBTA members).

Since I don't think anyone benefits from a high profile news source
like LWN spreading what is essentially FUD, I would appreciate it if
you could publish some clarification.

Thanks,
  Roland

Here's a snippet of the PCI SIG bylaws
(http://www.pcisig.com/membership/about_us/bylaws/):

    SECTION 15.3 LICENSING OF MEMBER INTELLECTUAL PROPERTY RIGHTS

    When the Member or its Affiliate makes a Contribution to a
    Specification of the Corporation, including revisions thereto, or
    when the Corporation adopts and approves for release a
    Specification after providing notice as set forth in Section 15.2,
    above, the Member and its Affiliates hereby agree to grant to
    other Members and their Affiliates under reasonable terms and
    conditions that are demonstrably free of any unfair
    discrimination, a nonexclusive, nontransferable, worldwide license
    under its Necessary Claims to allow such Members to make, have
    made, use, import, offer to sell, lease and sell and otherwise
    distribute Compliant Portions, ....

    SECTION 15.5 RETENTION OF RIGHTS

    Nothing contained in this ARTICLE 15 shall be deemed as requiring
    a Member or its Affiliates to grant or withhold a nonexclusive
    license or sublicense of an individual Member's patents containing
    Necessary Claims to non-Members on such terms as the Member or its
    Affiliates may determine.

Pretty much identical to the IB language, eh?

For good measure here's a similar snippet of the Bluetooth SIG patent
and copyright license agreement
(https://www.bluetooth.org/foundry/sitecontent/document/Pa...):

    5. License Grant.

    (a) To Associate or Adopter Member. Effective upon the adoption by
    Bluetooth SIG of each Bluetooth Specification, the Promoter Members
    and their Affiliates hereby grant to each Associate and Adopter Member
    and its Affiliates (collectively, Licensee ) a non-exclusive,
    royalty-free, perpetual, irrevocable, nontransferable,
    nonsublicenseable, worldwide license under the Promoter Member s
    Necessary Claims with respect to the Bluetooth Specification and/or
    Foundation Specification solely to make, have made, use, import, offer
    to sell, sell and otherwise distribute and dispose of Compliant
    Portions; provided that such license need not extend to any part or
    function of a product in which a Compliant Portion is incorporated
    that is not itself part of the Compliant Portion.

Comments (none posted)

Kernel development

Dear LWN

Kernel development should serve, very broadly, three classes of user:
private users, corporate users and kernel developers, and it is
important that the needs of all three are met. Recently the needs of the
middle group have not been met.

Since version 1.0, over ten years ago, kernel versions have followed the
elegant and simple scheme whereby odd point releases are development
kernels and even point releases are stable kernels. The 2.6 kernel has had,
and continues to have, major subsystems completely rewritten, not in the
interests of bug fixing, but in the interests of development. That the old
kernel development model had shortcomings in the eyes of the developers I
accept, but the current model has shortcomings in the eyes of corporate
users. I currently maintain around 25 servers in a lights-out environment:
were I to install 2.6 on them, which version of 2.6 should I consider to be
"stable"?

For corporate users, the 2.4 series is stable. The only changes now are
genuine bug fixes or porting for new hardware (eg, SATA disks). The 2.6
series has some features which are attractive to corporates (eg, built-in
VPN), but few will risk installing such a rapidly-changing kernel on a
24x7 server.

A development methodology that serves all three classes of user is
required. Forking a development "odd-dot-zero" release near-simultaneously
with the release of the production "even-dot-zero" version worked well for
almost ten years. Should we return to that scheme?

Best regards,

Keith Edmunds
http://www.TheLinuxConsultancy.co.uk

Comments (6 posted)

IE vs. other web browser security

While it is disappointing that so much software fall over with bad HTML, at
least it *only* falls over. If you use IE then there are lots of ways of
installing, and running, arbitary code on your computer if you just visit a web
page, or preview HTML email in some cases. About 3 came in the same week
bugtraq reported the browser reliability results.

Banner ads on CNN et al for less than wholesome websites, and worms, have been
known to apply these techniques. Most of the IE exploits use hair-brained ideas
that only IE supports, and nobody else supported because of the obvious
security implications.

My conclusition is that despite the relaibility result IE is the least secure
browser around because of hair-brained design. Bugs can be fixed but hair
brained design is unfixable. What you exoect from an outfit that has *earned*
the assumption that their software is insecure until proved otherwise?

-- 
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."

Comments (1 posted)

With regards your analysis on Open Source sustaiability

Dear sir,

I am sure, by now, you have received numerous e-mails
on your article in the Financial Times. However, I
feel I may be able to make some points that others may
have missed on the issues you have raised.

First you state that, in Open Source, the source code
must be available to all. Actually, this is not
entirely correct. There are three popular Open Source
licenses - the GPL, the LGPL and a license modelled
after the Berkeley UNIX license known as the BSD
license.

The GPL states that you are required to make the
source code available to those whom you make the
binaries available. Thus, if the program is used
internally within an organization, it is only required
that the source be available to those people. No
distribution beyond that scope is required. Each of
those users can modify the source and distribute it
themselves, but there is nothing in the license that
entitles such users to expand the scope of
distribution. The GPL prohibits a reduction in rights,
but that is all.

The LGPL is similar to the GPL, except that only the
common public code needs to be distributed. If you
have proprietary extensions, or have proprietary
applications which make use of LGPL code, no
distribution of the source for those extensions or
applications is required.

The BSD license takes a different approach.
Redistribution is permitted, but not required. Anyone
can make proprietary modifications to the common
source code and sell binary-only versions based on
those modifications. The common pool of knowledge is
treated no differently than the contents of a public
library, in that anyone can go in and read the
contents, but what they do with that information is
entirely their own business.

Now we move onto the interpretation of the GPL, when
GPLed works are included in other works. The GPL
allows for "fair use", in that you have to incorporate
more than a trivial element of a GPLed work into
another work before the GPL applies. It must actually
be intrinsically embedded, not merely linked. The GPL
prohibits non-trivial inclusion of GPL code in a
non-GPL/LGPL work, but it does permit non-trivial
interactions between GPLed and non-GPLed code. (This
is why non-GPLed drivers are perfectly valid and
legal, when loaded into the Linux kernel, even though
the Linux kernel is GPLed. The kind of linking
involved is not considered to be covered by the GPL.)

But what remedies are permitted, if someone violates
this? You incorrectly say that the GPL offers none. In
fact, the GPL states that the GPL is the only license
an individual or organization has to distribute the
code and that violations of the GPL result in a
nullification in that license for that individual or
organization.

In other words, including GPLed code in a non-GPL
product, or vice versa, in such a way as to produce a
new work (not merely two distinct works combined) that
is distributed under terms that violate the GPL
results in a revocation of the permission to
distribute the GPLed code. The distributor is still
entitled to do what they like with their own code,
including selling it as a proprietary binary. Their
work is theirs and is not covered by the remedy. The
sole restriction is that they may not include the
GPLed code as part of their distribution.

The scenario of A creating a derivative work that is
covered by the GPL, and then B using it without prior
knowledge of it being GPL, is a violation of the GPL
by A. The GPL clearly states that GPLed source code
clearly declares itself as such and that the license
be included. If B is genuinely not aware of the
license (because proper copyright notices are not
included and/or the license is absent), then A has
violated the GPL. Since violating the GPL voids all
rights to distribute the code, B would likely be
entitled to damages against A in proportion to the
damage against B's business interests.

However, it must be noted that this applies only to
the GPL and (within certain limitations) the LGPL. The
BSD license freely allows BSD code to be used in
proprietary products and distributed in binary-only
form, without restriction. Indeed, Microsoft already
uses BSD code within Microsoft Windows - the TCP/IP
driver is a direct derivative of the standard BSD
TCP/IP driver. There have been no complaints over
this, because it was this kind of re-use of BSD code
in commercial products that the license writers had in
mind.

The next issue raised is who owns the capital. What
happens when a member of the "Open Source" workforce
leaves? This argument is based on the fallacy that the
source code (and therefore the value of that code) is
centrally owned. The author of a book will continue to
receive royalties for that book, long after they
retire. Indeed, they will continue to do so for
between fifty to senenty-five years after their death
(depending on their country of origin). Membership of
some publishing commune is not required to claim that
income.

Where, though, is the income from Open Source? The
GPL, LGPL and BSD licenses all permit sale and resale
with no restrictions or limitations, so physical
income certainly exists. Far more often, though, such
source code has indirect value. A person gains no
royalties from redistribution of their PhD thesis, but
individuals with PhDs frequently have higher earning
power than those without.

We see much the same thing with certification
programs. It actually costs money to be certified, but
again it has indirect value, in that a certified
individual will often have far greater earning power
and have a far greater range of opportunties.

How does this apply to Open Source? Well, if Linus
Torvalds were to apply for a job in computer
programming tomorrow, he is very likely to be
considered eligable - and of considerable interest -
for just about any position he should choose to apply
for. His name would attract media attention and
potential sponsorship, in much the same way as a
celebrity sports player does for whatever team they
play for.

The combination of proven talent (eg: the Linux
kernel) and endorsement value would give him
considerable value to any company. Precisely because
any company would rather such value came to it, rather
than a competitor, companies would likely pay him
extremely well to ensure his continued affinity.

Finally, I will briefly mention why the economic model
of Open Source is viable, sustainable and scalable.
Economics defines the "Closed Source" model as a Nash
Equilibrium.

(DEFINITION: Nash Equilibrium If there is a set of
strategies with the property that no player can
benefit by changing her strategy while the other
players keep their strategies unchanged, then that set
of strategies and the corresponding payoffs constitute
the Nash Equilibrium.)

Closed Source is a Nash Equilibrium, because the
computer industry prefers stability and consistancy.
This is why Microsoft has retained compatibility with
DOS applications, even though DOS is over 30 years
old, and why Apple - which does try to change
strategies, as technology shifts - has failed to
benefit.

Indeed, it is a proven fact, in computing, that
changing strategy leads directly to failure, whilst
retaining a working strategy is the only way to
profit. This is the requirement and definition of a
Nash Equilibrium, and therefore this is the best model
for such a market.

However, Professor Nash's work goes further than to
describe the stagnant scenario. His work on the
non-zero-sum scenario - where personal greed is NOT
the motivating force, and where cooperation rather
than competition drives the market. In such a
scenario, the sum total of profit is non-zero. A
company does not earn by taking from another. There
may be no interaction at all, or two or more companies
may work for the positive benefit of the group.

Open Source is the non-zero-sum scenario. Personal
gain is certainly permitted, and even encouraged
within certain constraints, but there is a net
guarantee that the profit of one is not at the expense
of another.

The non-zero-sum model is provably superior to the
zero-sum case and, therefore, in a free market must
inevitably supplant it. Economics theory shows the
results, and shows why they must eventually occur. In
the years since Professor Nash's work, there has been
little to contradict his conclusions. In the years
since Open Source has hit the scene, there has been
little to contradict the assessment that it conforms
to the non-zero-sum scenario.

In conclusion, whilst it is certainly meritous to
raise difficult issues with Open Source and ensure
that those issues are properly addressed and tackled,
it is not useful to consider Open Source vs. Closed
Source. Closed Source is simply not a sustainable
model, if in pure competition with Open Source.
Because Open Source forces the market into a
cooperative, non-zero-sum environment, either the two
will cooperate and co-exist, or Closed Source will die
off.

It is very right to debate, but to be beneficial, it
must be the right debate.

Jonathan Day

Comments (7 posted)