This recent thread looks very relevant: http://s.apache.org/55E

Now that I understand your question I don't think what you want to do is a
> problem at all.
> As long as you aren't storing GPL components in svn or distributing them
> there should be no
> problem providing plugins that are targeted to third-party systems.  See
> http://www.apache.org/legal/resolved.html#platform


On Tue, Oct 2, 2012 at 9:39 AM, Noah Slater <nsla...@tumbolia.org> wrote:

> (For clarity, in this email non-OS means "not compatible with the Apache
> license.")
>
> Can you clarify what "link" means in this context? You need to be careful
> with licenses such as the GPL, which expressly prohibit linking (in quite a
> vague sense) unless the your software is also GPL. (Which is what the LGPL
> was for.)
>
> But beyond that, as long as the source tarball that we release contains no
> binaries (of any sort) and nothing that is incompatible with our license,
> then we should be fine. (I am not sure about the build question. In
> general, I don't think it is problematic to have non-OS software on our
> systems. JIRA for example! But we would have to check the specifics with
> Infra.)
>
> Though that does make me wonder about how much non-OS stuff is required on
> the installation machine. I am presuming the core of will work, and it is
> just that some plugins will not work unless you have the required non-OS
> dependancies locally?
>
> In fact, to make doubly sure, is this the situation you're describing:
>
>    1. Build the source release of CloudStack with plugin sources that can
>    only be compiled with non-OS software present (note that the compilation
>    does not happen during the source release, we only ship the source of 
> them.)
>    2. Prepare binary packages from the source release that compile the
>    the non-OS plugins with the non-OS software present (and distribute these
>    from non-ASF locations)
>    3. Users download the binary packages and use the non-OS plugins if
>    they have that non-OS software locally
>
> For 1) what happens if you're installing form the source release, and you
> don't have the non-OS software present?
>
> For 2) do you need the non-OS software present to compile the plugins when
> preparing the binary package?
>
> For 3) what happens if you're installing from the binary package, and
>  don't have the non-OS software present?
>
>
> On Tue, Oct 2, 2012 at 9:14 AM, Rohit Yadav <rohit.ya...@citrix.com>wrote:
>
>> Moving binary packaging discussion with Noah from another thread here;
>>
>> >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
>>
>> Thanks Noah, so if we build CloudStack against nonoss deps/libs (on
>> non-ASF infra, not likely but if possible on ASF infra) and publish the
>> binary (which won't have any non ASF compliant libs/deps/artifacts) on ASF
>> infra that will work?
>> Only the plugins (which are all ASF compliant) are linked against these
>> nonoss libs.
>> If we do this, we won't have to do separate builds, nonoss/oss, less
>> trouble for QA and a user will be just required to install nonoss libs/deps
>> to have the plugins work.
>>
>> Let's do this?
>>
>> Regards.
>>
>> ________________________________________
>> From: Noah Slater [nsla...@tumbolia.org]
>> Sent: Sunday, September 30, 2012 11:10 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [ASFCS40][DISCUSS] Binary packaging - another round of
>> discussions that I'd like us to come to a conclusion on.
>>
>> This all sounds good to me.
>>
>> What would be the difference between the src.tar.gz and the jar one?
>>
>> On Wed, Sep 12, 2012 at 8:55 PM, Chip Childers <chip.child...@sungard.com
>> >wrote:
>>
>> > All,
>> >
>> > This is another issue that we need to come to a consensus on (and I
>> > think we can do lazy consensus if required here) prior to 4.0 being
>> > released.
>> >
>> > We've variously been discussing how to best provide binary artifacts
>> > from the 4.0 release.  Knowing that we are purely discussing
>> > convenience builds for users, and that ASF releases are source only,
>> > I'd like to propose the following approach.
>> >
>> > I propose that the project only publishes source tarballs to the ASF
>> > mirrors, and that we rely on the community at large to publish binary
>> > build artifacts.
>> >
>> > Wido has volunteered to host deb and rpm repos containing packages
>> > built from the source, and I know that (over time) we will see the
>> > actual distributions put cloudstack packages together.  I would
>> > imagine (and am not speaking for Wido), that we could work with Wido
>> > to ensure that his hosted repos have the latest release in them.  We
>> > would then be in a position where it's OK if a specific distro
>> > packaging community is a version or two behind the ASF releases.  That
>> > scenario would allow us to point users that want the very latest
>> > release to the custom repo, but folks that want official distro
>> > packages can simply use the version being provided by their OS's
>> > packaging system.
>> >
>> > For the convenience of the community, I'd further propose that we
>> > provide a set of links to these community repos on our download page
>> > (including appropriate verbiage about the URLs not representing
>> > official ASF release artifacts).  This would also include instructions
>> > for how to setup a RHEL/CentOS/Ubuntu system to pull from Wido's
>> > hosted repos.
>> >
>> > As for QA teams involved in the testing of ASF releases, I believe
>> > that we should continue to use jenkins.c.o (with Citrix's agreement
>> > and continued support) as the source for downloading packages for
>> > testing.  This is because it can do it for us on a nightly schedule.
>> >
>> > There is one optional part of this proposal:  we include a tarball of
>> > cloudstack jar files on the ASF mirrors.  Although, I'm just not sure
>> > what value that provides to the community.
>> >
>> > Thoughts?
>> >
>> > -chip
>> >
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>



-- 
NS

Reply via email to