Bureaucrats, confirmed, Administrators
4,558
edits
Changes
minor edits
So, where can we get an idea of the language to use for a client wishing to hire a consultant who would employ GPL software and intend to publish and share that intellectual property for the benefit of the client, the contractor and the world at large?
== Viral? Good Examples ==For a long time (and it still continues), the GPL was labelled "viral" (in a bad way) because if you let GPL code touch your proprietary code, you'll be forced to share your proprietary code. That's only half true. Articles like [http://www.techrepublic.com/blog/it-consultant/legal-considerations-when-using-free-software-in-it-consulting-projects/ this one] talk about this viral nature, but don't even touch on the other half of the story: what triggers the license. You have to "distribute" software to trigger the GPL, so if all you ever do is use the software (plus GPL additions) for your own internal purposes, then you have all the right in the world to use GPL software without having to publish your software to the world. Of course many people recognized that they could circumvent distribution by making "services" out of free software, for example, an online logo generator that uses the [[GIMP]] as a backend. This is sometimes called the <abbr title="Application Service Provider">ASP</abbr> loophole. In drafting the GPLv3, there was an attempt to define network transmission of services tantamount to distributing the software. This did not ultimately make it into the GPLv3, but instead is part of the variant called the Affero GPL (or AGPL)<ref>https://www.gnu.org/licenses/why-affero-gpl.html</ref>. The AGPL license has not been as popular as the GPLv2, but at least it's there for software developers to use when they want to prevent their creations from getting boxed up in the cloud. Of greater concern to the corporation is how distribution ''can'' be triggered in some non-obvious ways - such as through merger and aquisition<ref>See Distribution explained</ref>. Ultimately, using GPL software in your (commercially available and distributed) product is not different than using some other (proprietary) software -- you need the right to do it. GPL says you don't have that right unless you're willing to share. You don't want to share, then build it yourself. In-house counsel was often focused exclusively on this viral aspect and the "FOSS governance" policies that grew out of it were focused on restricting what could come in-bound to an organization. Their consulting contracts with vendors still had the mindset that they weren't using GPL software anywhere in their organizations, including the mundane and operations related areas of the business that would never cross the "distribution" threshold. To be clear, you can -- and millions of companies do -- use Drupal for an internal website, or MediaWiki for a knowledgebase. You can even modify or extend that code to do things you need it to do. And you don't have to share your code if you don't want to. For most companies and most situations, the best thing they can do is to actually promote their code back "upstream" into the FOSS software project. At a minimum, they should not '''prevent''' their code from getting upstream by placing legal obstacles in the way. The issue we're trying to focus on here and that very few address, is that a '''majority''' of companies not only use free software, but need commercial support for that software. They frequently want to build that extra feature or just need help deploying, integrating, upgrading and documenting it. It's not a core product. It's just some internal thing to get work done. Take for example a simple PHP application used for keeping track of Time Off, using a MySQL database backend. Should a company "own" the intellectual property associated with upgrading MySQL? It may actually be counter to the law. An author only has rights to the specific pieces of expression that they've contributed to a collaborative work so they can't claim ownership over the whole thing.
It was only after extensive research for this topic that I discovered the Civic Commons' [http://wiki.civiccommons.org/Legal_Issues_and_Best_Practices_Around_Procuring_or_Deploying_OSS_In_Your_Organization Best Practices Around Procuring or Deploying OSS in Your Organization]
* [http://harmonyagreements.org/index.html Project Harmony] offers not only a "harmonizing" view of Contributor Agreements, but also the inter-company contributor agreements so that employees of one organization can effectively collaborate on external FOSS projects that the company uses.
* [http://wiki.civiccommons.org/Contributor_Agreements The Civic Commons Wiki] offers a complete run down of CLA and CAA examples
== Is it Viral? ==
Why do contracts seem so hostile toward Free Software? Basically, contracts were written to defend against the risks that GPL '''could''' introduce to a companies core products. But this is only one aspect of the complete landscape. A seperate aspect is how companies '''rely''' on GPL software.
For a long time (and it still continues), the GPL was labelled "viral" (in a bad way) because if you let GPL code touch your proprietary code, you'll be forced to share your proprietary code. That's only half true. Articles like [http://www.techrepublic.com/blog/it-consultant/legal-considerations-when-using-free-software-in-it-consulting-projects/ this one] talk about this viral nature, but don't even touch on the other half of the story: what triggers the license. You have to "distribute" software to trigger the GPL, so if all you ever do is use the software (plus GPL additions) for your own internal purposes, then you have all the right in the world to use GPL software without having to publish your software to the world. Of course many people recognized that they could circumvent distribution by making "services" out of free software, for example, an online logo generator that uses the [[GIMP]] as a backend. This is sometimes called the <abbr title="Application Service Provider">ASP</abbr> loophole. In drafting the GPLv3, there was an attempt to define network transmission of services tantamount to distributing the software. This did not ultimately make it into the GPLv3, but instead is part of the variant called the Affero GPL (or AGPL)<ref>https://www.gnu.org/licenses/why-affero-gpl.html</ref>. The AGPL license has not been as popular as the GPLv2, but at least it's there for software developers to use when they want to prevent their creations from getting boxed up in the cloud. Of greater concern to the corporation is how distribution ''can'' be triggered in some non-obvious ways - such as through merger and aquisition<ref>See Distribution explained</ref>.
Ultimately, using GPL software in your (commercially available and distributed) product is not different than using some other (proprietary) software -- you need the right to do it. GPL says you don't have that right unless you're willing to share. You don't want to share, then build it yourself. In-house counsel was often focused exclusively on this viral aspect and the "FOSS governance" policies that grew out of it were focused on restricting what could come in-bound to an organization. Their consulting contracts with vendors still had the mindset that they weren't using GPL software anywhere in their organizations, including the mundane and operations related areas of the business that would never cross the "distribution" threshold. To be clear, you can -- and millions of companies do -- use Drupal for an internal website, or MediaWiki for a knowledgebase. You can even modify or extend that code to do things you need it to do. And you don't have to share your code if you don't want to. For most companies and most situations, the best thing they can do is to actually promote their code back "upstream" into the FOSS software project. At a minimum, they should not '''prevent''' their code from getting upstream by placing legal obstacles in the way.
The issue we're trying to focus on here and that very few address, is that a '''majority''' of companies not only use free software, but need commercial support for that software. They frequently want to build that extra feature or just need help deploying, integrating, upgrading and documenting it. It's not a core product. It's just some internal thing to get work done. Take for example a simple PHP application used for keeping track of Time Off, using a MySQL database backend. Should a company "own" the intellectual property associated with upgrading MySQL? It may actually be counter to the law. An author only has rights to the specific pieces of expression that they've contributed to a collaborative work so they can't claim ownership over the whole thing.
== Further Resources ==
* [http://www.law.cornell.edu/ Legal Information Institute] - a project started in 1992 by the Cornell University Law School that publishes the law online, for free. See the [http://www.law.cornell.edu/constitution U.S. Constitution] and [http://www.law.cornell.edu/uscode/text U.S. Code], etc.
* [http://copyfree.org/resources/references Copyfree], offers a collection of interesting articles, essays etc. about the problems of Copyright and offers an alternative copyright regime.
== Colophon ==
As part of our Free Culture efforts, the copyright for this wiki was updated to use the Creative Commons Attribution-ShareAlike 4.0 International License.
<html>