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