A significant facet of our jobs as IT (formerly known as DP) professionals involves dealing with software licenses. Personally, I consider it to be the most distasteful aspect of my job. Why? Because the administrative expenses associated with software licenses are sunken costs. Like leeches, these expenses suck the life out of your IT budget, without contributing in any way to the success of your IT operation. Think I'm exaggerating the extent of the problem? If so, then how do you account for the genre of software that has been created to do little more than count instances of licensed software and ensure license compliance? (Software titles in this genre no doubt have their own licenses.)
If you are strictly a consumer of software products—and by that I mean that either 1) you use only canned software or 2) you use software that you have written in-house for use strictly in-house—then you may have little interest in the morass that now engulfs our industry. Your administrative costs all revolve around counting the number of licenses you have and comparing that to the number of users or computers using the software, ensuring that the former count matches or exceeds the latter count. Meet that requirement (and don't do any of the other prohibited things like reverse-engineering file formats or using the software in creative-but-unanticipated ways) and you'll avoid the severe punishments meted out to the miscreants—like monetary penalties, dismemberment, death, or worst of all, a software audit by the Business Software Alliance. (For some reason I can't help but think of Monty Python's "Nobody expects the Spanish Inquisition" skit when I think of a BSA audit, but I digress.) Of course, if you use open-source software in this manner, you won't have to count the licenses or instances.
If you write software for others to use (as an individual or as part of a corporation), you can have a much more difficult path to travel. Not only do you need to ensure that you meet the licensing terms of whatever software you use in the production of your software while you're using it, but you'll need to ensure that you meet the terms while distributing your software, too. For example, you may have used a proprietary tool to produce your program but be unable to distribute everything from the original tool needed to run your program. The end-user needs to purchase a copy of the proprietary tool to use your program. While some simple programs are distributed with these limitations, more familiar examples include packages that use the proprietary extensions found in any of the commercial databases. Buy a product tied to one of those databases and you've committed to purchasing a license of the target database as well.
Basing your product on open-source tools instead of proprietary ones isn't going to relieve you of any licensing burden, to be sure. In some ways, the burden might be greater. The licenses available in the open-source world run the gamut from the ultra-liberal BSD style (where the software truly is a gift that you are welcome to use, modify, and redistribute without any strings attached whatsoever) to the forced-largess brought about by the GPL-style license (where you need to distribute any changes that you make to GPLed software and make available your product's source code if you have directly tied your software to GPLed software). Determining when you have crossed over into GPL land can easily be a major problem, subject to interpretation.
In many ways, the success of the open-source movement is at the root of the problems surrounding open-source licensing. Many companies have wanted to proclaim their new-found appreciation of the movement (if for no other reason than that it makes for wonderful press releases), yet when rubber meets the road many find themselves unwilling or unable (because of their own licensing of other software) to make the leap fully into the GPL or BSD world. What course do they take? They pull a page from the open-source playbook and write their own license, of course! And of course, they all have their own stipulations.
One of the first to do this was Mozilla.org, the organization given the stewardship of the Netscape browser code when it was open-sourced. The precedent of the Mozilla Public License Version 1.0 has validated all of the other companies that have created their own licenses. The list includes such luminaries as IBM (IBM Public License), Sun Microsystems (Sun Public License), Intel (Intel Open Source License), MIT (MIT license) and even NASA (NASA Open Source Agreement). The de facto organization that reviews these licenses for conformance to the spirit of open source and then gives them a "seal of approval" if they are found worthy is the non-profit Open Source Initiative (OSI). On the OSI site, you can find a list of approved licenses and the text of those licenses. If you want some entertainment, pick a couple of them and read them over. While each license is a fairly easy read (one of the requirements of an OSI-approved license is that it doesn't require a lawyer for interpretation), a software package that you write using multiple open-source packages based on multiple licenses can cause you some indigestion; you need ensure that you meet the requirements of all of the licenses involved.
Notably missing from the list of OSI-approved licenses is Microsoft's "Shared Source Licenses." It's not that these don't meet the requirements as much as it is that the OSI and MS have had a shaky relationship and MS has not submitted its licenses for approval. Having read over the MS licenses, I can say that they are no better or worse than those on the OSI list, depending upon your needs. Not surprising to me was that some MS variations provide for licenses to be valid only on the Windows platform. I'm not sure how that fits in with the true spirit of open-source software, but if everyone else is customizing their view of open-source, why not MS, too?
I can't help but feel that the proliferation of all of these licenses can only lead to a slow-down in open source. Movements are afoot to clean up the mess, and if you read much of the material coming from the community, you'll see that the call to apply the KISS (keep it simple, stupid) principle to licensing is getting louder. And just as you think things will start improving, you'll note the hype surrounding GPL Version 3 that seems to pervade much of the headlines of late. In a nutshell, the big issue surrounds DRM (the acronym for Digital Rights Management, or Digital Restrictions Management if you're a card-carrying member of the Free Software Foundation as I am). On the one hand, you have the FSF, which believes DRM to be Satan's spawn, and on the other hand, you have the pragmatists (including Linus Torvalds) who realize that some allowances must be made for things such as Apple's iPod and high-end graphics cards if Linux and other open-source products are to gain acceptance from a wider audience.
Where will all of this end? I don't know. I strongly believe in the open-source model, and apparently many corporate entities do, too. It's just that all of our views of what it should look like differ. Many packages are available that are too compelling to ignore, yet the burden of employing them can be nasty. Until the open-source market gets the license morass drained, all I can offer is the suggestion to put on your muck boots and slog through. And please, don't write your own license!
Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online