...

...

...

...

"TJ" == Tim Jackson lists@timj.co.uk writes:

TJ> If the license file isn't distributed with the package, we should TJ> have a clear policy: either we pull it in from an external source TJ> (maybe if that's "reasonably" possible, i.e. it's distributed on a TJ> public URL as a standalone file), or we don't.

Hundreds of Perl modules do not include the license text. Most of those are under the same terms as Perl (GPL or Artistic). It is trivial to generate them via perldoc and include them in the package, but this is essentially never done because of the sheer redundancy having the same text in hundreds of modules.

When doing reviews, the only time I will request that license text be added to the package when it isn't in the tarball is if the license is not one of the commonly seen licenses or if the license itself is variable. So if you're adding clauses to BSD or you're using the historical permission and disclaimer (which is a multiple-choice thing) or if your package says "These files are under the RandomCrapWare license" then I'll want to see it.

At some point it has to come down to common sense. Unfortunately I suspect that excessive formalization will lead to us having a list of licenses which are acceptable to not include if they aren't in the tarball.

- J<

On Thu, 2006-06-29 at 08:43 +0100, Paul Howarth wrote:

On Wed, 2006-06-28 at 23:13 +0100, Tim Jackson wrote:

...

There seems to be some confusion about including the license file in a package. I have been told two more-or-less contradictory things in two very similar packages. Unfortunately I can't find the wiki citation about this right now, but...

php-pear-DB (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733):

"You do not have to bring in the license from an external source."

php-pear-PEAR-Command-Packaging (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423):

"SHOULD FIX: Include actual license in %doc"

OK, so they're not actually contradictory. But we really ought to have some consistency here. If the license file isn't distributed with the package, we should have a clear policy: either we pull it in from an external source (maybe if that's "reasonably" possible, i.e. it's distributed on a public URL as a standalone file), or we don't. Otherwise we just lengthen package reviews and cause the precious time of packagers to be wasted with repeated pointless discussions and re-spins of packages.

I really don't care what the policy is - I don't mind whether or not I have to pull external license files into my packages, I just think there should be an unambiguous policy so that I don't have to have this debate every time I do a package. Plus we have at least some consistency for users.

The policy is very clear IMHO:

http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines

MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.

Forgot to add: there's also this:

SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.

So upstream should be requested to add the license text in their distribution, but the package need not contain it until upstream does this.

In the special case of the package maintainer being the same as upstream, I think there is merit is pushing a bit harder for this.

Paul.

On Thu, 2006-06-29 at 13:12 +0100, Tim Jackson wrote:

Paul Howarth wrote:

...

SHOULD: If the source package does not include license text(s) as
        a separate file from upstream, the packager SHOULD query
        upstream to include it.

So upstream should be requested to add the license text in their distribution, but the package need not contain it until upstream does this.

Indeed, and getting license files in upstream packages is certainly a Good Thing in the general case. However, this ignores the case where (rightly or wrongly) it is not normally done upstream. (e.g. PEAR), probably because for tiny modules like PEAR modules where they are often installed in relatively large numbers, you would end up with a large number of duplicated license fields.

...

In the special case of the package maintainer being the same as upstream, I think there is merit is pushing a bit harder for this.

I agree. In this particular case, I have no problem in including the license text in the package upstream, but at the same time I believe it's not conventionally done, so by the same consistency logic I probably shouldn't make one PEAR module be special, *just because* I happen to be maintaining a Fedora package for it. (I'm not saying there isn't necessarily a general argument for including license files in every module, just that that doesn't appear to be the convention at the moment, so even if I solve this particular issue by including it, there are millions of other modules out there that don't).

It's very common for perl modules not to include the license text too, but in the cases where the upstream has included it, the Extras packages also include it as %doc. This does tend to result in a very number of copies of, for instance, the GPL, but the space taken up by these is still very, very small as a proportion of the size of the distribution, and anyone that's really struggling for space always has the option of installing packages using rpm's --excludedocs option.

Paul.