The State of Your Taxes
Dear DDJ,
I was curious about the Kansas source code "shield law" Jonathan Erickson discussed in his "Editorial" (DDJ, June 2001) with respect to property tax determination. Does it also extend to shielding the business rules, logic, and algorithm used to determine the property tax? I would think they could not hold back the algorithm since tax computation is generally within the public's right to know. I could see them shielding the actual source code, but not the rules.
In California, anyone can petition for access to any code developed for the state and each agency has the right to refuse. We got into a goofy situation where we had built a successful interface to one of the state's nastier legacy systems, then our competitors attempted to requisition the code.
Even stranger, all bids that are part of a competitive procurement become property of the state and can be requisitioned by anyone. I have had the successful bidder on a project my company lost requisition my proposal with full rights to use the material within and no recourse for my company. As a courtesy, the agencies allow the vendors in this situation to prepare an edited version that is distributed. But what this creates is the situation where the winning vendor can see all solutions and pick and choose to improve their design. No, I am not making this up.
The knotholes that most states make vendors go through both before, during, and after the project, as well as win or lose, used to make me crazy until I realized that is their intent. And, curiously, there is a counterplay — not to go crazy — that can have interesting results.
Barr Bauer
Jonathan responds: Thanks for your note, Barr. To answer your question, the Kansas state officials I talked to were adamant in not releasing any information regarding the business rules, logic, and algorithms used to determine property taxes. Also, from what I can tell, there is no "shield law" per se in Kansas; it is simply bureaucrats — not elected officials — making up the rules as they go along.
Embedded Space
Dear DDJ,
I just read Ed Nisley's column in the July 2001 issue of DDJ and have a few comments. I really liked the fact that his column pointed out the need for real-time systems to be designed with a "system" view in mind. All too often, hardware and software (firmware) are considered separately (and fingers pointed back and forth). But, as Ed points out, the system must be designed as a whole to meet real-time requirements.
He mentions that it would be an interesting exercise to reproduce his old Logic Analyzer using a modern SOC. I did something similar a few years back, creating a PC-based (parallel port) logic analyzer using a small CPLD (see the cover of Electronics Now, March 1998) to perform the real-time functions; the kit is used in many college labs. With a modern programmable SOC, almost everything, even limited RAM, could fit on one chip, [and] the PC is replaced by the on-chip micro and an LCD display.
One programmable SOC that looks pretty interesting that Ed did not mention is Atmel's FPSLIC. It contains an FPGA and an AVR microcontroller. The AVR is a nice step up from 8051s and PICs in terms of its architecture (works well with C) and the FPGA has free RAM for use as FIFO and buffers. It still looks a bit pricey now — but if the price comes down, it could take off. Thanks for an interesting column!
Bob Brown
More Open Source versus Free Software
Dear DDJ,
I am sure Jonathan Erickson doesn't realize how ironic it is to associate me and Tim O'Reilly with "open source" in the June 2001 issue of DDJ.
If the House UnAmerican Activities Committee [HUAC] asked me, "Are you now or have you ever been a supporter of the open-source movement?" I could proudly and cheerfully say "no." I've been campaigning since 1984 for free software — free as in freedom (see "The GNU Manifesto," DDJ, September 1985).
Free software means, roughly, that you are free to study what it does, free to change it, free to redistribute it, and free to publish improved versions (see http://www.gnu.org/philosophy/free-sw.html for more details). You deserve these freedoms; everyone deserves them. I wrote the GNU General Public License (GNU GPL), the target of Microsoft's greatest ire, to defend these freedoms for all users, in the spirit of the free software movement.
Years later, in 1998, another group began operating under the term "open source." They have contributed to the free software community in practical ways, but they stand for very different views. They studiously avoid the issues of freedom and principle that we raise in the free software movement; they cite only short-term practical benefits as the reasons for what they do.
Their stated definition for the term "open source" is somewhat broader than free software, and thus includes my work. But describing the GNU GPL as an "open source license," as Microsoft did, is more than half misleading. The GNU GPL embodies the firm philosophy of the free software movement; it doesn't come from the open source movement. I am not a supporter of the open source movement, and never have been.
Tim O'Reilly, by contrast, is a pillar of the open source movement, at least to hear him tell it. However, if you look at actions rather than words, most of the manuals published by O'Reilly & Associates do not qualify as open source — let alone as free. The handful of free titles are exceptions. He could easily excuse himself to HUAC — "Yes, I talked about open source, but I didn't really do much of it."
If Tim moves to selling "free" as in freedom books in the future, he could become a true supporter of the free software movement, or at least the open source movement.
With the recent founding of FSF-Europe, and the coming inauguration of FSF-India, the free software movement is going stronger than ever. Please don't lump us in with the other movement in our community.
Richard Stallman
Shared Source?
Dear DDJ,
Having read Al Stevens's article on the problems he experienced installing Linux ("A Moving Target," DDJ April 2001), it struck me that instead of splitting up Microsoft, Judge Jackson could order them to publish the source code for Windows 2000. The success of various existing open-source projects (MySQL, PHP, Linux, and so on) leads me to think that making Windows 2000 open source could give us a free, stable, easily installed, secure operating system. It would give all companies that write software (including web browsers) for Windows a level playing field. Microsoft would become just another Windows application provider, with a range of products including Office and Internet Explorer. (They might even have time to fix the bugs in Visual C++ and make it conform to the C++ Standard!) Netscape would be able to integrate Navigator into the operating system to exactly the same degree as Microsoft could with Internet Explorer.
Mike Pentney
CORBA Interoperability
Dear DDJ,
I'd like to compliment Eric Ironside, Letha Etzkorn, and David Zajac for their excellent article "Examining CORBA Interoperability" (DDJ, June 2001). I would like to add my own $0.02 to the discussion because I've used one of the libraries (ACE/TAO) in a production context. The native exception handling on the platforms that we used (namely Red Hat 6.1 and Linux Mandrake 7.0/7.1) seems to be totally functional (with no apparent issues) with the NT version of the ORB--so long as you select to compile for native exceptions when you build ACE and TAO. I know this to be the case because there is a system in place at Dallas-Fort Worth (Texas) International Airport that runs the embedded side of the system under Linux and the transaction processing side under NT--exception processing is used to flag issues on both sides of the system and it works rather well using "native" exceptions. We didn't want to rework the NT version of the code to use the "exception" macros supplied by ACE and TAO and we wanted to do proper exception processing to handle all error conditions and failure modes. So we spent a day rebuilding the Linux version of the network layer code (ACE) and the ORB (TAO) to support native GCC exception handling. [It] worked right straight out of the box with no issues from then on out.
The main reason, according to the ACE/TAO install documentation, that exception processing is not turned on under the Linux side is that GCC seems to make rather largish binaries when you use true exception processing. Without native exception processing, TAO seems to only be able to deal well with other builds of TAO similarly configured. I suspect that the problems the authors mentioned about exceptions [are] because of the ORB being configured to not use native exceptions by default because they describe the problems we encountered in the early stages of the Linux embedded lane controller for PassKey.
One "compatibility" caveat seems to have been missed by the authors that I feel should be mentioned. TAO's IDL compiler lets you pass structures across the wire that otherwise conform to the data types supported by TAO (as it should). However, the marshalling in the version that we used at the time (1.0 of TAO) doesn't adjust for different byte packing orders on your target platform when you use structures. Therefore, if your NT binaries are compiled with the default 8-byte alignment in Visual C++, the Linux side, whether it is the client or the server, will not work right as Linux only offers 2- or 4-byte alignments for code at this point in time and will force the structure to the "wrong" alignment on the Linux portion of the system.
Frank C. Earl
DDJ
