Bug 1096434

Summary: Changes to legal information in fedora-release
Product: [Fedora] Fedora Reporter: Richard Fontana <rfontana>
Component: fedora-releaseAssignee: Dennis Gilmore <dennis>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: rawhideCC: bcl, bruno, dennis, extras-orphan, fweimer, gholms, herrold, jdisnard, mattdm, msivak, notting, pahan, rfontana, rtiller, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1001394 Environment:
Last Closed: 2014-05-10 16:56:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 182235    
Attachments:
Description Flags
LICENSE file to replace GPL file
none
Revised version of Fedora-Legal-README.txt none

Description Richard Fontana 2014-05-10 05:14:30 UTC 
Created attachment 894206 [details]
LICENSE file to replace GPL file

Red Hat Legal would like to request the following changes be made to fedora-release:

1) Delete the file "GPL".

2) Add the file "LICENSE" (see attachment)

3) Replace the file "Fedora-Legal-README.txt" with the modification attached to the comment below.

4) Change the License: tag in the spec file to MIT.

If the package maintainer wishes to indicate that solely the contents of fedora-release itself are licensed under GPLv2, this is acceptable but then Red Hat Legal would like it to be clarified that this GPL license is not a compilation license applicable in some sense to Fedora as a whole. This would require modification of the above request. My personal view is that there wouldn't be much point to this given the nature of the contents of fedora-release.

If the package maintainer would like to preserve the historical notion that Fedora as a compilation is released under GPLv2, this too is acceptable to Red Hat Legal provided that instead of following the above request, the package maintainer indicates in the file "Fedora-Legal-README.txt" that the GPL comes from the package maintainer individually (e.g. by putting the notice "Copyright 2014 Dennis Gilmore" at the top). There is some basis for arguing that if the compilation license comes from anyone it is from the package maintainer (as opposed to Red Hat). In such a case Red Hat requests that "GPLv2" in the spec file be replaced with "GPLv2+". However, I note that the package maintainer stated a desire for relaxation of source code availability requirements in the message
https://lists.fedoraproject.org/pipermail/legal/2014-February/002384.html
which is arguably at odds with at least some interpretations of the notion of a GPL-licensed compilation.

I discussed some of the policy arguments for this license change in BZ# 1001394. I'd in addition note that since 2010 Fedora has used a contributor agreement under which contributions are by default licensed under the MIT license. It seems fitting then that any compilation license for Fedora should be under the MIT license. Indeed this may be regarded as an overdue compliance with FPCA section 3 last paragraph (see: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement#FPCA_Text).
Comment 1 Richard Fontana 2014-05-10 05:33:03 UTC 
Created attachment 894207 [details]
Revised version of Fedora-Legal-README.txt

This revises the file to indicate that the compilation is under the MIT license, but that all code and content remains under its appropriate license, and that the licenses of such code and content conform to specific licensing guidelines published by the Fedora Project.

In addition the contact information for the source offer has been updated to reflect the change in Red Hat's headquarters address and to specify the Vice President, Intellectual Property as the contact.
Comment 2 Bruno Wolff III 2014-05-10 14:56:59 UTC 
Do similar changes need to be made to generic-release?
It has a GPL file and GPLv2 as a license tag.
Since it is pretty much just the spec file, public keys and some very shirt files indicating this is a generic release, I don't think the license is a big concern, though I don't know what legal requirements there would be in changing the license for this stuff.
Comment 3 Richard Fontana 2014-05-10 15:43:02 UTC 
(In reply to Bruno Wolff III from comment #2)
> Do similar changes need to be made to generic-release?
 
Yes, generic-release should be changed to match whatever changes are made to fedora-release. For example, if my suggestion is adopted, then the 'GPL' file in generic-release should be deleted and a LICENSE file identical to that suggested in the first attachment herein should be used in its place; similarly the spec file tag should be changed to MIT.

On the other hand, in the event the fedora-release maintainer wishes to *maintain* GPL licensing of either just the contents of fedora-release, or the appearance of GPL licensing of the Fedora compilation as a whole, or both, then that is fine but it would entail adding some sort of clarification file to generic-release to indicate that (as applicable) (i) the contents of generic-release are licensed under GPLv2-or-later, but not the compilation (which would be governed by the MIT license); (ii) the Fedora compilation is governed by GPLv2-or-later, but that license is from the individual package maintainer of fedora-release to the extent of the maintainer's personal copyright interest in Fedora as a compilation, and not from Red Hat. Thus in this case (ii) there would be some additional COPYRIGHT file in generic-release that would say "Copyright 2014 Dennis Gilmore", or something along those lines, to make clear that Red Hat itself isn't subjecting the compilation to the GPL.
Comment 4 Dennis Gilmore 2014-05-10 16:56:58 UTC 
I have accepted all of legals changes as is.

Bruno generic-release needs quite a bit of work. which is difficult because you have not followed the standard procedures for updating.