On Tue, May 14, 2013 at 8:33 AM, Devdeep Singh <devdeep.si...@citrix.com> wrote: > 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 >
It is possible that this might not be eligible for inclusion at all, or that at a minimum we might need a separate build profile. Right now because we don't know, we simply can't begin to look towards a solution. The first step towards legal is the PMC. --David
