decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
A CLA By Any Other Name - Updated 3Xs
Tuesday, May 24 2011 @ 02:40 PM EDT

One of the challenges free and open source software projects have that proprietary software doesn't is determining the best method for accepting developer contributions to a project from a legal perspective, not an engineering perspective. In proprietary software, where all of the developers work for the employing entity, the copyright in their work belongs to the employing entity under the “work for hire” doctrine found in 17 U.S. Code §101.

Free and open source development projects cannot (and really don't wish to) rely on the work for hire doctrine and have to develop their own rules of the road for developer contributions. One of the first issues to be addressed is context. What does the project seek to achieve? Who started the project? Is one entity principally responsible for most of the code in the project?

Where the project is largely managed by a single entity there is some benefit in having all copyright in the code base held by that single entity in order to assure compliance with the governing FOSS license. This is a bigger issue in the U.S. under copyright than it tends to be in some other countries. For example, one of the reasons that Harald Welte has been so active in GPL enforcement in Germany is the more lenient standards for standing (the right to sue) in German courts under copyright.

Where that single entity is a commercial entity, there may also be an interest in dual licensing, i.e., the ability to license the same code under a FOSS license and a proprietary license. This approach has been successfully employed by companies such as MySQL, but MySQL also wrote about 99% of the code in their code base. The original MySQL contributor agreement was replaced with one from Sun, and has now been replaced by this one from Oracle [PDF], which grants Oracle joint ownership of copyright. [NB: Joint ownership of copyright can be problematic, since each of the owners can license under terms they choose.]

There are also projects that are truly open source projects and where the project maintainers are more interested in simply assuring they have sufficient rights in the contributions in order to include them in the project. They may also be interested in maintaining some flexibility around which FOSS license to use as the project develops. Each of these approaches results in a different approach to how contributions of others are handled, and because each project is unique, contribution agreements tend to cover a wide range of approaches. Simon Phipps has written a good article discussing some of these issues and addressing Project Harmony, but more about Project Harmony later.

Some projects, like the GNU projects run by the Free Software Foundation (FSF), in some instances require an assignment of code submissions if they are to be included in the project. [See, Contributing to GCC as an example. There the FSF asks that contributors either assign their copyright or disclaim it (put the code in the public domain). In neither case does the contributor retain any rights under copyright in their contribution. Such an approach likely works for the FSF because they have been a trusted partner in assuring code stays free. You can see the full text of such an assignment to the FSF here:

Copyright Clerk
Free Software Foundation
59 Temple Place Suite 330
Boston, MA 02111
USA

ASSIGNMENT

For good and valuable consideration, receipt of which is acknowledged, (the "Assigner"), hereby transfers to the Free Software Foundation, Inc. (the "Foundation") its entire right, title, and interest (including all rights under copyright) in its changes and enhancements to the computer program , including changes in accompanying documentation files and supporting files as well as changes in actual program code, subject to the conditions below. These changes and enhancements are herein called the "Work". The work hereby assigned shall also include any future revisions of these changes and enhancements hereafter made by the Assigner.

The Foundation grants the Assigner non-exclusive rights to use the Work (i.e. the changes and enhancements, not the program which was enhanced) as it sees fit; this grant does not limit the Foundation's rights.

For the purposes of this contract, a work "based on the Work" means any work that in whole or in part incorporates or is derived from all or part of the Work.

The Foundation promises that all distribution of the Work, or of any work "based on the Work", that takes place under the control of the Foundation or its agents or assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to the Foundation or to anyone else for any permitted use of the work they apply to, or to communicate with the Foundation or its agents in any way either when redistribution is performed or on any other occasion.

The Foundation promises that any program "based on the Work" offered to the public by the Foundation or its agents or assignees shall be offered in the form of machine-readable source code, in addition to any other forms of the Foundation's choosing. However, the Foundation is free to choose at its convenience the media of distribution for machine-readable source code.

The Foundation promises to give or send the Assigner, upon reasonable prior notice and payment of a fee no more than twenty times the cost of the necessary materials and postage, a copy of any or all of the works "based on the Work" that the Foundation offers to the public or that it has offered within the past six months, or that it distributed for the first time within the past six months. For works that are programs, the machine-readable source code shall be included. Such a request shall detail whether the Assigner wish to receive all such works or specific works. The choice of works to request may affect the cost and therefore the fee.

The Assigner hereby agrees that if it has or acquires hereafter any patent or interface copyright or other intellectual property interest dominating the program enhanced by the Work (or use of that program), such dominating interest will not be used to undermine the effect of this assignment, i.e. the Foundation and the general public will be licensed to use, in that program and its derivative works, without royalty or limitation, the subject matter of the dominating interest. This license provision will be binding on the assignees of, or other successors to, the dominating interest, as well as on the Assigner.

The Assigner hereby represents and warrants that it is the sole copyright holder for the Work and that it has the right and power to enter into this contract. The Assigner hereby indemnify and hold harmless the Foundation, its officers, employees, and agents against any and all claims, actions or damages (including attorney's reasonable fees) asserted by or paid to any party on account of a breach or alleged breach of the foregoing warranty. The Assigner makes no other express or implied warranty (including without limitation, in this disclaimer of warranty, any warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE).

For the Assigner,
[name and title]
[signature and date]

For the Free Software Foundation,
Richard Stallman, President:

[Please write your snail address here, so I can snail a copy back to you.]

FSF uses the above approach where FSF itself is the principal developer of the project or where the principal developers have elected to assign copyright to the FSF. But this approach is not used on all GNU projects, some of which rely merely on the governing GPL to keep everything in line. [Note: See updates, below.]

You will also note from the above assignment text that the FSF makes an important commitment to the contributor as to the manner in which the FSF will relicense the contributed work. In other words, the FSF has limited itself to the GPL, LGPL, or Affero GPL, so any party assigning to the FSF can take comfort that their contribution will remain free.

But where does that leave other development groups, including those run by commercial entities such as Red Hat (Fedora Project) and Canonical, to say nothing of important projects like Apache and Eclipse that have their own communities. How do each of these entities approach the subject of contributions to projects they are managing.

Canonical, and more specifically, Mark Shuttleworth, have made some news lately around Canonical's contributor agreement. The Canonical approach mirrors, to some extent, the approach taken by the FSF. Canonical asks contributors to assign the copyright in their contribution to Canonical, and Canonical then “simultaneously grants the contributor a very broad license back, so that the contributor retains full rights to re-use, distribute, and continue modifying the contributed code.” The language of the grant states:

Canonical grants to Me a world-wide, non-exclusive, royalty-free and perpetual right to use, copy, modify, communicate and make available to the public (including without limitation via the Internet) and distribute, in each case in an original or modified form, the Assigned Contributions as I wish.

As Canonical states, this is a very broad grant, and it would allow the original author of the code to relicense their code contribution to any other party under terms of their choosing, including a proprietary license. In terms of rights vesting in the original author, that would seem to be a bit of an improvement over the FSF approach which only provides the original author the same license in his/her contribution that everyone else receives, i.e., a license under either the GPL or LGPL as determined by the FSF, including the determination of which version of those licenses. In any case, Canonical obtains unfettered rights to relicense the contribution in any manner it chooses and makes no commitment as to the form of such license. There is no assurance that the license Canonical uses will be a FOSS license, although Canonical states that will “ordinarily” be the case.

The Canonical agreement addresses potential patents through a promise not to sue from the contributor. But clauses 7 and 8 of the Canonical agreement place a rather heavy reporting and notification burden on the contributor:

7. I will not assert or enforce any patent against (a) Canonical (b) anyone who received the Software and/or the Assigned Contributions from Canonical or (c) anyone who received the Software and/or the Assigned Contributions under a Free Software License, where that patent is infringed by any of them exercising copyright rights in the Software and/or the Assigned Contributions. I will promptly notify Canonical and provide details of any such patents (and any published patent applications which if granted are likely to constitute such a patent) for which I am the proprietor (or applicant). Canonical will not assert or enforce against Me any patent that is infringed by Me exercising My copyright rights in the Software and/or the Assigned Contributions.

8. If I am or become aware of any patent or other intellectual property right which is, or is likely to be, infringed by the use of the Assigned Contributions, I will promptly notify Canonical.

All of this has led to significant push-back on the Canonical approach even though it is only shades of difference from the original FSF approach. The primary reason for the push-back? Probably the fact that Canonical is a commercial entity.

By contrast, the historical method used in the Fedora Project sponsored by Red Hat has been to obtain a broad license from the developer but leave the copyright ownership with the developer. This can be seen in the now superseded Fedora Project Individual Contributor License Agreement. In another departure from both the FSF and Canonical approach, Red Hat obtained an express license in any patents the contributor held covering the contribution. But one of the significant shortcomings (at least in the eyes of a number of contributors) of this old approach by Fedora was that it did not assure Red Hat would relicense the contribution as FOSS. Not surprisingly, while this approach left the copyright in the hands of the original author, the broad license rights granted Red Hat with no assurance that Red Hat would only relicense the code as FOSS left a number of contributors cold.

But one of the things the maintainers of the Fedora Project came to realize is that Fedora is primarily an aggregator of projects, not an originator of projects. As an aggregator, Fedora is more interested in assuring that packages included in the distribution have an acceptable FOSS license that governs them rather than worrying about an assignment or broad license apart from that package license.

So Red Hat, having hired much smarter lawyers than the one responsible for the old CLA (I think his first name was Mark) and listening to the Fedora developers went back to the drawing board and came up with the Fedora Project Contributor Agreement or FPCA. The FPCA is a very different animal. It is not a copyright assignment agreement, and it is not a broad grant of license in copyright to the code. Rather it works a lot like the Uniform Commercial Code does for commercial transactions under state law, i.e., if you specify a license for your contribution, that's what governs, but if you don't specify a license, then the contribution will be deemed made under the default license, which for the time being is the MIT license for software contributions. Now make no mistake about it, the MIT license is a very broad license, and it, too, would allow the code to be used in both FOSS and proprietary distributions. However, if you are concerned about the MIT-default, then specify your own. Your choice. You the developer control. Of course, if you specify a license that is unacceptable to Fedora (and they go to great lengths to let you know what is acceptable), then they won't accept your contribution.

This new Fedora approach would appear to be a vast improvement over any of the other approaches discussed above, at least on the copyright side, but for all of the improvement on copyright terms, it says nothing about patents. The problem there is that many of the FOSS licenses, including the MIT license, say nothing about patents. When asked why the omission, a Red Hat representative stated that it was a “considered decision,” recognizing there may be some risks but also recognizing that this keeps the process simple and acceptable to package maintainers and developers.

Returning to Canonical, it's not like they aren't trying to address the issue of contributor agreements. One need only look at Project Harmony, originating with Canonical general counsel Amanda Brock and described as:

Its initial goals are to avoid proliferation in contribution agreements across FOSS software projects where those organizations chose to work with contribution agreements. In doing this we hope to assist organizations which use contribution agreements by providing standardized variable templates with clear and concise explanations; to come to a common understanding on these; and to recognize the relative maturity of FOSS by dealing with its internationalization. We hope to make it easier for organizations to have and use contribution agreements. We believe that contribution agreements should make it easier for developers to contribute regardless of who their employers are.

Project Harmony is not a single contributor agreement; it is a series of such agreements. You can use either a license approach or an assignment approach. Project Harmony simply proposes that you use one of its standardized forms of agreement as opposed to a uniquely drafted one so that contributors can be confident they have seen the agreement language before and understand the approach being taken. So Project Harmony is not necessarily a new approach but rather seeks to standardize contributor agreement language depending on the approach one elects.

A quick review of some of the other contributor agreements that have been or are being used:

  • Android - Google utilizes the broad license approach.
  • Mono - Novell requires a copyright assignment if the contribution pertains to C# compiler or the Mono runtime engine.
  • Apache - The Apache Software Foundation uses the broad license approach.
  • Eclipse - The Eclipse Foundation uses an approach similar to that for the Fedora Project, with the governing terms for contributions included in the Eclipse Terms of Use for their website. Those terms provide:
To the extent you wish to upload, submit, or otherwise make Non-Code Content (as defined below) available to the Eclipse Foundation and/or the Members, you may make that material available under the terms and conditions of the EPL or any other license stipulated for that purpose at www.eclipse.org/legal. Non-Code Content is Content for which you own or control all rights, and which is not program code intended to be submitted to a Project and documentation related to such code. For example, Non-Code Content would include white papers, dissertations, articles or other literary works, power point presentations, encyclopedias, anthologies, wikis, blogs, diagrams, drawings, sketches, photos or other images, audio content, video content and audiovisual materials.

In summary, there are a number of different approaches to code contributions, and each approach is dependent on the nature of the entity, its particular goals, and the degree it is the predominant contributor to the project. There really is no one right answer, but there are also reasons why developers may balk at such terms. If a developer doesn't like the terms offered/imposed, they can elect not to contribute or start their own project. Ahh, the freedom of FOSS.

Update: We asked Richard Stallman if he had any comments to add regarding what FSF requires and regarding the Canonical CLA, and here is his response, plus a clarification from Brett Smith of FSF:

When a new GNU package is established, the developers can choose to give the copyright to the FSF or to keep it. To give the copyright to the FSF, they sign copyright assignments. Once the package is FSF-copyrighted, we ask subsequent contributors to assign copyright too.

In our copyright assignments we commit to releasing only with source code and with freedom to redistribute. Other contributor agreements place only very weak limits on what the company could do with your contributions.

The FSF published recommendations for contributors considering signing such agreements, telling them what to look for. I don't remember the URL and I can't see it in my machine. I cc'd Brett who can tell you where to find it. He can also tell you more about what the Harmony contributor agreement implies.

I think that under the Harmony contributor agreement, if the company nearly always released your code in nonfree releases, it would be violating the agreement. But it could go almost that far without violating the agreement.

And Brett Smith clarified further:
The article RMS is referring to is at fsf.org/blogs/rms/assigning-copyright. I'm pretty sure RMS was thinking about Canonical's copyright assignment here, which says that "Canonical will ordinarily make the Assigned Contributions available to the public under a 'Free Software Licence,'" but "may also, in its discretion, make the Assigned Contributions available to the public under other license terms." I'm not aware of any analogous text in the draft Harmony agreements.
Update 2: - From Brett Smith at FSF:

It is true that the agreement does ensure that whenever the FSF distributes the assigned software, recipients will have access to the source code and be able to distribute the software themselves. However, this means we're not limited to using GNU licenses: any non-copyleft free software license would also meet these criteria.

Update 3: Further from Brett Smith of FSF:

Our copyright assignment agreement gives the contributor unlimited nonexclusive rights, so they can do anything whatsoever with their code -- even use it in nonfree software. We do not ask contributors to make a commitment about how they will use their own code; they are already doing us a favor by assigning it. We make such a commitment to them, but they don't make such a commitment to us. Our usual assignment form that we provide to individuals accomplishes this by saying:

FSF agrees to grant back to Developer, and does hereby grant, non-exclusive, royalty-free and non-cancellable rights to use the Works (i.e., Developer's changes and/or enhancements, not the Program that they enhance), as Developer sees fit....

The form you posted is a specialized one we use when a company wants to assign a limited, specified set of changes to us. In it, a similar grant back appears in the second paragraph. The wording we use in individual assignments is more precise (and we'll be updating the specialized form now that we see that), but substantively they do the same thing: give contributors rights to use and distribute their own work any way they like.


  


A CLA By Any Other Name - Updated 3Xs | 214 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections
Authored by: alisonken1 on Tuesday, May 24 2011 @ 02:41 PM EDT
Put kerrections -> corrections in title if small enough, and fill out
comments to make note of where the correction should be.

---
- Ken -
import std_disclaimer.py
Registered Linux user^W^WJohn Doe #296561
Slackin' since 1993
http://www.slackware.com

[ Reply to This | # ]

Newspicks Thread
Authored by: alisonken1 on Tuesday, May 24 2011 @ 02:43 PM EDT
Remember to put the newspick item in the title and/or comment section since the
newspicks tend to scroll off the page rather quickly.

Any clickies be sure to follow html specs and change POST MODE to HTML if you
want the clickie to work.

---
- Ken -
import std_disclaimer.py
Registered Linux user^W^WJohn Doe #296561
Slackin' since 1993
http://www.slackware.com

[ Reply to This | # ]

Off-topic
Authored by: alisonken1 on Tuesday, May 24 2011 @ 02:45 PM EDT
Remember clickies and change post mode to HTML - and remember geeklog has a
tendency to split long links as well.

---
- Ken -
import std_disclaimer.py
Registered Linux user^W^WJohn Doe #296561
Slackin' since 1993
http://www.slackware.com

[ Reply to This | # ]

A CLA By Any Other Name
Authored by: old joe on Tuesday, May 24 2011 @ 02:54 PM EDT
What about the Linux kernel? What CLA does that have?

And the Libre Office project? How does their CLA differ from Open Office?

[ Reply to This | # ]

A CLA By Any Other Name
Authored by: Anonymous on Tuesday, May 24 2011 @ 03:00 PM EDT
"But where does that leave other development groups, including those run by
commercial entities such as Red Hat (Fedora Project)"

Careful, there are definitely teams within the Fedora project lead by and
consisting of community contributors who aren't part of Red Hat. I wouldn't
necessarily say Fedora is a development group 'run by' Red Hat, maybe
'sponsored' is a better word?

- Máirín Duffy

[ Reply to This | # ]

What about non US jurisdictions ?
Authored by: Anonymous on Tuesday, May 24 2011 @ 04:09 PM EDT
There are jurisdictions including Germany, where the transfer of copyright is
simply not possible. I'm trying to explain this to the .us centric copyright
assignment advocates (including FSF) since the 1990's and never got a reasonable
answer.

So I'm refusing to sign a paper which is not worth anything just to make some
stubborn copyright assignment fetishist happy. That excludes me from
contributing to any project which requires copyright assignment.

I know that a lot of people in such jurisdictions do not care at all about this
and just happily sign the papers, but that's not a solution.

It won't hold up in a lawsuit when the legitimate heirs of a person who signed a
copyright assignment start to challenge it. Even the person itself could change
his mind and would probably get away with it.

Are all these copyright assignment advocates still believing that .us law is the
only relevant one in a global collaborative environment?

Aside of that I have yet to see a single reasonable proof that copyright
assignments solves any problem at all. IMNSHO its creating more problems than it
claims to solve. And we have enough real proof that projects can do very well
without it.

Thanks,

tglx

[ Reply to This | # ]

What is a CLA?
Authored by: Anonymous on Tuesday, May 24 2011 @ 04:22 PM EDT
Centre Line Average, maybe?

[ Reply to This | # ]

Congratulations
Authored by: Anonymous on Tuesday, May 24 2011 @ 04:41 PM EDT
A nice well considered article. And one that,in my opinion, displays the
difference between Marks style and PJs. PJ comments on the process of the battle
from somewhere down in the trenches, whereas Mark surveys the battlefield from
his lofty academic perch and comments dryly on the progress of the battle.

[ Reply to This | # ]

Software Licensing – Don’t Complain If You Don’t Like The License
Authored by: The Mad Hatter r on Tuesday, May 24 2011 @ 08:28 PM EDT
Really Bill. Don't complain that a license that you don't like is 'un-American'.
Don't moan that it's communistic.

If you don't like the license, there's nothing forcing you to use it. There's
nothing forcing your customer to use it. You keep telling us how important
Capitalism is, and how it nothing can compete with the benefits of Capitalism.
But then you complain that you can't compete against something. You do realize
that this doesn't make any sense, don't you?

Pardon my sarcasm. Bill doesn't like competition. Time and time again his
company has proven that it is incapable of competing in a level marketplace. The
only way Microsoft can survive is if it's in a Monopoly situation, or if it's
competitor is so incompetent (think of Sony and their liberal use of the Foot
Gun) that it beggars belief.

It continually amazes how many people I meet who think that Microsoft is the
greatest company on the face of the planet. I recently read this absolutely
incredible blog post by some deluded fool who was calling on Microsoft to bring
order to the EBook market. I was one of half a dozen people who corrected him on
his facts about Microsoft Innovation. The shock was clearly evident in his
writing at the responses he had drawn - but he still held to his belief that
without Microsoft, Information Technology would be a shadow of it's current
self.

Totally amazing.



---
Regards

Wayne Borean

http://madhatter.ca - Through the Looking Glass
http://wayneborean.ca - About Writing
http://weblit.ca - Web Lit Canada

[ Reply to This | # ]

WOW!
Authored by: celtic_hackr on Tuesday, May 24 2011 @ 10:25 PM EDT
I never knew the FSF CLA was so restrictive. I could never sign that! I make my
living writing software. Most of it is proprietary. A great deal of it is also
reused from other code I've written. Signing something like that would mean I
could not use any of my pre-existing knowledge or code. Any portion of that code
would be bound up as now being open source software. All my work might be
affected.

Of course, it's unlikely I'd ever sign any kind of CLA. Too risky, once you have
something down on paper, some lawyer somewhere will be able to twist it into
something it was never meant to be and then I'd have to fight just to hold on to
my ability to make money.

[ Reply to This | # ]

A CLA By Any Other Name
Authored by: Anonymous on Wednesday, May 25 2011 @ 12:12 AM EDT
The article's title -- perhaps intentionally ironic -- misrepresents the
situation. What Canonical demands is NOT a CLA, it is copyright assignment. What
the GNU project demands is NOT a copyright license agreement, but copyright
assignment (and the GNU project does not try to hide this fact). What Fedora
demands IS actually a copyright license agreement.

It is a disservice to discussion to conflate CLAs with copyright assignment.
Certainly there are further considerations, but to conflate the two from the
outset is destined to failure.

[ Reply to This | # ]

Comes v Microsoft
Authored by: Superbowl H5N1 on Wednesday, May 25 2011 @ 07:15 AM EDT

Comes v Microsoft Plaintiff's Exhibits go here.

---
Here's where you can get the computer RMS uses:
http://freedomincluded.com/

[ Reply to This | # ]

A CLA By Any Other Name
Authored by: webster on Wednesday, May 25 2011 @ 10:07 AM EDT
.

_________ "If a developer doesn't like the terms offered/imposed, they can
elect not to contribute or start their own project. Ahh, the freedom of
FOSS."__________

OR after reading the article propose their own. This is a good jump start for
any developer or lawyer. Thanks, Mark.

.

[ Reply to This | # ]

For KDE the other name is FLA
Authored by: steveire on Wednesday, May 25 2011 @ 03:51 PM EDT

Though not mandatory, contributors can assign copyright for works to KDE e.V (or in countries where that is not possible, grant a broad licence), for which a broad licence is assigned back to the contributor.

The possibilities for relicencing by KDE e.V is limited to weak or strong Free Software.

http://ev.kde.org/rules/fla.php

[ Reply to This | # ]

A CLA By Any Other Name - Updated
Authored by: Anonymous on Thursday, May 26 2011 @ 01:20 AM EDT
I think there is a fundamental misunderstanding involved here. I have a previous version of the assignment, and the sentence
The Foundation grants the Assigner non-exclusive rights to use the Work (i.e. the changes and enhancements, not the program which was enhanced) as it sees fit; this grant does not limit the Foundation's rights.
uses "it" to refer to "the Assigner". The restriction to the contributed changes and the last sentence part after the semicolon don't make any sense otherwise.

A rather stupid consequence of artificial gender-neutral pronoun use. Somebody should tell the FSF to replace "it" by "the Assigner" to remove a very obvious source of confusion.

[ Reply to This | # ]

Confusing
Authored by: Anonymous on Tuesday, June 07 2011 @ 04:05 PM EDT
Your article is confusing.

Copyright assignment is not a bad thing. If you do not assign a copyright, then
it becomes public domain?

Mono Project requires you to assign copyright, but this copyright could be
yourself or your employer or Novell. However, there was no foundation for the
Mono Project.

Mono's Licenses:
- Base Class Libraries: MIT/X11
- Tools: GPL
- Mono Runtime: LGPL

If you were not an employee of Novell and you wanted to contribute to the Mono
Runtime, you were required to contribute under the MIT/X11 license. However,
you were allowed to assign the copyright to yourself or your employer.

It looks like if you were an employee of Novell getting paid to work on Mono,
then you were required to assign copyright to Novell.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )