Hi, > -----Original Message----- > From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] > Sent: Monday, May 13, 2013 6:39 PM > To: dev@cloudstack.apache.org > Subject: RE: Regrading support for intel txt > > 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.
The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep > > 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
