On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <nsla...@tumbolia.org> wrote: > Just a clarification here. It is fine to use, or depend on proprietary > software that exists on the system. During the build, or after install. > "For example, using a GPL'ed tool during the build is OK." [1] The > stipulation is that we cannot ship anything WITH the build that is > incompatible with our license. > > [1] http://www.apache.org/legal/resolved.html
Understood. The approach we are taking is to ensure that the default build process only includes compatible dependencies in the produced RPM and DEB packages (with a few "system dependencies" being required by the packages themselves). The intent here was to have the RPM and DEB's published via ASF infrastructure. We've changed course a little bit recently (with Wido hosting the repos outside of ASF), which does open up the possibility of changing our approach. That being said, I personally like the clean model that we have in place right now. Someone that gets the source code today knows that the default build will only pull in dependencies that are compatible from a licensing perspective. They are then responsible for some required system dependencies. And for those dependencies that can optionally be enabled in the build, they are able to follow the instructions to build their own copy of the app that includes the other features. The approach is largely based on the answer for "Can Apache projects rely on components whose licensing affects the Apache product?" from the legal "resolved" page. It keeps us in a position to potentially host package repos on ASF infra, and sends a clear signal to companies / organizations that want to include an integration into their product for how best to reach a broader audience (via permissive OSS licensing). Make sense? -chip > On Thu, Sep 13, 2012 at 8:13 PM, David Nalley <da...@gnsa.us> wrote: > >> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <rohit.ya...@citrix.com> >> wrote: >> > >> >>But how do you build them without those libraries - for instance the >> >>VMware plugin doesn't build without the vmware libraries being >> >>present. >> > >> > No, not vmware plugin or any nonoss plugin. >> > By default mvn builds only oss ones. >> > >> > So if you've the non-oss jars, you copy them to deps/ and run the >> install-non-oss.sh script. >> > This will copy the nonoss deps to ~/.m2 and you build with the nonoss >> profile: >> > mvn package -Pnonoss, this creates packages with these nonoss plugins. >> > (check plugin/pom.xml, that will clear the confusion). >> > >> > Lastly, why is kvm under nonoss in plugin/pom.xml? Thanks. >> >> >> Because until today the libvirt-java library that it needed was LGPL >> which is not compliant with the ASF guidelines for permissible >> licenses to be included/depended on by the default build. >> >> --David >> > > > > -- > NS
