Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Jump to navigation
Jump to search
m
<abbr title="I Am Not A Lawyer">IANAL</abbr> (That means I am not a lawyer.) I'm just a free software expert.
Text replacement - "<abbr title="[^"]+">(.*)<\/abbr>" to "$1"
== Contribution Agreements ==
Contribution agreements are one area where we can look to get an idea of standard practices among larger foundations and FOSS projects. Essentially, the client is the foundation, and the developer may be an individual or a member of a corporation. The OpenID Foundation (OIDF) develops specifications, so it's a good example of where standards development and software development meet. There is a [http://openid.net/executed-contribution-agreements/ long list of contributors to the OpenID Foundation]. The OIDF has both a formal Process to develop their specifications, as well as an <abbr title="Intellectual Property Rights">IPR</abbr> Policy <ref>http://openid.net/ipr/OpenID_IPR_Policy_(Final_Clean_20071221).pdf</ref>. The Policy classifies contributors as "unaffiliated" (an individual), "affiliated" (anyone who work for a company), and "representative" (third-party).
Here is the language in section 5.1 of the IPR:
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.
== Disclaimer ==
This information is here to educate, inform, and hopefully spread best practice information to other consultants and their clients alike who wish to operate in the real world that is completely full of interconnected "Intellectual Property". It is not legal advice. It should not be construed as legal advice. It does not create an attorney-client relationship. If you're an attorney reading this, I'd love to get your feedback and I hope that this information is useful to the representation you provide to your clients.
