I had mentioned this concern (licensing and system VM presence) in the earliest Apache discussions, and I included it in the CloudStack project proposal at [1]. I had been told that it was a non-issue. That is, as long as the code in our repo is of allowed license this dependency is fine, and it won't block our first Apache release. There are some other interesting ideas later in this thread, but they seem lower priority to me than the other issues on the deps page [2].
[1] http://wiki.apache.org/incubator/CloudStackProposal [2] http://confluence.cloudstack.org/display/dev/Moving+dependencies+to+ASF+approved+licenses > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Wednesday, July 04, 2012 1:03 PM > To: cloudstack-dev@incubator.apache.org > Subject: [DISCUSS] systemvms > > Hi folks, > > I spent a bit of time going through the patches directory and working on > license headers today. > > Historically CloudStack has made a Debian-based systemvm template > available for each hypervisor. However, my sense is that going forward we > will not be able to do this because of licensing issues. However, the need for > a systemvm will not be eliminated, so I'd like to come up with some ideas on > how to mitigate this. > > My only initial thought is that we'd have only the body of code that the > systemvm uses exclusively for CloudStack (and remove all of the other bits > like vhdutil) and the config tree.) and that we would additionally provide > some packaging around those bits so that a user could deploy that package to > a debian or fedora-based system and have a working systemvm. > > Thoughts, comments, flames? > > --David
