[Bug 166189] Review Request: perl-Class-DBI-Loader-Relationship : Easier relationship specification in CDBI::L

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: perl-Class-DBI-Loader-Relationship : Easier relationship specification in CDBI::L


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166189





------- Additional Comments From paul at city-fan.org  2005-09-12 11:20 EST -------
(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?


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.