Spec Name or Url: http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship.spec SRPM Name or Url: http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship-1.2-2.src.rpm Description: Easier relationship specification in CDBI::L (NOTE: This package is one of the Maypole dependencies)
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.