Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 166189
Summary: | Review Request: perl-Class-DBI-Loader-Relationship : Easier relationship specification in CDBI::L | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom "spot" Callaway <tcallawa> |
Component: | Package Review | Assignee: | Paul Howarth <paul> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://search.cpan.org/dist/Class-DBI-Loader-Relationship/ | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-14 18:45:37 UTC | Type: | --- |
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: | 166188 | ||
Bug Blocks: | 163779, 166203 |
Description
Tom "spot" Callaway
2005-08-17 20:32:21 UTC
Cleaned up based on other Maypole fixes: New SPEC: http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship.spec New SRPM: http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship-1.2-3.src.rpm I can't find any trace of licensing terms in the upstream tarball for this package... Review: - rpmlint clean - package and spec naming OK - package meets guidelines - spec file written in English and is legible - sources match upstream - package builds OK in mock for FC4 (i396) - BR's OK - no locales, libraries, subpackages or pkgconfigs to worry about - not relocatable - no duplicate files - no directory ownership or permissions issues - %clean section present and correct - macro usage is consistent - no large docs - docs don't affect runtime - no scriptlets - no .desktop file needed - code, not content Needswork: - I can't find any trace of licensing terms for this package. Where did you find the "same terms as perl" license info? I sent an email to the upstream maintainer, but have yet to receive a response. I'll change this to "Distributable" before I commit. (In reply to comment #4) > I sent an email to the upstream maintainer, but have yet to receive a response. > > I'll change this to "Distributable" before I commit. I guess that's OK since everything on CPAN is required to be free (as in beer) software. However, doesn't this cause problems for other modules that depend on it? For example, if a dependent module has the standard "GPL or Artistic" license, wouldn't the GPL part of that require that this module be available under the GPL? Only if it actually links to that code. Use does not trigger the "viral" effect of the GPL. And actually, in the case of a dual license link, it would really mean that the linking code would default over to Artistic. I suspect that this code is under the same license as perl, and that the upstream maintainer is just really lazy. FYI: Larry Wall has a comment about this in http://dev.perl.org/licenses/ (In reply to comment #6) > Only if it actually links to that code. Use does not trigger the "viral" effect > of the GPL. And actually, in the case of a dual license link, it would really > mean that the linking code would default over to Artistic. Consider Maypole, which is licensed GPL or Artistic and uses this module. If I wanted to build and distribute something based on that under the GPL, surely my package and its non-OS dependencies need to be available under a GPL-compatible license? I would have thought a perl module (without which Maypole would not work) would be counted as one of those dependencies? If it's not, what would be the point of releasing this module under a specific license such as GPL or Artistic if anyone can use that code under whatever terms they liked (e.g. proprietary)? > I suspect that this code is under the same license as perl, and that the > upstream maintainer is just really lazy. So do I. (In reply to comment #7) > FYI: Larry Wall has a comment about this in > > http://dev.perl.org/licenses/ Hmm, OK, that *seems* to suggest that using a perl module is an act of aggregation rather than linking. I can go with that in this case, but supposing the module hadn't been noarch; if it was XS code that had to be compiled, that would count as linking, wouldn't it? (In reply to comment #8) > Consider Maypole, which is licensed GPL or Artistic and uses this module. If I > wanted to build and distribute something based on that under the GPL, surely my > package and its non-OS dependencies need to be available under a GPL-compatible > license? I would have thought a perl module (without which Maypole would not > work) would be counted as one of those dependencies? I can make a GPL application which does nothing but calls out and runs a proprietary application with specific flags. Merely running non-GPL-compatible bits is ok, its only linking at compile time. Larry Wall thinks that perl modules are not being "linked to", rather only being run. > If it's not, what would be the point of releasing this module under a specific > license such as GPL or Artistic if anyone can use that code under whatever terms > they liked (e.g. proprietary)? You make a valid point. :) Perl's licensing is really weak. > Hmm, OK, that *seems* to suggest that using a perl module is an act of > aggregation rather than linking. I can go with that in this case, but supposing > the module hadn't been noarch; if it was XS code that had to be compiled, that > would count as linking, wouldn't it? I'd say yes. Larry seems to say no. OK, since IANAL, it's Approved. After changing the License: tag to "Distributable", you'll also need to remove the GPL and Artistic license texts from the package of course, at least until upstream clarifies the position. |