Licenses and Copyright
How often do you see on Usenet a sentence like “DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice ?” Perhaps one day tort reform will be passed and non-lawyers won't have to make a disclaimer like this in order to avoid being sued. Until then, I need to make the same disclaimer: I am not a lawyer. I don't even play one on T.V. What you read here is my interpretation of these licenses, and while I have done my best not to err, to err is human. Before betting your life, your fortune, or your sacred honor on my interpretation you should read them yourselves, come to your own understanding of them, and if you are not comfortable ask a lawyer.
The first thing you need to understand is the difference between copyright and license. A copyright safeguards the ownership of an intellectual property. If you hold copyright to some intellectual property, you have several rights regarding that property, and you can assign (sell or give) some or all of those rights to others. A License, on the other hand, is a document lets someone use your intellectual property.
For example, the GNU General Public License (GPL), which is often incorrectly called a “copyright,” is a license. Applying the GPL to code to which you own the copyright does not assign the copyright to the Free Software Foundation (FSF, the authors of the GPL). You still own the copyright—applying the GPL to your code merely lets other people modify and redistribute your code in accordance with the GPL's terms. The GPL is too long to include in this article; you can use FTP to retrieve a copy from the canonical site, prep.ai.mit.edu, in the /pub/gnu directory.
The GPL is one of the most popular licenses in the Linux world; the MIT X and BSD licenses are also popular. The MIT license is very permissive: it says (like all software licenses of which I am aware) that no warranty is provided, that the copyright notices must be maintained, and that MIT's name (or with similar licenses, the name of the copyright holder) cannot be used in advertising or publicity without written permission. The BSD license, by contrast, requires that all advertising materials display an acknowledgment of “the University of California, Berkeley and its contributors,” while prohibiting using either name as an endorsement. In other respects, it is much like the MIT license. If you can't figure out how to acknowledge MIT and BSD without using them, talk to a lawyer. The MIT and BSD licenses are short enough to reprint in this article—see the sidebars.
Let's say you wish to develop free software derived from software that is licensed under the terms of any one of these agreements. All you have to do is maintain the current copyrights and insert your copyright notice for the code you add, thereby licensing your additions under the same license as the rest of the code.
However, if you wish to develop commercial software derived from free software, there are thornier issues. The MIT and BSD licenses do not require you to release your source code. You must simply follow the terms of the license, which mostly have to do with maintaining copyright notices and following limitations about advertising and promotion. If the original software is licensed under the GPL, however, you must release your source code in compliance with the GPL in order for you to distribute the derived work.
The biggest single concern shared by software developers new to Linux is that because Linux is subject to the GPL, any software written or compiled under Linux is also subject to the GPL. Fortunately, this concern is groundless. Plenty of commercial software is available for Linux, and it does not violate the GPL in any way. Developing and compiling your software on a Linux system does not cause your software to be derived from the GPL-licensed Linux source code.
Some people assume that because they use #include to include system header files in their application, their application is suddenly considered to be “derived from” those header files. This is not the case; the declarations in header files are legally considered “public interfaces” and cannot be copyrighted. This is the same as any other development platform: the header files on every commercial platform sport copyright notices that assert ownership over the header files, but that doesn't mean your application was derived from those header files.
Some people also assume that if they compile their program with the GNU C compiler (gcc), their program must be licensed under the terms of the GPL. This is not true. The GPL states that “the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).” Many commercial software vendors compile their products exclusively with GCC; some Unix systems are shipped from the vendor with GCC as the standard system compiler. They are not in violation of the GPL.
You do need to be careful, however, when linking with libraries that are licensed under a slightly relaxed version of the GPL called the GNU Library General Public License, or LGPL. Linux's standard C library, and most of its other libraries, are licensed under these terms, which require you (read the license for further details) to do one of the following:
Provide object files that can be linked to static libraries.
Provide source code.
The second option isn't very easy to implement, and the third option, while great for freely redistributable software, is less than ideal for more restricted commercial software vendors. The right answer for everyone, whether the software is free or not, is to link dynamically. This provides several advantages:
Your program uses less system memory when running.
Allows your program to be upgraded automatically when bugs are found in the library.
Creates smaller binaries.
Since dynamic linking is the default on all normal Unix platforms, using it on Linux platforms is not likely to be a hardship.
Note that this restriction applies only to libraries licensed under the LGPL. Commercial libraries such as the Motif libraries are not affected by this condition, nor are libraries that are licensed under the BSD or MIT terms. Since there is rarely any reason to link statically, you can almost always ignore this issue. You need only worry about it if you want to distribute a program that is staticly linked against an LGPL-licensed library and you do not wish to distribute the source code.
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!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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