Hello Fedora! (Is this thing on?)
Sorry for the very wide net, but we wanted to make sure as many members of our community could see this as possible.
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
The full text of the FPCA, along with a FAQ, can be found here:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
Please, take a moment and read the FPCA and the FAQ. It is not a long, or overly complicated document, as legal documents go, but it is important that all Fedora Contributors read it over and make sure they understand it and like it (or can at least agree to it).
Fedora Legal wishes to give the Fedora community a window of time for discussion and review of the FPCA. This window is open until May 18, 2010 (2010-05-18). After that point, either a revised FPCA will be released for review, or we will begin the process of phasing in the FPCA and phasing out the Fedora ICLA.
Thanks in advance,
Tom "spot" Callaway, Fedora Legal
P.S. Fedora Legal would like to give a huge thank you to the people involved behind the scenes to make the FPCA possible. The primary author was Richard Fontana, with feedback from Tom Callaway, Pamela Chestek, Paul Frields, and Robert Tiller. Feel free to give them gifts (for example, drinks or tasty snacks) as thank yous, although, this is not a requirement (legal or otherwise). ;)
Hi Tom,
On Mon, Apr 19, 2010 at 22:21, Tom "spot" Callaway tcallawa@redhat.com wrote:
Fedora Legal wishes to give the Fedora community a window of time for discussion and review of the FPCA. This window is open until May 18, 2010 (2010-05-18).
""" Once a Later Default License has been designated, Your Unlicensed Contribution shall also be licensed to the Fedora Community under that Later Default License. Such designation shall not affect the continuing applicability of the Current Default License to Your Contribution. """
Let's say I submit a spec file after this FPCA is accepted : it is automatically licensed under the terms or the current default license: MIT.
A month later, the default license changes to GPLv3. If I understand the above paragraph correctly, this means that my spec file remains licensed as MIT, not GPLv3?
Now, if I update my package, and thus modify the spec file, does it remain forever under the terms of the MIT or does this new change constitutes a new contribution and hence, the spec file is now GPLv3? (it seems like the former would make it pretty hard to track what license each spec file^W^WContribution is under at a given time)
Not that I have any concerns about this, I would just like to understand correctly the FPCA (me not speak legalese fluent ;)
P.S. Fedora Legal would like to give a huge thank you to the people involved behind the scenes to make the FPCA possible. The primary author was Richard Fontana, with feedback from Tom Callaway, Pamela Chestek, Paul Frields, and Robert Tiller. Feel free to give them gifts (for example, drinks or tasty snacks) as thank yous, although, this is not a requirement (legal or otherwise). ;)
Which one of you will be at FUDCon EMEA in September? :)
---------- Mathieu Bridon
On Mon, Apr 19, 2010 at 10:51:21PM +0200, Mathieu Bridon wrote:
Let's say I submit a spec file after this FPCA is accepted : it is automatically licensed under the terms or the current default license: MIT.
A month later, the default license changes to GPLv3. If I understand the above paragraph correctly, this means that my spec file remains licensed as MIT, not GPLv3?
Actually, it becomes explicitly dual-licensed under MIT and GPLv3. (Since the MIT-license is universally considered GPL-compatible, this is not a very interesting dual license.)
Now, if I update my package, and thus modify the spec file, does it remain forever under the terms of the MIT or does this new change constitutes a new contribution and hence, the spec file is now GPLv3? (it seems like the former would make it pretty hard to track what license each spec file^W^WContribution is under at a given time)
The modified spec file is solely under GPLv3, in this example. The portions that were in the original spec file, if you can identify them, can be said to remain under the MIT license (in addition to GPLv3).
Not that I have any concerns about this, I would just like to understand correctly the FPCA (me not speak legalese fluent ;)
If there is any unnecessary legalese we should correct that; we tried to draft this so that it could be easily understood by Fedora contributors.
- RF
On Mon, Apr 19, 2010 at 3:21 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
Tom,
Since any choice of a single default license for code is likely to be viewed by some as making some sort of a statement could you explain a little bit about the rationale for selecting the MIT License variant that was chosen as the initial default covering code contributions that are submitted without license preference?
I presume Red Hat Legal is fine with any free license?! Who selected the MIT License?
Thanks, John
On Mon, Apr 19, 2010 at 08:11:54PM -0500, inode0 wrote:
On Mon, Apr 19, 2010 at 3:21 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
Tom,
Since any choice of a single default license for code is likely to be viewed by some as making some sort of a statement could you explain a little bit about the rationale for selecting the MIT License variant that was chosen as the initial default covering code contributions that are submitted without license preference?
I presume Red Hat Legal is fine with any free license?! Who selected the MIT License?
As far as I'm aware the MIT license provided the broadest possible compatibility with other free software licenses while being itself a fully free software license. Since there are a fairly narrow range (and small number) of code contributions that don't already fall under an explicit license, compatibility was a primary concern.
While Red Hat Legal, specifically our licensing counsel Richard Fontana, agrees with Fedora's overall stance and explicit rules on free licensing, as shown on our wiki, I'm certain he would agree that not every free license is equal in value for any given application. In this case, with compatibility being a primary concern, the MIT license seems better suited than some other free licenses.
The page Spot linked already has a list of everyone who participated in the draft. Spot hasn't talked about the ratification process, but I suspect it will look something like this:
* Any changes that come out of the RFC process will be mulled over by Spot, Richard, and possibly other counsel.
* Draft changes will be announced as follow-ups.
* Final approval should be made by the Fedora Board once the draft has stabilized and been given the nod by counsel.
On 04/19/2010 09:11 PM, inode0 wrote:
On Mon, Apr 19, 2010 at 3:21 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
Tom,
Since any choice of a single default license for code is likely to be viewed by some as making some sort of a statement could you explain a little bit about the rationale for selecting the MIT License variant that was chosen as the initial default covering code contributions that are submitted without license preference?
I presume Red Hat Legal is fine with any free license?! Who selected the MIT License?
I was the one who recommended MIT, because:
1. It is extremely permissive, possibly the most common "permissive" Free license. 2. Unlike many of the major common Free licenses (GPL, Apache, MPL), it is pretty much universally compatible with other Free licenses. 3. It is very very similar to the "license" that we were using for unlicensed contributions with the old Fedora ICLA.
That particular MIT variant was chosen on the merits of its legal wording.
When we looked at content licensing, there was a much smaller set of licenses to consider. We wanted to use a license that was permissive and as compatible as possible with other content licensing. That narrowed it down pretty quickly to the Creative Commons licenses, and given the fact that the wiki had already switched to CC-BY-SA, we decided to go with it. The waiver of clause 4d was done when Red Hat Legal determined it had the potential, if enacted, to make the work non-free.
And of course, it is important to note that this only applies to code contributions made without any licensing already in place. If you would prefer that a different license be used for your contribution (and you are the copyright holder), then by licensing your contribution explicitly, you avoid falling under this conditional. :)
With that said, if people feel strongly that a different license should have been used, we're certainly listening, and will take that feedback under advisement.
~spot
On Tue, Apr 20, 2010 at 08:58:52AM -0400, Tom spot Callaway wrote:
I was the one who recommended MIT, because:
- It is extremely permissive, possibly the most common "permissive"
Free license. 2. Unlike many of the major common Free licenses (GPL, Apache, MPL), it is pretty much universally compatible with other Free licenses. 3. It is very very similar to the "license" that we were using for unlicensed contributions with the old Fedora ICLA.
That particular MIT variant was chosen on the merits of its legal wording.
Fedora classifies a large set of closely-related licenses as 'MIT'. Most of these are actually legacy licenses. The variant we chose, however, is the de facto standard version of the MIT license today, and as such it is one of the most popular FOSS licenses. So that is an additional good feature of this license. We briefly thought about writing our own license, but on reflection this didn't seem like a good idea. We don't want to encourage license proliferation if we can avoid it; it was therefore important to choose a license that, today, is widely used.
When we looked at content licensing, there was a much smaller set of licenses to consider. We wanted to use a license that was permissive and as compatible as possible with other content licensing. That narrowed it down pretty quickly to the Creative Commons licenses, and given the fact that the wiki had already switched to CC-BY-SA, we decided to go with it. The waiver of clause 4d was done when Red Hat Legal determined it had the potential, if enacted, to make the work non-free.
Yes, this relates to some poor wording in an otherwise very good license (CC-BY-SA 3.0 Unported), with the potential for an undesirable interpretation not intended by the license drafters, and something ikely to be corrected in future versions of CC-BY-SA (CC-BY-SA 3.0 content is automatically relicensable to later versions of CC-BY-SA). Currently Fedora documentation is licensed out by Red Hat under CC-BY-SA 3.0 Unported with Red Hat making the same waiver.
For content licenses, we basically had four choices: (1) public domain dedication, (2) a Creative Commons license, (3) a non-widely-used content license, or (4) a free software license (like the MIT license). We decided against (1) because we want to make clear that the contributor retains copyright. We decided against (2) because we want to favor widely-used licenses and disfavor license proliferation, all else being equal. We decided against (4) because we felt that licenses specifically designed for software -- like the MIT license -- were not necessarily the most suitable choices for at least some typical kinds of content contributed to Fedora, at least if good licenses designed for content were available, as they are in the Creative Commons license set. Among the Creative Commons licenses, there were basically two choices, CC-BY and CC-BY-SA.
We don't think that CC-BY's relationship to CC-BY-SA is sufficiently analogous to that between MIT and GPL (and other strong copyleft licenses) to justify the choice of CC-BY based on a desire for license compatibility. Since CC-BY and CC-BY-SA therefore seemed roughly equal, we felt that a policy of promoting copyleft licensing where feasible, and the fact that it had been adopted for Fedora wiki content and docs with general enthusiasm (replacing the much disfavored OPL), justified the choice of CC-BY-SA.
On Tue, Apr 20, 2010 at 9:29 AM, Richard Fontana rfontana@redhat.com wrote:
We don't think that CC-BY's relationship to CC-BY-SA is sufficiently analogous to that between MIT and GPL (and other strong copyleft licenses) to justify the choice of CC-BY based on a desire for license compatibility. Since CC-BY and CC-BY-SA therefore seemed roughly equal, we felt that a policy of promoting copyleft licensing where feasible, and the fact that it had been adopted for Fedora wiki content and docs with general enthusiasm (replacing the much disfavored OPL), justified the choice of CC-BY-SA.
Richard,
Thank you very much for your remarks. I agree with a policy of promoting copyleft licensing where feasible and am happy to hear that was a consideration in the process.
My only concern about the CC-BY-SA follows from my understanding (which may or may not be correct) that it is incompatible with the GPL and would cause problems for small support and documentation files added to something covered by the GPL. If such files are not considered "content" by Fedora then that isn't an issue.
Thanks again.
John
On Tue, Apr 20, 2010 at 7:58 AM, Tom "spot" Callaway tcallawa@redhat.com wrote:
On 04/19/2010 09:11 PM, inode0 wrote:
On Mon, Apr 19, 2010 at 3:21 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
Tom,
Since any choice of a single default license for code is likely to be viewed by some as making some sort of a statement could you explain a little bit about the rationale for selecting the MIT License variant that was chosen as the initial default covering code contributions that are submitted without license preference?
I presume Red Hat Legal is fine with any free license?! Who selected the MIT License?
I was the one who recommended MIT, because:
- It is extremely permissive, possibly the most common "permissive"
Free license. 2. Unlike many of the major common Free licenses (GPL, Apache, MPL), it is pretty much universally compatible with other Free licenses. 3. It is very very similar to the "license" that we were using for unlicensed contributions with the old Fedora ICLA.
That particular MIT variant was chosen on the merits of its legal wording.
Thanks for this explanation. I see points 2 and 3 above as compelling reasons in support of the selected license. I'm sort of in the position of being completely satisfied with this if reason 1 above was fallout from reasons 2 and 3. If reason 1 was the starting point, I'm still wondering why there would be a default preference for a non-copyleft license.
When we looked at content licensing, there was a much smaller set of licenses to consider. We wanted to use a license that was permissive and as compatible as possible with other content licensing. That narrowed it down pretty quickly to the Creative Commons licenses, and given the fact that the wiki had already switched to CC-BY-SA, we decided to go with it. The waiver of clause 4d was done when Red Hat Legal determined it had the potential, if enacted, to make the work non-free.
Isn't CC-BY-SA copyleft, not permissive, and incompatible with the GPL?
One thing I've never been completely clear about is where the line is drawn in Fedora regarding what is code and what is content so I'm not sure if there are edge cases where the CC-BY-SA being incompatible with the GPL (assuming it is) would be an inconvenience.
While not as common, something like the GNU All-Permissive License seems like it might match your stated goals better in this case and is really quite similar in spirit to the MIT License selected for code. It isn't really a general content license but is intended for what is commonly understood to be documentation included with code.
And of course, it is important to note that this only applies to code contributions made without any licensing already in place. If you would prefer that a different license be used for your contribution (and you are the copyright holder), then by licensing your contribution explicitly, you avoid falling under this conditional. :)
Noted.
With that said, if people feel strongly that a different license should have been used, we're certainly listening, and will take that feedback under advisement.
Thanks for the feedback.
John
On Tue, Apr 20, 2010 at 09:50:07AM -0500, inode0 wrote:
While not as common, something like the GNU All-Permissive License seems like it might match your stated goals better in this case and is really quite similar in spirit to the MIT License selected for code. It isn't really a general content license but is intended for what is commonly understood to be documentation included with code.
I think we considered that one briefly, and it's worth considering again. The only drawback is that it is not a well-known and widely-used license like the MIT license (the modern variant) is, or like CC-BY-SA is. It would avoid the possible problem you have pointed to.
There's also an argument that the Creative Commons licenses are better for some kinds of creative content because they explicitly talk about public display and public performance rights, but perhaps that's more of a theoretical benefit in this context.
- RF
On Tue, Apr 20, 2010 at 2:02 PM, Richard Fontana rfontana@redhat.com wrote:
On Tue, Apr 20, 2010 at 09:50:07AM -0500, inode0 wrote:
While not as common, something like the GNU All-Permissive License seems like it might match your stated goals better in this case and is really quite similar in spirit to the MIT License selected for code. It isn't really a general content license but is intended for what is commonly understood to be documentation included with code.
I think we considered that one briefly, and it's worth considering again. The only drawback is that it is not a well-known and widely-used license like the MIT license (the modern variant) is, or like CC-BY-SA is. It would avoid the possible problem you have pointed to.
There's also an argument that the Creative Commons licenses are better for some kinds of creative content because they explicitly talk about public display and public performance rights, but perhaps that's more of a theoretical benefit in this context.
In all the cases where the content is not bundled with code I think the CC-BY-SA license is a superb choice, so I did not mean to suggest swapping it for the permissive license I mentioned except possibly in the case of bundling with code already covered by a different copyleft license. The MIT license used for code could also be used in such cases without problems I believe (and that would be the default if all such bundlings are defined as code by the FPCA which I'm just too dense to discern).
I am happy to leave that in the capable hands sorting through these issues now.
Thanks, John
First of all, thank you for your thoughts! This is exactly what I'd hoped for. :)
On 04/20/2010 10:50 AM, inode0 wrote:
Thanks for this explanation. I see points 2 and 3 above as compelling reasons in support of the selected license. I'm sort of in the position of being completely satisfied with this if reason 1 above was fallout from reasons 2 and 3. If reason 1 was the starting point, I'm still wondering why there would be a default preference for a non-copyleft license.
Yeah, the ordering there is closer to "3, 2, 1".
Also, there was the conscious thought that we wanted to:
* avoid issues of contention around default licensing (e.g. "How _dare_ you use this licensing! I didn't realize that would happen?!?") * motivate individuals who felt the default licensing was too broad to explicitly choose something more ... finer grained. I certainly think it is easier to nudge people in that direction than to have a more restrictive license as the unlicensed default. * ensure the greatest possible flexibility for future actions and use cases
When we looked at content licensing, there was a much smaller set of licenses to consider. We wanted to use a license that was permissive and as compatible as possible with other content licensing. That narrowed it down pretty quickly to the Creative Commons licenses, and given the fact that the wiki had already switched to CC-BY-SA, we decided to go with it. The waiver of clause 4d was done when Red Hat Legal determined it had the potential, if enacted, to make the work non-free.
Isn't CC-BY-SA copyleft, not permissive, and incompatible with the GPL?
I'm going to defer to Richard on the last point, but I can honestly say, the fact that CC-BY-SA is copyleft wasn't really a deciding factor. The biggest factor for me was that it was already in use for much of Fedora's content (e.g. art, wiki), and was already reasonably accepted (and presumably, understood).
It was never "okay, we want MIT, what is the content version of MIT". We wanted to try to address concerns around license proliferation (don't make a new license), compatibility (ensure that our choice is as compatible as possible with what is abundantly in use), and acceptability (will people be able to do what they need to do with the licensing terms, with the understanding that we may not be able to predict the range of use cases).
For code, those boundaries are far better understood than content.
One thing I've never been completely clear about is where the line is drawn in Fedora regarding what is code and what is content so I'm not sure if there are edge cases where the CC-BY-SA being incompatible with the GPL (assuming it is) would be an inconvenience.
Well, we tried to define that in the FPCA, when we say "'Content' means any copyrightable material that is not Code", because it is simpler to define what is Code and say that everything else is Content, with the reserved right of the Fedora Board to classify things that may be less clear cut.
While not as common, something like the GNU All-Permissive License seems like it might match your stated goals better in this case and is really quite similar in spirit to the MIT License selected for code. It isn't really a general content license but is intended for what is commonly understood to be documentation included with code.
Eh. I'm not sure it is. I do think that the common areas of content are worth targeting here, and trying to deal with in a focused manner. I posit that those areas are:
* documentation * wiki pages * artwork * music
I suspect that if pressed, the FSF would agree that the All-Permissive license (which in Fedora licensing lingo would be "Copyright only") is not necessarily a good fit for those items, preferring the FDL for docs and i dunno what for the rest.
After all, we're not proposing to go with Public Domain (or Public Domain-esque CC-Zero licensing) here, which would arguably be as permissive as possible.
In the area of content, it has been my experience that contributors in Fedora are concerned about attribution and reciprocity. They are also far more likely to not be easily able to explicitly license as part of the work (think art), and thus, fall into the default licensing language. From my perspective, using CC-BY-SA is a good fit for that specific use case.
~spot
On Mon, 2010-04-19 at 16:21 -0400, Tom "spot" Callaway wrote:
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
The full text of the FPCA, along with a FAQ, can be found here:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
I like the FPCA. It addresses a specific problem (default licensing) and solves it in a simple way. Consider this a "+1" karma point.
My only suggestion: Standardize a short name for the "CC-BY-SA 3.0 with 4d waived" license on https://fedoraproject.org/wiki/Licensing:Main so that it is easier to track accurately. And it would be worth explicitly pointing out that the copyleft allows derivative works to be licensed without the waiver, just like a GPL exception.
On Mon, 2010-04-19 at 16:21 -0400, Tom "spot" Callaway wrote:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
Actually, I do have a question. The default license for code is non-copyleft, while the default license for content is copyleft. What is the rationale for this apparently significant difference in treatment of the two kinds of contributions?
Tom "spot" Callaway wrote:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
One minor detail: The definition of "Submit" uses the term "electronic communication". Couldn't someone use that as a loophole and claim that they didn't Submit their Contribution because they sent it through optical fibers so it was optical communication and not electronic communication? Writing "digital communication" instead should close the loophole.
Björn Persson
On 04/20/2010 11:35 AM, Björn Persson wrote:
Tom "spot" Callaway wrote:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
One minor detail: The definition of "Submit" uses the term "electronic communication". Couldn't someone use that as a loophole and claim that they didn't Submit their Contribution because they sent it through optical fibers so it was optical communication and not electronic communication? Writing "digital communication" instead should close the loophole.
Definitely something to consider, thanks. I suspect the former is legal boilerplate of sorts, which is why it was used, but we'll look into it.
~spot
On Tue, Apr 20, 2010 at 02:02:02PM -0400, Tom spot Callaway wrote:
On 04/20/2010 11:35 AM, Björn Persson wrote:
Tom "spot" Callaway wrote:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
One minor detail: The definition of "Submit" uses the term "electronic communication". Couldn't someone use that as a loophole and claim that they didn't Submit their Contribution because they sent it through optical fibers so it was optical communication and not electronic communication? Writing "digital communication" instead should close the loophole.
Definitely something to consider, thanks. I suspect the former is legal boilerplate of sorts, which is why it was used, but we'll look into it.
It was the survival of some language from the definition of "submit" in the Apache ICLA, on which the existing Fedora ICLA is based. "Digital" may indeed be a preferable term to use there.
- RF
On Mon, Apr 19, 2010 at 04:21:42PM -0400, Tom spot Callaway wrote:
The full text of the FPCA, along with a FAQ, can be found here:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
Please, take a moment and read the FPCA and the FAQ. It is not a long, or overly complicated document, as legal documents go, but it is important that all Fedora Contributors read it over and make sure they understand it and like it (or can at least agree to it).
Fedora Legal wishes to give the Fedora community a window of time for discussion and review of the FPCA. This window is open until May 18, 2010 (2010-05-18). After that point, either a revised FPCA will be released for review, or we will begin the process of phasing in the FPCA and phasing out the Fedora ICLA.
Spot,
One of the contribution types that's always been a bit hazy is photographs of people. Often our contributors have photos they are willing to share of themselves and each other for use on the wiki. An example is the one-page release notes seen here:
https://fedoraproject.org/wiki/Fedora_12_one_page_release_notes
All the people in those photos have release forms on file, but collecting these release forms is non-trivial and sometimes a bit momentum killer. Is it possible for the FPCA to address this situation?
On Mon, Apr 26, 2010 at 6:44 AM, Paul W. Frields stickster@gmail.com wrote:
On Mon, Apr 19, 2010 at 04:21:42PM -0400, Tom spot Callaway wrote:
The full text of the FPCA, along with a FAQ, can be found here:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
Please, take a moment and read the FPCA and the FAQ. It is not a long, or overly complicated document, as legal documents go, but it is important that all Fedora Contributors read it over and make sure they understand it and like it (or can at least agree to it).
Fedora Legal wishes to give the Fedora community a window of time for discussion and review of the FPCA. This window is open until May 18, 2010 (2010-05-18). After that point, either a revised FPCA will be released for review, or we will begin the process of phasing in the FPCA and phasing out the Fedora ICLA.
Spot,
One of the contribution types that's always been a bit hazy is photographs of people. Often our contributors have photos they are willing to share of themselves and each other for use on the wiki. An example is the one-page release notes seen here:
https://fedoraproject.org/wiki/Fedora_12_one_page_release_notes
All the people in those photos have release forms on file, but collecting these release forms is non-trivial and sometimes a bit momentum killer. Is it possible for the FPCA to address this situation?
Are the release forms generally related to "Yes, we really are allowed to use this content" (created by the person who has signed the FPCA) - or are they related to "yes, you can use this picture of my face" - which generally (I would guess?) is a person who was the subject of a photo taken by someone ELSE who had signed the FPCA?
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ legal mailing list legal@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/legal
On 04/26/2010 10:48 AM, Robyn Bergeron wrote:
Are the release forms generally related to "Yes, we really are allowed to use this content" (created by the person who has signed the FPCA) - or are they related to "yes, you can use this picture of my face" - which generally (I would guess?) is a person who was the subject of a photo taken by someone ELSE who had signed the FPCA?
Yes and yes, although, the latter is the one that we really need the release for.
~spot
On Mon, Apr 19, 2010 at 4:21 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
Hello Fedora! (Is this thing on?)
Sorry for the very wide net, but we wanted to make sure as many members of our community could see this as possible.
For some time now, Fedora has been working with Red Hat Legal to come up with a replacement for the Fedora Individual Contributor License Agreement (aka, the Fedora ICLA). As a result, the Fedora Project Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is now being presented to the Fedora Community for comments and discussion.
The full text of the FPCA, along with a FAQ, can be found here:
https://fedoraproject.org/wiki/Legal:Revised_Fedora_CLA_Draft
Please, take a moment and read the FPCA and the FAQ. It is not a long, or overly complicated document, as legal documents go, but it is important that all Fedora Contributors read it over and make sure they understand it and like it (or can at least agree to it).
Fedora Legal wishes to give the Fedora community a window of time for discussion and review of the FPCA. This window is open until May 18, 2010 (2010-05-18). After that point, either a revised FPCA will be released for review, or we will begin the process of phasing in the FPCA and phasing out the Fedora ICLA.
Thanks in advance,
Tom "spot" Callaway, Fedora Legal
P.S. Fedora Legal would like to give a huge thank you to the people involved behind the scenes to make the FPCA possible. The primary author was Richard Fontana, with feedback from Tom Callaway, Pamela Chestek, Paul Frields, and Robert Tiller. Feel free to give them gifts (for example, drinks or tasty snacks) as thank yous, although, this is not a requirement (legal or otherwise). ;) -- ambassadors mailing list ambassadors@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ambassadors
I apologize for coming to this party late. I started thinking about the recent move of fp.o's content to CC-BY-SA using the 'nuclear option.' for changing license.
The proposed FPCA seems to eliminate license changes except for explicitly unlicensed content. (as oxymoronic as explicitly unlicensed sounds). So for instance, current Docs Projects are explicitly licensed CC-BY-SA 3.0 Unported. In the event that CC-BY-SA 4.0 (or $othercoolcontentlicenseinfavor) was 50% more awesome and we wanted to move to it, it would seem that the 'nuclear option' for doing so would not exist.
So first, is my above understanding correct? Second, if so, are we sure we want to give up the ability to change wiki and documentation licensing.
If I am way off base feel free to say so.
David Nalley
On Wed, May 19, 2010 at 10:54:26PM -0400, David Nalley wrote:
I started thinking about the recent move of fp.o's content to CC-BY-SA using the 'nuclear option.' for changing license.
The proposed FPCA seems to eliminate license changes except for explicitly unlicensed content. (as oxymoronic as explicitly unlicensed sounds). So for instance, current Docs Projects are explicitly licensed CC-BY-SA 3.0 Unported. In the event that CC-BY-SA 4.0 (or $othercoolcontentlicenseinfavor) was 50% more awesome and we wanted to move to it, it would seem that the 'nuclear option' for doing so would not exist.
So first, is my above understanding correct? Second, if so, are we sure we want to give up the ability to change wiki and documentation licensing.
The draft FPCA is intended in large part to codify the Fedora Project interpretation of the existing Fedora CLA, as I think Spot pointed out. I suppose that what's different about Fedora documentation and wiki content is that Fedora publicized, and continues to publicize, the specific licensing policy for such content (OPL, and later CC-BY-SA). I think it would be better to clarify the distinction between inbound and outbound licensing in places like https://fedoraproject.org/wiki/DocsProject#Documentation_licensing and https://fedoraproject.org/wiki/Legal/Licenses#This_Website (I'll edit the first page).
Given the established interpretation of the Fedora CLA by Fedora Legal, the 'nuclear option' was applied on the assumption that, regardless of such statements about licensing policy, documentation and wiki content contributions were, with rare exceptions, "Unlicensed" in the sense used in the FPCA and thus the contributor granted the broad copyright license "to Red Hat, Inc., on behalf of [Fedora], and to recipients of software distributed by [Fedora]". Thus, under the existing Fedora CLA, Red Hat (and, in fact, all other Fedora community members) had permission to license out most, if not all, docs contributions under the OPL, and under CC-BY-SA too. I don't think the fact that Fedora publicized its documentation licensing policy is inconsistent with the notion that contributors voluntarily kept their contributions "Unlicensed".
So actually I think that if the draft FPCA had been in place all this time, but say with the OPL as the 'Default License' for content, Fedora would have been able to exercise the 'nuclear option' by designating a new Default License.
Note BTW that CC-BY-SA 3.0 explicitly allows 'Adaptations' to be licensed under "a later version of this License with the same License Elements as this License". .
On Wed, May 19, 2010 at 11:49:52PM -0400, Richard Fontana wrote:
Given the established interpretation of the Fedora CLA by Fedora Legal, the 'nuclear option' was applied on the assumption that, regardless of such statements about licensing policy, documentation and wiki content contributions were, with rare exceptions, "Unlicensed" in the sense used in the FPCA and thus the contributor granted the broad copyright license "to Red Hat, Inc., on behalf of [Fedora], and to recipients of software distributed by [Fedora]". Thus, under the existing Fedora CLA, Red Hat (and, in fact, all other Fedora community members) had permission to license out most, if not all, docs contributions under the OPL, and under CC-BY-SA too.
A clarification here: *Red Hat*-copyrighted contributions did not come in under the Fedora CLA. However, all Red Hat-copyrighted contributions to Fedora docs that were previously licensed under the OPL are now also available under CC-BY-SA 3.0, so the statement in my last sentence there is correct.
- RF
On Wed, May 19, 2010 at 11:49:52PM -0400, Richard Fontana wrote:
Note BTW that CC-BY-SA 3.0 explicitly allows 'Adaptations' to be licensed under "a later version of this License with the same License Elements as this License". .
That is what brought be comfort during the relicensing process. I didn't like the implications of the Fedora Project able to potentially and arbitrarily relicense works without any other oversight or guidance.[1] But the OPL didn't have the above clause the CC does. I'm now comfortable that we can protect our free and open content with the CC license alone, and if another default license is chosen in the future, it will be fundamentally similar, thereby protecting the freeness.
- Karsten
[1] Even while I was the one calling for using the 'nuclear option'.