Letters to the editor

Re: Open-Source Fight Flares at Pentagon (Washington Post)

 
Eric Smith writes:
 
> I'm not trying to suggest that the Defense Department and NSA should not
> conduct security testing of free software, but merely that procurement
> regulations are a complete non-issue for it.
 
Not only should the NSA conduct security testing of free software, but
they already *have*, resulting in their own approved, security enhanced
version of Linux:
 
        http://www.nsa.gov/selinux/
 
Perfect for all US governmental use, one would have thought...
 
Tet

Comments (none posted)

Keeping OSS out of the security arena

>From http://www.internetnews.com/dev-news/article.php/1276831
 
> while ADTI believes pooled talent is highly beneficial in software
> development, it is naive to allow "bad guys" as well as "good guys"
> into that talent pool.
 
Oh, sure... and who gets to define `good' and `bad'?
 
OSS can be contributed to and inspected by the poorest computer owners in the
world, but even benevolent engineering and infotech societies have membership
dues which well exceed the cost of owning and operating such a computer, so
membership in same as a criterion basically equates `bad' with `poor'.
 
Microsoft's traditional definition seems in practice to be `good' equals us
and `bad' equals competitors, that is, _everyone_ else. I can't see those
criteria being well recieved by the public, although based on past practice I
would expect them to be carefully and professionally marketed in various ways
by Microsoft. The same basic approach is shared by many political and
religious groups too, which would also render a broad range of social
criteria inappropriate.
 
When you've bashed your collective heads against that particular wall often
enough, consider the axiomatic approach, `if it works, don't fix it'. In real
life, OSS _has_proven_ to be more secure than competing methods, and without
controls. To be honest, one must say `competing method', singular.
 
To effectively put a brake on OSS adoption by pausing for study when much
study has already been done seems to be the biggest and most pressing
security risk in this situation.
 
AdTI's own mission statement* includes `Our principles guide the selection of
which issues are critical to the advancement of freedom - but we don't rush
to judgement about which means will be most effective in producing it.'
Excellent! But AdTI seem to be `rushing to judgement' here, unless AdTI uses
an odd definition for `freedom'.
 
If AdTI's sponsors wish to compete in a market which prefers OSS, by choice
or mandate, they need but Open Source their own products, noting that the GPL
requires source to be available for distribution as _only_ far as the
binaries are, _not_ to the public at large.
 
Cheers; Leon
 
 
* a pasteable text version would be nice
 
--
CyberKnights Modern tools, traditional dedication.
+61-409-655-359 http://www.cyberknights.com.au/
 
linux.conf.au 2003 The Australian Linux Technical Conference
http://conf.linux.org.au/ 22-25 January 2003 in Perth, Western Australia

Comments (none posted)

Re: [riptide-announce] New riptide-0.3mbsibeta02061100 linux driver available

Marc Boucher wrote to discuss@linmodems.org:
> I am pleased to announce the first public open-source release of the
> Conexant (Rockwell) RipTide Audio/Communication Controller driver for
> Linux.
>
> It is now available for download from
>
> http://www.mbsi.ca/cnxtlindrv
 
Dear Marc,
 
Isn't that a misleading use of the term "open-source"?
 
818k of it is a proprietary, binary-only module. Users may not study or
modify or recompile the interesting bulk of the driver code, even though
it is plainly software which runs on the x86 CPU.
 
- Users cannot study the code, to simply learn from it.
 
- It only runs on x86 versions of Linux. It doesn't run on non-x86
  hardware, and cannot be ported by anyone other than Conexent.
 
- Most of the code cannot be audited for security or correctness, any more
  than other binary code.
 
- You even appear to have obfuscated the binary, to scramble symbolic
  information that might be useful for reverse engineering or security
  analysis.
 
In other words, the benefits of open source apply only to a very small
portion of the driver, and the caveats of closed source apply to the
rest.
 
It is a useful driver, for users prepared to run binary-only software
(with the caveats regarding freedom, security and reliability that
implies).
 
But to announce it as open source without mentioning that it is really
closed-source, binary-only software in an open-source wrapper is, IMHO,
marketing - not true by any stretch of the imagination.
 
Yours sincerely,
-- Jamie Lokier

Comments (none posted)

PostgreSQL not relational!

        Re: http://lwn.net/Articles/809/
 
 > Our archive of security alerts dating back to July, 2001 now lives in
 > a PostgreSQL relational database.
 
        As argued in http://dbdebunk.com/ and elsewhere, SQL is not relational.
  Also, so-called object/relational DBMSs are even further away from the
relational model than SQL ones, and aren't even DBMSs proper, but
DBMS-construction kits.
 
        This is not a trivial matter, as SQL not being relational keeps it from
fulfilling the possibilities of the model, which would fulfill all the
requirements for which OODBMSs are built.
 
 
--
  _
/ \ Leandro Guimarães Faria Corsetti Dutra +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/ fax +41 (21) 216 19 04
  X http://tutoriald.sf.net./ Orange Communications CH
/ \ ASCII Ribbon Campaign against HTML email +41 (21) 216 15 93

Comments (none posted)

Your LWN articles

 
You write:
 
> Describing the GNU system as "utilities" is quite an understatement.
> GNU is not a set of utilities--GNU is an operating system. The
> GNU/Linux system is pretty much the same as GNU, but not entirely
> the same, because it has Linux in it too.
 
> I appreciate Torvalds' contribution to the GNU/Linux system. I
> credit Torvalds (not hypothetical gods) for this work, and that's
> one reason I mention his contribution in the name of the operating
> system.
 
> I also appreciate that Torvalds' kernel would have mattered little
> for computer users' freedom, if not for the fact that we had already
> produced most of a free operating system for it to fit in. Giving
> him equal mention is more than fair.
 
The hypocritical thing about this is that you don't apply the
standards you demand from others to yourself.
 
A working GNU system requires a collection of basically Free Software
from a host of different sources. For example, most of the networking
stuff is typically taken from BSD, the windowing environments are
from X11, and so forth and so on. Some counts have indicated that
about a third of the identifiable portions from a GNU system are
actually GPLed, and only a small ratio of those are part of the GNU
project proper.
 
You feel you are entitled to call the resulting system "GNU" because
the GNU project had a vision of an entirely free system and
concentrated on providing those pieces of infrastructure that could
not freely be adopted from other free sources.
 
But exactly the same was done by Torvalds, other Linux developers and
distribution maintainers: they also took a look at what was available
and concentrated on providing those pieces of infrastructure that was
still missing in order to obtain a complete system meeting their
demands. At the time they were doing this, there was no such thing
as a complete GNU system.
 
While you consider it outrageous that those putting a complete system
together might not name it the way you would have named a similar
(but quite different system) had you completed work on it before that
time, you feel quite satisfied assuming that all of the various
contributors to such a system should be entirely happy to have their
individual work subsumed unter the "GNU" title, even if it had never
been intended as part of the GNU project.
 
The components of a GNU system are all intended as meaningful parts of
a complete system, but not necessarily as part of a particular system:
they are more versatile than that, and fit a lot of environments.
 
Now let us hypothetically assume that a GNU system actually consisted
to a majority from parts done specifically by and for the GNU project.
If an artist has in the creation of a work used only paints from a
particular manufacturer, does that mean that the resulting work is
that from the paint manufacturer, and that the paint manufacturer
should be able to choose the name? Hardly.
 
A situation may be conceivable where several paints would produced
particularly for a certain work, with particular pigments in it, and
given the artist freely. Would that make the title of the work
something to be chosen by the manufacturer? Hardly, unless the
manufacturer explicitly contracted for those paints, or commissioned
the entire work. Even in that case, an interference like this would
be generally considered distasteful since it interferes with one of
the basic artistic freedoms. And was not freedom something this was
all about?
 
This is the main problem with your naming crusade: even disregarding
the discrepancy between your demands for credit and your recognition
for that of others, and disregarding any discussions about your moral
or legal or whatever rights to it, the main problem is that it appears
distasteful. The amount of animosity and alienation you collect with
that stance vastly exceeds any possible gains in recognition you could
expect.
 
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

Comments (none posted)

Re: Your LWN articles

In your letter, you summarized our reasons for the name GNU/Linux
thus:
 
    You feel you are entitled to call the resulting system "GNU" because
    the GNU project had a vision of an entirely free system and
    concentrated on providing those pieces of infrastructure that could
    not freely be adopted from other free sources.
 
In that description you have carefully selected a part of what we say.
It fits what we did, but it it omits something important: we launched
the system's development, and did largest part of the work. The only
usable pieces of free software available when we started were TeX and
Bison, and Bison needed substantial extensions to serve the purpose.
During the 80s, as we were working on GNU, additional usable pieces of
free software occasionally became available, but we had to write a
large part of the system ourselves.
 
    But exactly the same was done by Torvalds, other Linux developers and
    distribution maintainers:
 
You've designed your description very precisely so that it can fit a
series of cases that are rather different. For instance, it fits what
we did, doing the bulk of the work of developing the GNU operating
system; it fits what Linus Torvalds did, writing a program that filled
the main gap in an almost complete operating system; it fits what what
GNU/Linux distribution maintainers such as Red Hat did, polishing and
extending a basically working system (alas, often extending it with
non-free software).
 
Despite your success in crafting a description that fits this range of
cases, they are not similar cases. Many others have also contributed
to the system, but we're the system's principal developer.
 
On another issue, you assert that our request for people to call the
system GNU/Linux "appears distasteful" and does more harm than good
for the GNU Project. In my experience, people usually react favorably
and it does more good than harm. It is mainly people who deny the
validity of this request that find it distasteful. Typically they
deny its validity because they underestimate our role in the
community's history, and for that very reason, they are less likely to
cooperate with us anyway. We ought not to be worried about what they
will think. This campaign appears to making slow but steady headway
in correcting people's picture of the system's origin.

Comments (none posted)

Response to Mr. Brown's critique of Open Source Software.

[Note: this response was written on June 10th, from a paper that Mr. Brown
apparently found fit to withdraw after initial publication. The URL that
the paper had previously been found at
(http://www.adti.net/html_files/defense/opensource_whitepaper.pdf)
stated, "The White Paper will be available by the close of business, June
10, 2002." Being as it is now after 8:00 p.m. EST, and the paper is still
not in evidence, I will not wait any longer to see if Mr. Brown has
changed his initial paper.]
 
Every now and then, you hear about or read something that forces you to
look at things in a new light, to marvel at the goings-on of the Universe.
 
The paper, "Opening the Open Source Debate," written by Kenneth Brown,
president of the Alexis de Tocqueville Institute, fails utterly and
entirely to accomplish this.
 
Regardless of the stance that one takes on a given issue, it is always
enjoyable to find a well-reasoned, objective treatment of said issue,
allowing the reader to consider previously un-thought-of venues and
realize new insights. However, this "paper," with a clear, very
subjective stance, does nothing except embarrass anyone who takes it
seriously. From the quirky use of English, to the figures cut out of
whole cloth, one has to wonder what possessed Mr. Brown to sit down and
put pen to paper.
 
An example of the questionable figures that Mr. Brown uses is this: "In
the U.S., the software sector accounted for approximately 319 million jobs
in 2001." Software has clearly taken off when it employs more people than
live in the country. If it were merely a typo, it might be forgiven, but
he then refers to his appendix, where the same figure resides, with
further reference to www.bls.gov/ces/home.htm#data, where the most I can
find is some 2.2 million, or slightly under 1% of the country's gross
population. While I admit I'm not certain of my figure in relevance to
whatever Mr. Brown thought he was quoting, at least I'm not presenting
something that is clearly incorrect.
 
If this were the only mistake, I would be tempted to let Mr. Brown off
fairly lightly. However, that is only the beginning. While he may term
his paper a "debate," one usually has to prop up premises with facts in a
debate; Mr. Brown showed no reluctance in avoiding this restriction.
I will start from the beginning, so that the interested reader may follow
along:
 
Brown: "Executable software accompanies binary code..."
Truth: Executable software -is- binary code; the two are one
       and the same, at least withing the bounds of the arguments
       that are being put forth.
 
Brown: "Open Software is not necessarily free software."
Truth: This is akin to saying "Water is free, usually." It's
       such an open-ended statement that it begs further
       qualification, not free-ranging pot-shots.
 
Brown: The entire section labelled, "GPL Open Source -- The
       Gift that Keeps Taking".
Truth: Aside from the fact that the heading, itself, proves that
       Mr. Brown has no interest in objectivity, the section is
       so full of mis-representations and accusations, with nary
       a shred of supporting evidence, as to make one cringe.
       First, he attempts to show that the Gnu Public License
       (the "GPL") is overly restrictive... and proves it by showing
       how open it is. Then, having failed in this endeavor, he
       decides that character assassination is not below him, and
       takes aim at Richard M. Stallman. "The controversial nature
       of Stallman's position began to turn away his supporters.
       [...] The rise in the popularity of Linus Torvalds and the
       Linux open source operating system began to create new
       supporters. Ironically, Linux supporters became the biggest
       proponents of the GPL." Clearly, Mr. Brown uses a different
       definition for the word "ironically" than do most. Linux
       supporters became proponents of the GPL not because they
       like Linux, but because the like the GPL. If anything, one
       could argue that they like Linux because of the GPL, and
       not the other way around.
 
Brown: Another section, entitled "The Myth of a 'Public Software'
       Community".
Truth: First and foremost, the heading implies a thesis to follow,
       and then supporting argument. This is entirely untrue. I
       don't know what point Mr. Brown tries to make in the argument
       (perhaps that federal dollars can act as a catalyst in the
       private sector? I'm really unsure.), but he fails across the
       board to address anything, much less prove anything.
 
Brown: In the single attempt Mr. Brown makes to find an alternative
       viewpoint, he quotes Rossz Vamos-Wentworth, "Security holes
       are eventually found, with or without open source code."
Truth: The security world holds to two viewpoints, neither of which
       is entirely conclusive. The truth lies somewhare in the
       middle. The viewpoint that the paper puts forth is that, if
       you can read the source code, it makes it all the easier to find
       security holes. Ironically, this is also the opposing camp's
       viewpoint; they, however, would append "and then fix them" to
       the sentence. The problem with closed-source software is that
       you generally find out it's insecure in one of two different
       ways: when the manufacturer decides to let you know, or when you
       get cracked.
 
Brown: A whole paragraph with a slew of questions. I will reproduce
       them here in their entirety: "Issues include: Who should have
       the right to alter software manuals? Who is the final editor
       or is there one? How should changes be regulated? Are manuals
       copyright protected documents? What is the process for making
       changes? What body regulates these changes? How can organizations
       guarantee that information in manuals is always accurate?"
Truth: WITHOUT EXCEPTION, every single one of the above questions can
       be applied -- in some cases, moreso -- to the private sector.
       The mere fact that Mr. Brown bothers to ask these seemingly
       rhetorical questions to bolster his position speaks plainly of
       how little he knows about the basic functioning of a real-world
       software or hardware company. I know one very competent end-user
       who spent TWO DAYS attempting to get a router to work properly.
       Why was he unable to? Because the manual, from one of the largest
       network equipment manufacturers, left out a two-word command.
       In other words, the entire paragraph should apply, in my
       considered opinion, to the software community at large. The
       only documents that I consider to have good editorship and
       version control, for the most part, are those by large,
       non-proprietary organizations such as the IEEE and the RFCs,
       describing open protocols, that are the white papers upon which
       the Internet is based.
 
Brown: "It becomes unrealistic for a firm to depend too much on the
       'trust'of an anonymous community..."
Truth: When an electrical engineer designs a "widget," one thing he
       tries very hard to avoid is "single sourcing" a component.
       In other words, the engineer goes to great lengths to make
       sure that no given component can only be obtained from a
       single vendor. The reason for this is that, were the vendor
       to go under, or change its structure, or simply cease to
       produce the component, suddenly the engineer's company would,
       at a minimum, have to spend time and resources to redesign
       their widget, and in a worst-case scenario, would be forced
       to halt its production entirely. This is -exactly- the case
       with closed-source software. Far better to have a loose-knit
       community that is, and always will be, able to assist you
       than one commercial entity that could fail tomorrow. Just
       ask users of Wang word processors how much trouble they had
       getting their information onto a more... well, "open" platform.
       Furthermore, on top of the community, itself, there are also
       a wide range of Open Source vendors (eg. Red Hat,
       http://www.redhat.com) that offer service and support contracts,
       and have under their employ some of the stars of the Open Source
       community. Ask yourself: when you have competing vendors offering
       support, do you get better service than when you're locked in? I
       clearly don't need to bother answering that rhetorical question.
 
Brown: "While each of these firms would insist that they are not against
       copyright protection, invoking the protections argues that they
       are against people copying their marketing documents and symbols."
Truth: While I'm sure the preceding sentence is supposed to prove some
       purported point, the fact that it's an oxymoron makes it difficult.
       Okay, apologies: it's not an oxymoron, it's an "identity:" he just
       restated the same thing, when he was attempting to contrast
       something. Mr. Brown should clearly leave abstract thinking for
       others.
 
Brown: "The purchase price of computer software is only a fraction of the
       total cost of ownership ["TCO"]. So even if the price tag reads
       "free", it can end up being more expensive than software you buy.
       This is especially true for the typical consumer. If it requires
       technical know-how to operate, doesn't offer built-in support, and
       demands constant attention, it won't feel free for very long."
Truth: All this is very well and good... but it leaves out the fact that
       the "average consumer" doesn't know how to fix a broken Windows
       box, either. Once something goes wrong with proprietary software,
       more likely than not, the answer is "re-install." This doesn't
       strike me as a cost-beneficent solution, especially when time to
       re-configure the system is involved. On the other hand, most
       computers with Linux installed on them only have to get re-booted
       when the machine has to be powered off to install new hardware.
       Contrast this with re-booting to install, say, a USB driver for
       a camera. And, if support is needed, it's actually -easier-
       for people to remote-administer an Open Software machine than
       a closed one; so long as you trust the remote operator, they
       can likely fix you without having to lug your machine to Comp USA.
 
Brown: "If a software application representing 5000 hours uses GPL code
       that reflects only 100 hours, is the GPL fair in its argument that
       the entire product is GPL?"
Truth: This may be the least insightful argument Mr. Brown has used thus
       far. Clearly, if only 100 hours' additional work would be required,
       and the author wished for the software to remain proprietary, then
       he would put in the 2% extra work himself. NOBODY forces ANYONE
       to use GPL code; rather, it is there as a resource. If you choose
       to use it, knowing full-well the ramifications, then, yes, the
       license is applicable. Otherwise, you don't. As opposed to
       closed source, at least you have a choice.
 
The rest of the paper meanders on; there are some other issues regarding
legal precedence in which Mr. Brown, to be blunt, makes me wonder whether
he is ignorant, or intentionally deceitful. ("There are unlimited
scenarios for accidents to occur, the license could be lost in the source
code's distribution, or maybe unreadable due to a glitch in its electronic
distribution." Do you eat candy you find, unwrapped, lying in the street?
No. And neither should a software firm; instead, any firm worth its charter
practices due diligence and is very careful of licensing, regardless of
whether it's open or closed. Common sense is clearly not one of Mr. Brown's
strong points.)
 
In his conclusion, I find it ironic that he names IBM as spending billions
on development, and wondering if Open Source would put their development
at risk. The reason I find this ironic is that IBM has put around a
billion dollars into Linux, itself, only to find it reaping great rewards
as it is able to make use of Linux's synergy, letting them minimize
in-house development costs, and allowing the lowering of their systems'
TCO, and, therefore, raising their margins and allowing them to compete
more proactively in the marketplace.
 
Or perhaps Mr. Brown is against competition, period.
 
Sincerely,
 
Ken D'Ambrosio
Merrimack, NH
 

Comments (none posted)