Re: Help with Dependency Licensing
On Wednesday, April 12, 2017 8:23 AM, Shane Curcuru <a...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help with Dependency Licensing
On Tuesday, April 11, 2017 11:10 AM, John D. Ament <johndam...@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 <nick.couch...@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
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
