You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Nick Couchman <ni...@yahoo.com.INVALID> on 2017/04/11 14:26:12 UTC
Help with Dependency Licensing
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
Re: Help with Dependency Licensing
Posted by Nick Couchman <ni...@yahoo.com.INVALID>.
On Tuesday, April 11, 2017 11:10 AM, John D. Ament <jo...@apache.org> wrote:
Nick,
> In general, the LICENSE and NOTICE refers to the contents of the release
> itself. If you're not bundling any of those outside dependencies, then
> there would be nothing to include.
Okay, sounds good, thank you.
> Please also note - you can provide a binary release, assuming that the
> binary release does not package the outside dependencies and that its clear
> that it brings in those other dependencies.
I think that's problematic in this case - Guacamole builds with Maven, and, the way it's configured across the project, it goes out and pulls in all of the dependencies (binaries in JAR format) and creates a single JAR file that can then be copied to the extensions folder and used to extend the main Guacamole client. So, the resulting binary file isn't just the source from the Guacamole project, it's also any binary dependencies necessary to run it. I'll discuss with the other folks in the project, but I believe the thought at this point is that it's probably simpler to provide folks with the instructions for building/packaging themselves than to try to build without the dependencies and then have the user load those files into certain locations for the extension in question.
Thank you very much for the guidance!
Regards,Nick
On Tue, Apr 11, 2017 at 10:26 AM Nick Couchman
<ni...@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
Re: Help with Dependency Licensing
Posted by "John D. Ament" <jo...@apache.org>.
Nick,
In general, the LICENSE and NOTICE refers to the contents of the release
itself. If you're not bundling any of those outside dependencies, then
there would be nothing to include.
Please also note - you can provide a binary release, assuming that the
binary release does not package the outside dependencies and that its clear
that it brings in those other dependencies.
John
On Tue, Apr 11, 2017 at 10:26 AM Nick Couchman
<ni...@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
Re: Help with Dependency Licensing
Posted by Nick Couchman <ni...@yahoo.com.INVALID>.
On Wednesday, April 12, 2017 8:23 AM, Shane Curcuru <as...@shanecurcuru.org> wrote:
Nick Couchman wrote on 4/11/17 10:26 AM:
>> 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.
>
> It's not completely clear from your description what specific bits of
> code are going where, so a more detailed description might help. But my
> first guess would be no. The CatX policy is pretty clear: don't include
> Category X code in Apache repos or releases:
>
> https://www.apache.org/legal/resolved.html#category-x
So, I'm writing an extension for the Guacamole client that allows authentication against RADIUS servers. Guacamole is written in Java and leverages the Maven repository to pull in dependencies. There are a couple of different implementations of RADIUS libraries for Java, the most complete of which is JRadius. JRadius is licensed under LGPL-2.1. The only other freely-available option is TinyRadius, which is extremely incomplete, is also LGPL-licensed. So, barring writing my own implementation of a RADIUS library, I'm kind of out of options.
Some things to note regarding the use of JRadius:- I am not including source code for JRadius in the project. I am using the Java classes, downloaded by Maven in binary format, and calling those classes from the source code.- This is an authentication extension to the Guacamole client, and is not "core" functionality.- At this point, we do not plan to distribute any binary code related to this extension. The plan is to put the extension source code in the main repository and provide instructions for building the component. A section in the legal page referenced above asks about Apache-licensed components depending on components that use prohibited licenses, and the answer (roughly) is that you cannot distribute the components (check) and it cannot be core to the product (this *extension* is not).
> The reasoning for this is twofold:
>
> - Legal issues. We obviously want to carefully comply with how everyone
> else's licenses, so GPL or any similar kind of code is inappropriate to
> use in any Apache work.
>
> - Policy issues. Immaterial of caselaw or potential legal rulings, the
> ASF only wants to incorporate third party works in ways that respect the
> intent of third party licenses. The JSON license is an example here,
> since it's unspecific call for 'Good, not Evil' is incompatible with our
> policy that our users can use the software for whatever they want.
>
> In any case, it sounds like your PPMC needs to provide a more detailed
> description of the issue, and open a Legal JIRA to get a definitive answer:
>
I'll open a Legal JIRA.
Thanks,Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Help with Dependency Licensing
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Nick Couchman wrote on 4/11/17 10:26 AM:
> 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.
It's not completely clear from your description what specific bits of
code are going where, so a more detailed description might help. But my
first guess would be no. The CatX policy is pretty clear: don't include
Category X code in Apache repos or releases:
https://www.apache.org/legal/resolved.html#category-x
The reasoning for this is twofold:
- Legal issues. We obviously want to carefully comply with how everyone
else's licenses, so GPL or any similar kind of code is inappropriate to
use in any Apache work.
- Policy issues. Immaterial of caselaw or potential legal rulings, the
ASF only wants to incorporate third party works in ways that respect the
intent of third party licenses. The JSON license is an example here,
since it's unspecific call for 'Good, not Evil' is incompatible with our
policy that our users can use the software for whatever they want.
In any case, it sounds like your PPMC needs to provide a more detailed
description of the issue, and open a Legal JIRA to get a definitive answer:
https://www.apache.org/legal/resolved.html#asking-questions
> 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
>
--
- Shane
https://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Help with Dependency Licensing
Posted by "John D. Ament" <jo...@apache.org>.
On Tue, Apr 11, 2017 at 8:40 PM Mike Jumper <mi...@guac-dev.org>
wrote:
> On Apr 11, 2017 17:29, "Niclas Hedhman" <ni...@hedhman.org> wrote:
>
> On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
> >
> > Even in the case of the GPL, my understanding is that the virality takes
> > hold upon linking (at build time), not upon referencing the API via an
> > import, include, etc. in the source.
> >
>
> Your understanding is, simply put, not aligned with the FSF, and the ASF
> has decided to follow FSF's conclusion. In fact, a former Director at ASF
> and lawyer, Larry Rosen, was trying to fight this stance, basically making
> the claim that GPL is overreaching, and that ended with Larry being kicked
> out (not only for this particular question).
>
>
> <quote src="http://www.gnu.org/licenses/lgpl-java.html" emphasis="mine">
> It has always been the FSF's position that *dynamically linking
> applications to libraries creates a single work derived* from both the
> library code and the application code
>
>
> Sorry, but I don't see the disagreement between the above statement and
> "the
> virality takes hold upon linking (at build time)". Doesn't this creation of
> a derivative work, even in the FSF interpretation, occur at the time of
> linking, and not at the time that the source is written?
>
> A piece of uncompiled source code is not yet linked. Linking is part of the
> build and/or runtime processes.
>
>
Mike, if I had to guess, the problem is two pieces. Assumptions about
licenses in use, and assumptions about how build tools work. What you're
describing sounds like GPL and statically linked libraries. The Cat-X
section applies to many licenses, many languages. For instance, JSON
license was moved to Cat-X due to a "do no harm" clause. Some of the
original licensing comments I cited were based on a discussion around
non-transitive licenses, such as LGPL and Amazon Software License.
If I had to summarize some next steps - anytime you're dealing with Cat-X,
seek out legal (not incubator) opinion, review existing discussions (even
if not captured on the website) and wait for a decision. All Cat-X is
never in source format, never as a binary must-have core dependency, and
typically a very rare case where a binary optional dependency is OK.
> - Mike
>
Re: Help with Dependency Licensing
Posted by Mike Jumper <mi...@guac-dev.org>.
On Apr 11, 2017 17:29, "Niclas Hedhman" <ni...@hedhman.org> wrote:
On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <mi...@guac-dev.org>
wrote:
>
> Even in the case of the GPL, my understanding is that the virality takes
> hold upon linking (at build time), not upon referencing the API via an
> import, include, etc. in the source.
>
Your understanding is, simply put, not aligned with the FSF, and the ASF
has decided to follow FSF's conclusion. In fact, a former Director at ASF
and lawyer, Larry Rosen, was trying to fight this stance, basically making
the claim that GPL is overreaching, and that ended with Larry being kicked
out (not only for this particular question).
<quote src="http://www.gnu.org/licenses/lgpl-java.html" emphasis="mine">
It has always been the FSF's position that *dynamically linking
applications to libraries creates a single work derived* from both the
library code and the application code
Sorry, but I don't see the disagreement between the above statement and "the
virality takes hold upon linking (at build time)". Doesn't this creation of
a derivative work, even in the FSF interpretation, occur at the time of
linking, and not at the time that the source is written?
A piece of uncompiled source code is not yet linked. Linking is part of the
build and/or runtime processes.
- Mike
Re: Help with Dependency Licensing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 12, 2017 at 9:03 AM, John D. Ament <jo...@apache.org>
wrote:
>
> The info I provided was based on a discussion on legal, originally carried
> over from a discussion on optional dependencies on software licensed under
> the Amazon Software License -
> https://lists.apache.org/thread.html/2630f3d9540f02ef24f5e03cc171c4
> a2975bd8965c80a1965a55c0b4@%3Clegal-discuss.apache.org%3E
>
>
Yet another long thread on the same topic. I was on Legal for ~5 years and
Hibernate came up again and again. Since their is an JPA implementation
in-house, there would be no need to depend on Hibernate for Apache
projects. And perhaps it is unfair to talk about Hibernate if you want to
discuss Amazon licensing terms, but that is where this thread headed (until
I stopped reading about half way down).
People (myself included at times) forget that our own individual 'opinion'
and 'interpretation' are irrelevant. What matters are "legal opinion" from
a lawyer, who is guessing(!) what a court/judge would rule, and to a lesser
degree the "intent of the license author", who in (L)GPL case is FSF Legal
Counsel (Eben Mogel just stepped down, btw), lawyers spending years to
figure this out, and when FSF declare an intent we either follow that or
take it to court.
Then to make matters worse, the software project author sometimes expresses
an intent that differs from the intent of its license author, and the
"exceptions" comes to play (or not).
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Help with Dependency Licensing
Posted by "John D. Ament" <jo...@apache.org>.
On Tue, Apr 11, 2017 at 8:29 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
> >
> > Even in the case of the GPL, my understanding is that the virality takes
> > hold upon linking (at build time), not upon referencing the API via an
> > import, include, etc. in the source.
> >
>
> Your understanding is, simply put, not aligned with the FSF, and the ASF
> has decided to follow FSF's conclusion. In fact, a former Director at ASF
> and lawyer, Larry Rosen, was trying to fight this stance, basically making
> the claim that GPL is overreaching, and that ended with Larry being kicked
> out (not only for this particular question).
>
>
> <quote src="http://www.gnu.org/licenses/lgpl-java.html" emphasis="mine">
> It has always been the FSF's position that *dynamically linking
> applications to libraries creates a single work derived* from both the
> library code and the application code.The GPL requires that all derivative
> works be licensed as a whole under the terms of the GPL, an effect which
> can be described as “hereditary.” So, if an application links to a library
> licensed under the GPL, the application too must be licensed under the GPL.
> :
> :
> FSF's position has remained constant throughout: the LGPL works as intended
> with all known programming languages, including Java. Applications which
> link to LGPL libraries need not be released under the LGPL. Applications
> need only follow the requirements in section 6 of the LGPL: allow new
> versions of the library to be linked with the application; and allow
> reverse engineering to debug this.
> </quote>
>
> At first, the "link to LGPL libraries need not be released under LGPL" is
> an indicator that Apache licensed projects could depend on LGPL projects,
> but it is this "Section 6" that makes LGPL incompatible, since we don't
> require this of our downstreams. This was hotly debated back in the days
> when this FSF article was written, and it took us a year or two to nail it
> down.
>
>
> More info at http://www.gnu.org/licenses/gpl-faq.html
>
> John, As for the case of Hibernate; If you depend on JPA, you don't depend
> on Hibernate. However, if you depend on JPA in a way so that only Hibernate
> makes the project work, and that EclipseLink or other implementations can't
> be used instead, then you are in gray territory and should ask Legal for
> advice. I am uncertain of that position.
>
>
The info I provided was based on a discussion on legal, originally carried
over from a discussion on optional dependencies on software licensed under
the Amazon Software License -
https://lists.apache.org/thread.html/2630f3d9540f02ef24f5e03cc171c4a2975bd8965c80a1965a55c0b4@%3Clegal-discuss.apache.org%3E
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: Help with Dependency Licensing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <mi...@guac-dev.org>
wrote:
>
> Even in the case of the GPL, my understanding is that the virality takes
> hold upon linking (at build time), not upon referencing the API via an
> import, include, etc. in the source.
>
Your understanding is, simply put, not aligned with the FSF, and the ASF
has decided to follow FSF's conclusion. In fact, a former Director at ASF
and lawyer, Larry Rosen, was trying to fight this stance, basically making
the claim that GPL is overreaching, and that ended with Larry being kicked
out (not only for this particular question).
<quote src="http://www.gnu.org/licenses/lgpl-java.html" emphasis="mine">
It has always been the FSF's position that *dynamically linking
applications to libraries creates a single work derived* from both the
library code and the application code.The GPL requires that all derivative
works be licensed as a whole under the terms of the GPL, an effect which
can be described as “hereditary.” So, if an application links to a library
licensed under the GPL, the application too must be licensed under the GPL.
:
:
FSF's position has remained constant throughout: the LGPL works as intended
with all known programming languages, including Java. Applications which
link to LGPL libraries need not be released under the LGPL. Applications
need only follow the requirements in section 6 of the LGPL: allow new
versions of the library to be linked with the application; and allow
reverse engineering to debug this.
</quote>
At first, the "link to LGPL libraries need not be released under LGPL" is
an indicator that Apache licensed projects could depend on LGPL projects,
but it is this "Section 6" that makes LGPL incompatible, since we don't
require this of our downstreams. This was hotly debated back in the days
when this FSF article was written, and it took us a year or two to nail it
down.
More info at http://www.gnu.org/licenses/gpl-faq.html
John, As for the case of Hibernate; If you depend on JPA, you don't depend
on Hibernate. However, if you depend on JPA in a way so that only Hibernate
makes the project work, and that EclipseLink or other implementations can't
be used instead, then you are in gray territory and should ask Legal for
advice. I am uncertain of that position.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Help with Dependency Licensing
Posted by Mike Jumper <mi...@guac-dev.org>.
On Tue, Apr 11, 2017 at 9:16 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> 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...
I think it's important not to conflate "Cat X" with "GPL".
There are numerous reasons a license might be Cat X, but not all such
licenses are due to the FSF, and not all such licenses are viral to the
extent that the licensing of the source of the linking project is
compromised.
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.
>
Even in the case of the GPL, my understanding is that the virality takes
hold upon linking (at build time), not upon referencing the API via an
import, include, etc. in the source.
- Mike
Re: Help with Dependency Licensing
Posted by "John D. Ament" <jo...@apache.org>.
On Tue, Apr 11, 2017 at 12:16 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> 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?
>
>
Ugh. I hit send too soon. Basically, what we came up with was that a
Cat-X dependency was OK when it was based on some common interface, and
never bundled within the application. Hibernate was an example that came
up - I can provide a library that ships with integration for hibernate,
based on the JPA specification (which is Cat-B or Cat-A).
> 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
>
Re: Help with Dependency Licensing
Posted by Niclas Hedhman <ni...@hedhman.org>.
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