Heya, > -----Original Message----- > From: Devdeep Singh [mailto:devdeep.si...@citrix.com] > Sent: Monday, May 13, 2013 1:28 PM > To: dev@cloudstack.apache.org > Subject: Regrading support for intel txt > > Hi, > > I was working on intel txt support [1] and I needed some suggestions and > feedback. I am developing the feature here [2] and it has a dependency on a > client library (given by intel) which is used for talking to an attestation > server. > Right now I am not sure under what license will the library be made available. > So I have kept this feature as part of nonoss. However, it is possible that > the > license may be so restrictive that we cannot include it as we do for nonoss. > Considering this, what are the options available? Should it be kept as a > separate maven profile?
Just like the other non-oss components it should have its own profile. We just use the nonoss define to activate all those profiles at once. Technically you could do a build with just the netscaler or midonet support enabled with the -P flag. > Once it is resolved that the license allows nonoss or > even oss, we move it there? The issue is the availability of the jar file and the availability of the api description. If the jar file is freely available for download (that is without having to login to a website or accept some eula) than we can include it in the regular build. It would be even easier if the jar would be on a maven respository. If the jar file is not available or has restrictions on distribution (like an eula or to have a valid login account) then people cannot compile the code without obtaining this library. Then we need to put it in a special profile and disable it by default. (nonoss is actually a misnomer for this) If the api is not publicly available then we can't even add code using that api to our repository. But I'm not sure if that is even possible. If we run into that we might need to have a chat with some legal types to get feedback. Let's cross that bridge only when we have to. Feel free to send the link to the library around so we can check the distribution restrictions if any. Cheers, Hugo > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+Int > el+TXT+Technology > [2] https://github.com/devdeep/cloudstack/tree/intel-txt > > Regards, > Devdeep
