cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: [VOTE] Apache Cloudstack 4.0.0-incubating Release, first round
Date Fri, 12 Oct 2012 15:16:01 GMT
Thanks for the response, David!

Looks like you and Chip replied at the same time. I will comment on things
not yet addressed.

On Fri, Oct 12, 2012 at 3:39 PM, David Nalley <david@gnsa.us> wrote:
>
>
> So effectively we are bundling an upstream library (XenServerJava) in
> its entirety - are you suggesting we should strip the readme and
> license files from that library.


Yep.


>
> >> docs/publican-cloudstack/NOTICE
> >
> > This file should probably not exist.
> >
> > This information should be in the top level NOTICE and LICENSE files.
>
> So I have a question - the notice and license files in
> publican-cloudstack are used in the generation of the
> publican-cloudstack RPM package (see
> docs/publican-cloudstack/publican-cloudstack.spec -  including the
> toplevel LICENSE or NOTICE file would contain erroneous information
> for the publican-cloudstack package How do we resolve this so that the
> publican-cloudstack package can contain proper LICENSE/NOTICE
> information for the resulting package?  Same issue with Marvin - it
> has it's own LICENSE/NOTICE/README - but its really designed to be
> shipped as a standalone python library when it emerges into 'binary'
> form


Think I covered this obliquely in my last email. If the file is just part
some 3rd party software we have imported, then we need to strip it of these
files and work the important information into our own files.

However, if the files are needed to build some sort of binary package
(because they will be unpacked by the binary package and placed on the
user's system) then I they need to stay where they are. In this instance,
they are not remnants of a code import, but a functional part of the build
system.

I will caveat this by saying that I've actually not run into this before,
so I am trying to apply common sense. (i.e. I am not speaking
authoritatively from policy or anything.)

-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message