Licenses and Copyright
There are a few things that you can do that are incompatible with using the GPL. First of all, you can't derive a work from code licensed both under the GPL and the BSD license. This is because the GPL forbids imposing any restrictions beyond those imposed by the GPL, and the BSD license imposes the additional restriction that UCB and its contributors be acknowledged in advertisement.
Also, non-disclosure agreements (NDA) that prohibit you from releasing source code developed under the terms of the agreement are blatantly incompatible with using the GPL. If you sign an NDA that doesn't allow you to distribute source code, and then write code for a GPL application under the terms of the NDA, you can use your modified version of the GPL application (remember that the GPL doesn't restrict use in any way), but you cannot redistribute it.
Similarly, if your code uses a software patent, the patent must be licensed for everyone's free use, or you cannot redistribute your modified version of the application.
The Linux kernel is licensed under the GPL. This means that if you write code linked into the Linux kernel, and want to distribute it, the code must be licensed under the GPL. For example, you are not allowed to distribute the driver for a new hardware device as an object file that needs to be linked into the kernel at compile time. To do so would beg a lawsuit brought by everyone who holds copyright to some part of the Linux kernel.
It is possible, however, to distribute a driver in binary form only, under any licensing terms you wish, as a kernel loadable module. The kernel provides a public interface to which object modules can be bound at run time. The key words here are public interface. A public interface cannot be copyrighted. The declarations in a C header file and the system call interface are also examples of public interfaces, that are also not copyright-able. You can safely think of the kernel-loadable module interface as “system calls for code running with kernel privileges in kernel space”.
However, it is usually not advisable to distribute binary-only kernel loadable modules, for a variety of reasons:
The public interface is subject to change at any time and is frequently changed.
It violates the spirit of the GPL that has made Linux a success by taking away users' freedom to support themselves, and some users or potential users may become vocal about losing that freedom.
Linux developers will not notify you of changes in the interface; you need to be proactive in discovering changes by “joining the kernel-of-the-day club” (downloading, compiling, and running the latest kernel every time a new development kernel is released) or you will get complaints from users that your software suddenly broke.
Maintaining a binary-only product based on a kernel-loadable module is definitely possible but doing this does take extra work, and if you don't account for the work beforehand, you may be unhappy when you need to take the time. To say this another way: most commercial software development on Linux raises no more issues than are raised on any other platform, but binary-only kernel modules do raise other issues that you would need to consider.
Sometimes people want their code to be licensed under terms that are compatible with both the GPL and the BSD licenses. There are three ways to do this.
The first involves the copyright instead of the license. You can donate the copyright to the public domain which gives intellectual ownership to everyone in the world, individually and collectively. Anyone can do anything at all with the code, with no restrictions whatsoever. Since they own the code, they don't need a license to use it.
The second involves writing a very permissive license that allows anyone to use the code for almost any purpose. As long as you don't add any restrictions that aren't in the GPL, and as long as you don't prevent other people from adding restrictions, code protected by this form of licensing can be used for projects that use the GPL or the BSD license, without legal problems. If you choose to write your own license, be sure to get legal help in doing so. There are many licenses written by laymen that are legal nonsense, and if you want to have any chance of being able to enforce your license, get a legal opinion. Also, get a legal opinion if you do want other people to be able to use your code, since without a license, it is illegal to use code you don't own. anyone concerned about lawsuits won't be able to use your code if it is licensed under non-enforceable terms, even if you have personally decided you would never sue anyone over use of the code.
Perhaps the best option, however, is this: as the copyright owner, you can license your code to anyone you like under any license you like. You don't have to offer only one set of license terms. You can offer users the choice between, say, the GPL license terms and the BSD license terms. For example, a set of libraries called PAM is being developed which will need to be linked both with GPL applications and BSD applications. Its license first gives the BSD license terms (modified not to mention UCB, since UCB isn't involved in its development), and then says, “ALTERNATIVELY, this product may be distributed under the terms of the GNU General Public License, in which case the provisions of the GPL are required INSTEAD OF the above restrictions.” Some code in the Linux kernel has been licensed in this way.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 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