Date: Fri, 1 Dec 2000 03:11:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brett@lariat.org (Brett Glass) Cc: tlambert@primenet.com (Terry Lambert), freebsd-chat@FreeBSD.ORG, freebsd-advocacy@FreeBSD.ORG Subject: Re: Here is what IBM thinks about using FreeBSD on their newer Message-ID: <200012010311.UAA18343@usr09.primenet.com> In-Reply-To: <4.3.2.7.2.20001130170310.049eb740@localhost> from "Brett Glass" at Nov 30, 2000 05:10:40 PM
next in thread | previous in thread | raw e-mail | index | archive | help
This is getting rat-holed into another "GPL is evil" tirade... > >Only if you link against it. When was the last time you > >linked against "grep"? > > In this case, it's infectious in a different way: It is > eliminating truly free alternatives. Use it, and you are > facilitating another prong of the GPL agenda: to snuff > out other options. The fact that FreeBSD does not provide > a non-GPLed grep which is BSD-licensed means that the FSF > has succeeded. The real "grep" source code is still available; sure it means you have to assemble the parts instead of just taking FreeBSD and running, but be honest: any product based on FreeBSD, or any Open Source code, for that matter, has to be productized before it is really useful. > Also, proponents of the GPL are now opting for an expanded > requirement based on the notion of "performance for profit." > Just running the code in a situation where you made money > from it would trigger a requirement to forfeit one's work. I haven't heard this, and I have reason to doubt it: the MySQL license was this way, and they moved away from that to go with the GPL instead, which dropped the "no commercial use" restrictions, including the performance for profit restriction. > >People who needed access to a command line, and could actually > >use one, were such access granted, were not in our target > >market. > > Ah, but I'm sure that the scripts that run your GUI activate > command line utilities behind the scenes -- including, most > likely, ones like grep. You may be sure, but you're also wrong. 8-). Actually, the UI code on the InterJet is predominantly written in C++, using C++ objects as models for form, frame, table, and other objects. The work was initiated at a time when you could not write HTML code that would result in a consistant user experience across different browsers, and the library used to implement the code is called "libbif" for "Browser Independent Framework". The stuff that's not written that way is writen in C, and the major guts of the system are also in C. I rewrote the mail services subsystem and the agent database management subsystem, to use subschema entries, so mail configuration, mailing lists, users, user capabilities, account information, etc., was all based on a common data modelling system. In fact, the only things that weren't in this model were the legacy code in the system agent, the web publishing, and the scheduling agent (the system agent handled network and other system configuration settings, and was written in C by Archie, while the scheduling code was written by Larry). Even in the startup and shutdown scripts (at least two of which are shell scripts which call grep, but the majority of which are actually special purpose binary programs or wrapped versions of special purpose binary programs, with perl or sh doing the wrapping), there's no GPL infection, since calling something from a shell script is _not_ linking. Even if you were right and the rest of the world were wrong about what constitutes risk in this neighborhood, I'd like to point out an obvious fact that appears to have escaped you... IBM does not sell InterJets, any more than your local cable company sells set-top boxes: IBM sells services. Since an end user does not _buy_ an InterJet, they are not entitled to the source code, even if it was all contaminated: they are not being sold the software. Consider if you were to run a program compilation service, where people submitted code to be compiled, you compiled it with GCC, and sent the object code back to them. You charge for this service, and you've made modifications to GCC to make it more efficient: are your customers entitled to your modifications? No. They are merely _utilizing_ your service. This is the same distinction between "use" and "utilize" that GPL proponents try to obfuscate, only this time it is working against them. Likewise, I could that GCC, modify it, make a compiler that generates vastly superior code, use it to compile the stock GCC, get a compiler that compiles the same unimproved code as the stock GCC... but does so three times faster. I now sell binaries of this new compiler, and give away the source code: after all, it's nothing more than the stock GCC source code. I don't have to give away my modified compiler source code at all, any more than I have to give away the source code to the DEC/Compaq Alpha compiler when I compile GCC using it and get a faster, tighter GCC binary as a result. So much for any "performance for profit" clause which might come along later being worked around. Until and unless the entire software industry moves to the new model, _any_ new model can be worked around, within the scope of it having to be able to coexist with the current model for it to be able to get anywhere. > >There is a Ricoh photocopier and a Ricoh document capture > >device, both based on FreeBSD. I rather seriously doubt > >that they ship the code in such a state that you could get > >a command line, period. > > I'll have to check with Steve Savitzky on this. (He's a > strong open source advocate within Ricoh and may have > driven this choice.) My guess is that you can get a > command line for the purpose of servicing the machine, > perhaps via a TTY port inside the case. But that's not > the point. Even if YOU can't get the command line, > I'll bet their GUI invokes command line utilities. Doubtful. CGIs are underpowered, and scripted CGIs will always lose out, performance-wise, to compiled code. If you are right, then someone is just going to build the same product, throw out the scripting, and take their market away from them, based on higher performance on equivalent CPU cycles, or the same performance on lower cost hardware with lesser CPU cycles. Binary always beats scripts on everything but prototyping. Scripts are not a good idea for deployment, since they are fragile in the face of system upgrades and other changes which might change the underlying components implementing their functionality (e.g.: grep), and since it is almost impossible to do formal verification against a script: you'd have to verify every system comonent with which the script interacted, and then you'd have to invent a formal validation tool for sh or perl, which while not quite an NP-incomplete problem, would be close enough for the amount of time remaining before your product is obsolete. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012010311.UAA18343>