[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 tcallawa at redhat.com  2005-09-12 11:25 EST -------
(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.

-- 
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.