Chip, thank for the explanation. This makes perfect sense, and I like the approach.
To summarise what I'm hearing: - A release includes source for plugins for non-OS software - By default, the release will only build plugins for OS software - Users can enable the plugins for non-OS software at build time - If we host builds that include deps, we will not enable plugins for non-OS software - Community provided builds have the option to include these plugins and deps As a side note, from my time as a Debian developer, I find it strange to think that we would bundle dependancies within the deb file. Is this common practice for Java systems? (Or just something we would do to simplify our packaging efforts?) On Mon, Oct 1, 2012 at 8:16 PM, Chip Childers <chip.child...@sungard.com>wrote: > 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 > -- NS
