On Jun 24, 2011, at 8:17 PM, Clemens Lang wrote: > On Sat, Jun 25, 2011 at 08:05:10AM +1000, Joshua Root wrote: >> It's not a problem in the sense of making it impossible to distribute >> the code. It is a problem in the sense of us not wanting to have >> multiple licenses. > > What licenses does the MacPorts project want? Should everything > distributed as "MacPorts" be BSD-licensed? And what type of BSD-license? > Is the only license acceptable the 2-clause BSD-license in use atm, or > would it be fine to redistribute an Apple-modified 3-clause BSD-license > where the 3rd clause is something like "you may not advertise with the > name Apple unless explicitly permitted to"?
IIRC, any code under a license that is no more restrictive than the current license is fine; 3-clause BSD, MIT, etc. > Also, what kind of workarounds do we have to redistribute things not > licensed like the project wants? Is weak linking against a library > distributed as port acceptable? (Think of an LGPL lib somebody wants to > use in MacPorts. Would it be acceptable to distribute that lib as > separate port, weakly link against it and tell users to install that > port if they want to use $new_feature?) Dependencies like this are just an end-run around licensing requirements, and the net effect will be the same. What is required from libelf? Since basic parsing of the Mach-O header is a pretty straight-forward task, it may be possible to avoid an external library entirely here. I'd also be happy to help with any GSoC implementation questions; dylib load/id LC_CMDs, etc. -landonf _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
