A Senior Microsoft Attorney Looks at Open-Source Licensing
Gomulkiewicz's argument is utterly without merit, of course, but an outsider wouldn't be able to figure out why, and that's dangerous. Here's the rebuttal. Sure, open-source licenses disclaim liability. And sure, open-source authors can't handle lawsuits. But there's a world of difference between a disclaimer of responsibility from an open-source author and a similar disclaimer made by a corporation that's trying to shove closed-source software down your throat.
Why? It's all in the nature of the deal. With open-source software, you don't need warranty protection (and indeed, it would arguably be bad faith to demand it) because you are, in principle, walking into the deal with your eyes wide open. You know what you're getting, and if you don't, you can find someone who does. Open-source licenses enable the community of users to inspect the code for flaws and to trade knowledge about such flaws, which they most assuredly do. Such licenses allow users to create derivative versions of the code that repair potentially hazardous problems the author couldn't foresee. They let users determine whether the program contains adequate safeguards against safety or security risks. In contrast, the wealthy software firms pushing UCITA are asking us to buy closed-source code that may well contain flaws, and even outright hazards attributable to corporate negligence--but they won't let us see the code, let alone modify it. You don't know what you're getting. And that's why it's not worth giving up your right to sue the bastards, if they've been negligent and stuck you with something that hurts or kills somebody.
Here's the difference, in a nutshell. Suppose you're about to get on an airplane. A nice-looking young man hands you a carry-on bag and says, "Would you please take this with you? My wife forgot it." And then, he's gone. Uh-oh, no warranty. Does the bag contain a bomb, or is it just swimsuits and underwear? If the package is wide open when he hands it to you, you're free to see what's inside ("Yup, it's just clothes.") Of course, you still shouldn't take it on the plane (who knows; perhaps some terrorist somewhere has figured out how to make explosive underwear) but you get my point: When the package is open, you're not just a powerless pawn. But what if the package is wrapped up tight, and you're told you could be sued or jailed if you tried to see what's inside? That's the deal you get from UCITA.
In sum: even without warranties, free software is a good deal because you're free to determine just what you're risking. It's not just because the package is open; it's because the openness gives you freedom. Unless you talk about freedom, you can't understand free software, and you can't correctly interpret the provisions of free-software licenses.
What's so horrible about talking about giving users freedom? Here's the "confrontational", seditious language that OSI wants to suppress (from the GNU Project's home page):
Free software" refers to the users' freedom to run, copy, distribute, study, change, and improve the software. More precisely, it refers to four kinds of freedoms for users of software:
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom 1).
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to improve the program and release your improvements to the public, so that the whole community benefits (freedom 3).
And that, my friends, is what it's all about.
By keeping quiet about our principles, we're handing the likes of Gomulkiewicz the tools they need to further their aims, which are most decidedly not those of the Free Software movement or the Open Source software movement. And if you think this doesn't matter, think again. UCITA proponents will use Gomulkiewicz's argument in their effort to convince legislators to adopt UCITA's provisions--and we're all going to have to live with them.
What do you get when you bring principles back in the picture? Try this: contrary to your argument, Mr. Gomulkiewicz, the examples you discuss disclose all too clearly why the authors of closed-source, commercial programs should be held liable for program defects--unless, of course, your clients are willing to give users the countervailing freedoms that make GPL-licensed software an acceptable deal.
Gomulkiewicz, Robert W. "How Copyleft Uses License Rights to Succeed in the Open Source Software Revolution and the Implications for Article 2B", Houston Law Review, 1999, 36 (Spring 1999). Note that Gomulkiewicz expressly states that the views expressed in his article are his own, and not those of Microsoft Corporation or the Business Software Alliance.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Non-Linux FOSS: Caffeine!
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Parsing an RSS News Feed with a Bash Script
- Work the Shell - Analyzing Log Files
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide