Why Corporations Favor The Apache License Over The GPL/LGPL

By Ricky on July 18th, 2011

Licensing of one’s works is a huge issue in the world of open source software. A proper license ensures that people do not steal your works. Right now there are two licenses that are most commonly used for open source software – the GNU Public License/GNU Lesser Public License and the Apache License.
The GNU/LGPL is very popular among independent developers and companies which mainly deal with open source software. The Apache License, on the other hand, is favored by the big corporations for their open source projects.

Let us examine why these corporations stay away from GPL and favor the Apache License.
This is what Section 4 of the Apache License version 2.0 says:
You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
You must give any other recipients of the Work or Derivative Works a copy of this License; and
You must cause any modified files to carry prominent notices stating that You changed the files; and
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
In non-lawyer words, this means two very important things:
When someone modifies an Apache licensed software and redistributes it, it is not necessary to release the modified version of the source code.
It is not necessary to submit the changes made to the source code to upstream.
The only requirements are that proper attribution must be provided and that the Apache license should be included with the redistributed software.
This license gives huge leeway to anyone who wants to use the Apache license codes in their products. They can cherry pick what they want from the codes that the community has built, make their own improvements/changes over it and then release it as their product. They do not even have to release the modifications they have made to the code – but they generally do, albeit a bit late, so that the community of developers do not go on an altogether different path.
The GNU General Public License on the other hand is a much more restrictive license. The main idea behind the GPU is freedom of the software.
Here is a part of Section 6 of the GNU General Public License version 3:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
This part is the main reason why many corporations avoid the GPL. This is basically what this section means:
If a software under GPL or a modified version of a GPL-ed software is released to the public, the distributor needs to make the source code, including the modified version if any, available to anyone who wants it.
If a GPL-ed software is used to run a device, the manufacturer must make the installation information available so that a modified version of the software can be made to run on the same device.
This means that with GPL negates any possibility by the corporations of making their changes to the GPL-ed codes and releasing their product without releasing the source codes. This is very good to promote software freedom but scares away the corporations.
Case Study - Android
The case of Android provides a very good example of the differences between the leeway that a corporation can get because of the Apache license and the GNU Public License.
As you might be probably aware, Google has not yet released the complete source code of Android 3.0 “Honeycomb”. This is possible because of the Apache license.
The licensing of Android is a bit complex. Android uses the Linux kernel and the userspace is built using Dalvik – a Java Virtual Machine developed by Google. While the Linux kernel is released under GPL, most of the userspace that Google has developed is under the Apache License.
The result is clear with Android Honeycomb. While source code of the part under GPL has been already released, Google has not yet released the part under Apache License. (They developed the part under the Apache License. So, they can change the license anytime. But that is another discussion.) Actually, Google has released the GPL part, which mostly consists of the Linux kernel, of Android 3.2 while the Apache Licensed part is nowhere in sight.
The Apache License also allows the Android handset manufacturers to not release the source code of Android that is running on their phone. (Every manufacturer modified Android based on its need and hardware they are using on the phone.) It also allows many manufacturers to lock the bootloader of their device. Had it been licensed under GPL, locking the bootloader would not have been possible because of the tivoization clause included in Section 6 of the GPL (also quoted above). (I am not sure if locking the bootloader constitutes GPL violation because of the presence of the Linux kernel.)
Disclaimer: Anything mentioned in this article should not be considered as legal advice.

http://digitizor.com/2011/07/18/apache-license-vs-the-gpl/?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+digitizor+%28Digitizor%29