License of .spec files

[David Cantrell]

On Sun, 19 Aug 2007 09:52:20 -0400
"Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:

> On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote:
> > Hello all,
> > 
> > I have a question, probably for spot, what's the license of .spec file
> > it-self? Is it under license of a product or indirectly signed by CLA?
> > Is it a good idea to include the license specification about the spec
> > file in the .spec file?
> 
> FWIW, licensing the .spec files never made much sense to me.
> 
> 1. There's very little original copyrightable work in a spec file.
> 2. The license of the spec file itself would have nothing to do with the
> contents of the RPM, other than that the spec file would also be
> included as a separate file inside the RPM. So, the spec file is not
> automatically under the same license as the bits being packaged up.

But I think it does.  In GPLv2, there was always this paragraph:

"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

The 'plus the scripts used to control compilation and installation of the executable' meant what you, the packager, used to create the executable you are delivering to the recipient.

The FSF has certainly looked the other way with this clause and I'm not sure [that I even care] what the GPLv3 says about this.  Many commercial vendors ship tarballs+patches and claim the 'scripts used to control compilation of the exectuable' are the Makefile templates and configure scripts.  Sure, I guess, but what did _you_ run to get the executable you are delivering to me.  A spec file definitely delivers more information about how we constructed the package we are handing the customer, which in my opinion is actually how you should comply with the terms of the GPLv2.

> There really is no need to sublicense the spec files, but you're
> permitted to do so if you're so motivated. I highly suggest that you do
> not, because it will confuse others.

I think it should be consider part of the complete source code for GPL projects.  That aside, the spec files _are_ the instructions for the distribution, if not intertwined and confusing.  But they document what we do to construct the distribution.  Should that collection of knowledge not be licensed?

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Westford, MA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070820/9ffb4c12/attachment.sig>