(if you're tired of this thread, well, there's always the delete key.) as a followup to an earlier posting regarding the peruvian congressman who tried to enact a bill to promote open source software in the national IT infrastructure, there was one *important* point that may have been missed.
that bill in no way prevented the consideration or purchase of microsoft software. what the bill *did* was to lay down some basic requirements for software that would be purchased by the peruvian government. it didn't name any names, it simply stated what was and was not acceptable in terms of general software attributes. the last several emails got me thinking about this, and i sat down and dashed off a short piece that i'd been thinking about for a while. you'll see how this comes back to the peru/microsoft issue at the end. basically, here's my take on the criteria one should use in evaluating whether or not to purchase/adopt a vendor's software package. --------------------------------- Open source ---- ------ Despite the constant raving over open source, I don't think having access to the source code is all that it's cracked up to be, and I wouldn't necessarily make this a deal-breaker. Sure, it would be nice. At the least, you could check the code for spyware and Trojan horses, and possibly recompile it for a different architecture. But it's certainly possible to be happy with decent, reliable closed source. Consider NVIDIA and their video card drivers; while open source fanatics carp and whine about the closed source aspect, and granted it does make it a bit inconvenient to install, I'd be willing to live with it. Because, quite simply, there are bigger issues ... Open formats/protocols ---- ------- --------- *This* is a deal-breaker -- the fact that all of the software's file formats and communications protocols be completely and accurately documented and publicly available. This requirement should not be open for negotiation. Having details of the file formats and protocols means you have at least some chance of debugging if something is going wrong. In addition, if the company goes bankrupt and vanishes or (God forbid) gets into a legal screaming match with you, you're protected from having your precious data becoming suddenly and completely inaccessible. It's also protection against forced, non-backward-compatible upgrades, a favorite source of regular revenue. As long as you understand the formats and protocols, you always have the freedom to take your data elsewhere. (And don't put up with arguments about how hiding these details somehow results in more secure code. Microsoft software is the very definition of concealed, proprietary code. And it leaks like a freaking sieve.) Which brings us to the next critical requirement ... Open interoperability ---- ---------------- Associated with open formats and protocols, this means that you should have the right to use or develop software that will play nicely with the vendor's package. The software should, under no circumstances, contain code or features whose only purpose is to prevent it from working with other vendor's software. If you're paying for the software, you should expect the right to use it in conjunction with any other software package that you want. Which brings us to the final deal-breaker ... Open licensing ---- --------- (OK, this doesn't really have anything to do with the word "open" but I was on a roll.) Using a little artistic license here, my idea of open licensing is that the licensing terms for any software should be written in clear English, and it should be publicly available for examination before the purchase. You should, under no circumstances, have to sign an NDA or agree beforehand to *anything* just to know what the licensing terms are. This, by definition, disqualifies EULAs that are visible only after you tear open the shrinkwrapped box. In addition, regardless of whether the licensing terms represent a sale, a lease, a subscription or any other form of use, those terms should not be changeable arbitrarily by the vendor at any time. And, finally (and related to interoperability), you should just say "no" to any software whose licensing terms attempt to dictate what is and is not acceptable use of the software. No vendor should have the right to tell you (beyond what are reasonable licensing rules) what you can and can't do with the software. Witness, for example, Microsoft's amusing clause in the FrontPage EULA which stated that you can't use that software to develop web sites that make derogatory comments about Microsoft. That sort of restriction should be grounds for immediate disqualification from consideration. ------------------------------------ and that's the criteria. from memory, this is vaguely similar to what the peruvian congressman was promoting. and when the microsoft peru rep complained that the proposed bill disqualified consideration of microsoft, the congressman quietly pointed out that it did no such thing. all it did was set out some very basic requirements as to what *kind* of software would be considered. if microsoft's software did not fulfill the requirements, that was after all *microsoft's* choice. end of discussion. rday p.s. i wrote this out since i'm likely going to use it as the basis for a seminar or two in the near future. feel free to email me privately to comment on it. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
