On 06/27/2012 12:38 PM, Guy Hulbert wrote: > It's unenforcable if the modules in question do not incorporate any > OpenSSL code and are just an interface to the library. I think this is > probably the case. Eh? How is a binding to a library not a project that is "derived from" that library? I don't follow your explanation that the clause is unenforcable. What makes it unenforcable? Do you think that the holder of a fully-proprietary license (imagine the most absurd non-free software imaginable) wouldn't have any grounds to complain against someone who was distributing a binding to their library without their approval? You know that you can only make a binding by at least building against header files, and linking at runtime to object files, right? > There seem to be between 30 and 40 modules on CPAN with OpenSSL in the > name and no-one seems to be bothered. You're seeing the modules that *remain* in CPAN. There used to be a perl module named OpenSSL. It doesn't exist in CPAN any more (in fact, the authors removed it when i asked them about these questions, as can be seen in the history of #534338. :( Listen, i don't like this situation either, and i wouldn't bother with it except that authors of some code in debian have made an explicit request by placing a constraint on their license that we have accepted by redistributing it. Shouldn't we at least try to honor that request? --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature