Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <570350127.610810.1491920772513@mail.yahoo.com>
References: <570350127.610810.1491920772513.ref@mail.yahoo.com> <570350127.610810.1491920772513@mail.yahoo.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Wed, 12 Apr 2017 00:16:18 +0800
Message-ID: <CADmm+Kefo4Dm3HjCfYFuFME9UPLhbFNHUdQFGwppq=Rqg4-Dhw@mail.gmail.com>
Subject: Re: Help with Dependency Licensing
To: "general@incubator.apache.org" <general@incubator.apache.org>, Nick Couchman <nick.couchman@yahoo.com>
Content-Type: multipart/alternative; boundary=94eb2c1a1ee8ac181f054ce66a21
archived-at: Tue, 11 Apr 2017 16:16:50 -0000

--94eb2c1a1ee8ac181f054ce66a21
Content-Type: text/plain; charset=UTF-8

Please note that Cat X licenses are deemed to be incompatible with Apache
License, insofar that they are viral in nature, and FSF has made a claim
that dynamically linked languages, such as Java, forces the virality to the
dependent project... Meaning, if you have an import statement linking your
code to such dependency, there is legal uncertainty whether the entire
project must be under the copyleft license in question. FSF certainly
thinks so, and VP Legal has in the past concluded that we should have the
same stance.

So when is the optional Cat X dependency acceptable?

For instance, an acceptably licensed API specification is what our project
depend on, and some runtime mechanism (such as Java Service Loader or
Spring Dependency Injection) make that available. Without this indirection,
we ain't allowed to have dependency on Cat X for Java (and other
circumstances).


HTH
Niclas


On Tue, Apr 11, 2017 at 10:26 PM, Nick Couchman <
nick.couchman@yahoo.com.invalid> wrote:

> Hello, everyone,I'm currently working on the Guacamole incubator project,
> and am developing an extension for the project that has dependencies on
> binaries (JARs via Maven) that are licensed under Category-X licenses.
> We've already determined that we cannot distribute a binary version of this
> extension, but, since it is an extension (and not core to the functionality
> of the product), we should be able to distribute the source code with build
> instructions for the users.
> The question I have is how we should deal with license bundling in this
> scenario?  In the rest of this project, including other extensions, we
> bundle a src/licenses directory that has all of the dependency licenses for
> the extension.  When the binary is built, a resulting file has not only the
> binary for the extension, but also all of the dependency licenses.  Since
> we're not distributing a binary, is there any reason/need for us to package
> up dependency licenses?
> Let me know if this needs more clarification - I know this might be a bit
> vague, but I'm in new territory, here, and am happy to provide any further
> information that might help someone help me :-).
> Thanks,Nick


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

--94eb2c1a1ee8ac181f054ce66a21--