http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is pretty clear:
---- Duplicate Files
A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline. ----
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
Can we make a clear determination as to whether there are circumstances where duplication of license files is permitted, and clearly outline those situations in the guidelines? My understanding of the current opinion from the legal folks is that we must duplicate the license files if there's no clear dependency chain between the packages. Otherwise I think that we have enough duplicated copies of the GPL floating around and we should try to keep the number down where we can.
- J<
On 11/08/2009 03:10 AM, Jason L Tibbitts III wrote:
http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is pretty clear:
Duplicate Files
A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
Can we make a clear determination as to whether there are circumstances where duplication of license files is permitted, and clearly outline those situations in the guidelines? My understanding of the current opinion from the legal folks is that we must duplicate the license files if there's no clear dependency chain between the packages. Otherwise I think that we have enough duplicated copies of the GPL floating around and we should try to keep the number down where we can.
How about something like this:
* For binary RPMs, the complete set of license files (as provided by upstream) must be included in the %doc section of either the main binary rpm or a common RPM that the other binary sub-packages depend on. Independent sub-packages are required to include their own copy of the relevant license texts (as provided by upstream).
~spot
"TC" == Tom "spot" Callaway tcallawa@redhat.com writes:
TC> * For binary RPMs, the complete set of license files (as provided by TC> upstream) must be included in the %doc section of either the main TC> binary rpm or a common RPM that the other binary sub-packages depend TC> on. Independent sub-packages are required to include their own copy TC> of the relevant license texts (as provided by upstream).
Seems fine to me as long as we otherwise stick to our prohibition on file duplication. Do we need to somehow define "license files"? If documentation specifies "this is GPL", does that make it a license file? Does the presence of a COPYING file change the answer? (I know, it's a relatively pointless question, but I know with certainty that it won't be too long before it is asked in a package review.)
- J<
On 11/11/2009 01:44 AM, Jason L Tibbitts III wrote:
Seems fine to me as long as we otherwise stick to our prohibition on file duplication. Do we need to somehow define "license files"? If documentation specifies "this is GPL", does that make it a license file? Does the presence of a COPYING file change the answer? (I know, it's a relatively pointless question, but I know with certainty that it won't be too long before it is asked in a package review.)
I've had the idea for some time that it would be ideal if rpm supported something like this:
%files %doc foo bar %license COPYING
That would make it clear what the license file is, from an RPM perspective. From a definition perspective, I define a license file as:
"A copy of the legal text which defines the copyright on the work and the permissions or restrictions placed upon that work by the copyright holder(s)."
So, COPYING (where COPYING is a copy of the GPLv3 license text) is a license file. A README.txt which simply says "This code is under GPLv3." is not a license file.
Worth mentioning in the Licensing guidelines?
~spot
We should run a program that dedupes files in /usr/share/doc, automaticallyq replacing identical files with hard links[0]. There are a number of these sorts of programs, "fdupes" being one that we have in Fedora.
A quick calculation running "fdupes -r /usr/share/doc" on my Fedora 12 desktop machine, and some analysis:
* 3484 files could be replaced by hard links (that count doesn't include the single remaining copy of the file).
* Total files in /usr/share/doc is 31887, so that is 11% of all files in that directory.
* Deduping would save 38896 (1K blocks) out of 473748 blocks used (about 8%). [1]
By no means all the duplicates in /usr/share/doc are just license files. Many other types of file are also duplicated, including many images.
Rich.
[0] One day filesystems will do this for us automatically and transparently ...
[1] Assumption: storing the directory entry and inode is free.
On 11/14/2009 10:40 AM, Richard W.M. Jones wrote:
We should run a program that dedupes files in /usr/share/doc, automaticallyq replacing identical files with hard links[0]. There are a number of these sorts of programs, "fdupes" being one that we have in Fedora.
Really, RPM should do this as part of the transaction. If the file marked as %license in the package matches an identical file in %licensedir, hard link. If not, install.
I've been meaning to open a ticket with RPM upstream for this for... oh, about forever. :) I'll bump it to the top of my todo pile.
~spot
On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote:
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
And it'll keep coming up in future too.
We are distributing binary packages which you can download independently from http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packa... using just a web browser or 'wget'. Web browsers and wget don't understand RPM dependencies, and RPM files can be unpacked by a variety of software, not just the rpm program.
Some of those binary packages have the license stripped from them. The GPLv2 clearly says you should not do this:
1. [...] and give any other recipients of the Program a copy of this License along with the Program.
Rich.
On Sat, Nov 14, 2009 at 03:46:02PM +0000, Richard W.M. Jones wrote:
On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote:
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
And it'll keep coming up in future too.
We are distributing binary packages which you can download independently from http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packa... using just a web browser or 'wget'. Web browsers and wget don't understand RPM dependencies, and RPM files can be unpacked by a variety of software, not just the rpm program.
Some of those binary packages have the license stripped from them. The GPLv2 clearly says you should not do this:
- [...] and give any other recipients of the Program a copy of this
License along with the Program.
So if legal says that it's okay to rely on rpm dependencies to do this for us, you'd still insist on doing your own thing?
-Toshio
On Mon, Nov 16, 2009 at 07:55:43PM -0800, Toshio Kuratomi wrote:
On Sat, Nov 14, 2009 at 03:46:02PM +0000, Richard W.M. Jones wrote:
On Sat, Nov 07, 2009 at 11:10:34AM -0600, Jason L Tibbitts III wrote:
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
And it'll keep coming up in future too.
We are distributing binary packages which you can download independently from http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packa... using just a web browser or 'wget'. Web browsers and wget don't understand RPM dependencies, and RPM files can be unpacked by a variety of software, not just the rpm program.
Some of those binary packages have the license stripped from them. The GPLv2 clearly says you should not do this:
- [...] and give any other recipients of the Program a copy of this
License along with the Program.
So if legal says that it's okay to rely on rpm dependencies to do this for us, you'd still insist on doing your own thing?
If it was brought to their attention that there is other software that can unpack individual RPMs, and they gave a detailed response (not just "okay"), then I'd be interested in reading that response. Nuanced legal opinions are always interesting to read.
Rich.
On Sat, Nov 7, 2009 at 12:10 PM, Jason L Tibbitts III wrote:
http://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files is pretty clear:
Duplicate Files
A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.
However, some packagers absolutely insist on duplicating license files (say, once in the main package, and again in the -devel package) and this issue keeps coming up.
Suppose the license of the corresponding software states that the COPYING file must be distributed in all derived work of the software. There is no problem with -devel packages since they pull the main package and the COPYING file makes its way to the target. But what if there is a -tools subpackage that does not require the main package? When you install the -tools subpackage, the COPYING file will not get installed. Thus the license is violated.
Where am I wrong?
Orcan
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Orcan Ogetbil -
Richard W.M. Jones -
Tom Callaway -
Toshio Kuratomi