cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
Date Wed, 27 Mar 2013 13:48:36 GMT
On Wed, Mar 27, 2013 at 10:27:44AM +0000, Donal Lafferty wrote:
> Let me bring the conversation back to the subject line...
> WRT to ServerResource implementation, I'd suggested using a RESTful API to hide ServerComponent
and ServerResource implementations from each other [1]


> This left the ServerResource open for implementation in any 'native' language.  In contrast,
the ServerComponent conformed to Management Server (Java/Spring/whatever our ORM is/etc),
and it is meant to be 'generic' to simplify reuse.
> I reason that the difficulty device access for test and build, and not language choice.
 Integration testing requires device access, and some tools will only run on a particular
platform, e.g. libvirt, MSFT compiler.  The language choice is secondary to this problem.


It's both language and build tool/platform, but I get your point.
Testing and building is my biggest concern.  I'm +1 to David's
suggestion that the ServerResource code bits are a separate git repo,
which we can publish as a different release artifact.

This doesn't address general build / testing though.  Anyone have
thoughts on this?

> WRT to licensing, I was looking for bright line rules [2]. E.g. the Master repo only
gets donated code.  A process for developing rules for tools and frameworks is what I'm looking

I'm not going to give you a bright line. Code running in the CLR is probably 
OK.  Use of system libraries provided by MSFT is also probably OK (but I 
could be wrong).  Use of any other libraries will need to be specifically 

Donal, I think you might need to do a little bit of legwork here.
Have you searched the legal-discuss ML archives for discussion about
.NET code and use of MSFT system libraries in that code?  Do other ASF
projects do .NET code?  How are they handling this?

> [1]
> [2] 

View raw message