Bug 820334

Summary:	Incorrect license tag in spec file
Product:	[Fedora] Fedora	Reporter:	Jonathan Underwood <jonathan.underwood>
Component:	cmake	Assignee:	Orion Poplawski <orion>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	hobbes1069, jreznik, ltinkl, orion, pertusus, pmachata, rdieter
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-10 13:14:59 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:

Description Jonathan Underwood 2012-05-09 16:24:08 UTC

Description of problem:
Currently the license tag in the spec file is BSD, but as Richard Shaw pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=819678#c5 the licensing is a bit more complicated:

$ licensecheck -r . | awk 'match($0,":"){print substr($0,RSTART+2)}' | sort |
uniq -c | sort -g -r
    768 UNKNOWN
    636 *No copyright* UNKNOWN
    105 BSD (2 clause)
     90 GENERATED FILE
     37 MIT/X11 (BSD like)
     19 zlib/libpng
     11 *No copyright* GENERATED FILE
      9 BSD (3 clause)
      4 GPL (with incorrect FSF address)
      2 ISC
      2 GPL (v3 or later)
      2 GPL
      2 BSD (4 clause)
      2 BSD (2 clause) GENERATED FILE
      1 *No copyright* ISC

The GPL 3 or later files are bison generated parsers which have an exception granting redistribution under terms of your choice, so these are not incompatible with the GPLv2+ files. However, as Richard says, the license tag should probably be

BSD and MIT and GPLv2+ and zlib

Comment 1 Rex Dieter 2012-05-10 12:36:03 UTC

Let's look at which files of these are actually used... :)

I believe the zlib/libpng is largely bundled copies of libs, that we don't use due to --system-libs build flag, though there is Source/kwsys/MD5.c that I'll look into separately.

Wrt GPL these all seem to come from bison.

Then we have a bunch of stuff in Source/CursesDialog/form/ that is MIT/X11 (BSD like)

Comment 2 Jonathan Underwood 2012-05-10 13:11:07 UTC

(In reply to comment #1)
> Let's look at which files of these are actually used... :)
> 
> I believe the zlib/libpng is largely bundled copies of libs, that we don't use
> due to --system-libs build flag, though there is Source/kwsys/MD5.c that I'll
> look into separately.
> 
> Wrt GPL these all seem to come from bison.
> 
> Then we have a bunch of stuff in Source/CursesDialog/form/ that is MIT/X11 (BSD
> like)

Right - but shouldn't the License tag reflect what is distributed in the SRPM? Or is it meant to reflect the code that's used in the binary rpms? I can see arguments both ways...

Comment 3 Rex Dieter 2012-05-10 13:14:59 UTC

I'm firmly in the "reflect code that's used in the binary rpms" camp.  :)


OK, MD5.c is bundled(md5-deutsch), see 
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#cite_note-1

So, I'd advocate going with

# most sources are BSD
# Source/CursesDialog/form/ a bunch is MIT 
# Source/kwsys/MD5.c is bundled(md5-deutsch) and zlib licensed
# some GPL-licensed bison-generated files, these all include an exception granting redistribution under terms of your choice
License:        BSD and MIT and zlib


# Source/kwsys/MD5.c
# see https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Provides: bundled(md5-deutsch)



%changelog
* Thu May 10 2012 Rex Dieter <rdieter> 2.8.8-3
- Incorrect license tag in spec file (#820334)

Comment 4 Rex Dieter 2012-05-10 13:18:03 UTC

See also,
https://fedoraproject.org/wiki/Licensing/FAQ#Multiple_licensing_situations

"... So, if you are comfortable calculating the effective license it can be helpful to others to use that in the License: field. If you're not comfortable, or you wish to be precise in how you populate the License: field, you may list all of the licenses in the source that were compiled together to make the combined work in the binary rpm. "

Note the *binary rpm* part. :)

Comment 5 Jonathan Underwood 2012-05-10 13:34:10 UTC

OK, excellent - thanks for the clarification and the education :).