incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: Building debs with Maven
Date Mon, 01 Oct 2012 19:16:51 GMT
On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <nslater@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 <david@gnsa.us> wrote:
>
>> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <rohit.yadav@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

Mime
View raw message