[GSoC] libelf license

Landon J Fuller landonf at macports.org
Fri Jun 24 17:56:13 PDT 2011


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


More information about the macports-dev mailing list