Re: Regrading support for intel txt
On Tue, May 14, 2013 at 8:33 AM, Devdeep Singh 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
Re: Regrading support for intel txt
On Tue, May 14, 2013 at 01:49:57PM +, Devdeep Singh wrote: > > -Original Message- > > From: Chip Childers [mailto:chip.child...@sungard.com] > > Sent: Tuesday, May 14, 2013 6:58 PM > > To: dev@cloudstack.apache.org > > Subject: Re: Regrading support for intel txt > > > > On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: > > > 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 > > > > This is problematic IMO for 2 reasons: > > > > #1 Community angle: > > === > > > > If it's not possible for some to access that library, even if we make it > > it's own > > build target, then how can anyone test it? On one hand, we place a burden > > on ourselves in a similar way for every non-oss dependency. On the other > > hand, the fact that we already *sort of* deal with this already might mean > > that > > the difference is minimal WRT community issues. Have you tried asking > > Intel if > > they would switch to open publication of the library (not for open sourcing > > it, > > although that wouldn't suck). > > I have reached out to them regarding open publication of the library and am > waiting for an answer from them. ack - thanks > > > > > #2 Legal aspects: > > = > > > > Any discussion of the legal aspects will start with a copy of the license > > itself. > > We're stuck without that. We need to understand what we are dealing with > > here in the project first, and then we should bring any questions to legal- > > discuss@a.o after our initial review. > > I have asked them for the license text of the library. Waiting to get it from > them. > ack - thanks - just post it to this thread (or point us to the doc URL) when you have it. > Regards, > Devdeep > > > > -chip > >
RE: Regrading support for intel txt
> -Original Message- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Tuesday, May 14, 2013 6:58 PM > To: dev@cloudstack.apache.org > Subject: Re: Regrading support for intel txt > > On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: > > 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 > > This is problematic IMO for 2 reasons: > > #1 Community angle: > === > > If it's not possible for some to access that library, even if we make it it's > own > build target, then how can anyone test it? On one hand, we place a burden > on ourselves in a similar way for every non-oss dependency. On the other > hand, the fact that we already *sort of* deal with this already might mean > that > the difference is minimal WRT community issues. Have you tried asking Intel > if > they would switch to open publication of the library (not for open sourcing > it, > although that wouldn't suck). I have reached out to them regarding open publication of the library and am waiting for an answer from them. > > #2 Legal aspects: > = > > Any discussion of the legal aspects will start with a copy of the license > itself. > We're stuck without that. We need to understand what we are dealing with > here in the project first, and then we should bring any questions to legal- > discuss@a.o after our initial review. I have asked them for the license text of the library. Waiting to get it from them. Regards, Devdeep > > -chip
Re: Regrading support for intel txt
On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: > 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 This is problematic IMO for 2 reasons: #1 Community angle: === If it's not possible for some to access that library, even if we make it it's own build target, then how can anyone test it? On one hand, we place a burden on ourselves in a similar way for every non-oss dependency. On the other hand, the fact that we already *sort of* deal with this already might mean that the difference is minimal WRT community issues. Have you tried asking Intel if they would switch to open publication of the library (not for open sourcing it, although that wouldn't suck). #2 Legal aspects: = Any discussion of the legal aspects will start with a copy of the license itself. We're stuck without that. We need to understand what we are dealing with here in the project first, and then we should bring any questions to legal-discuss@a.o after our initial review. -chip
RE: Regrading support for intel txt
Hi David, I got the library directly from intel ftp site with the username and credentials they had shared. Not sure if I can share these details publicly :(. Regards, Devdeep > -Original Message- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Monday, May 13, 2013 8:23 PM > To: dev@cloudstack.apache.org > Subject: Re: Regrading support for intel txt > > On Mon, May 13, 2013 at 7:27 AM, Devdeep Singh > wrote: > > 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? Once it is resolved that the license allows nonoss or > even oss, we move it there? > > > > [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 > > > Devdeep: > > First, thanks for bringing this issue to the list. I greatly appreciate it. > Second: Is there a link to this library? > > --David
RE: Regrading support for intel txt
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
Re: Regrading support for intel txt
On Mon, May 13, 2013 at 7:27 AM, Devdeep Singh wrote: > 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? Once it is resolved that the license > allows nonoss or even oss, we move it there? > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+Intel+TXT+Technology > [2] https://github.com/devdeep/cloudstack/tree/intel-txt > > Regards, > Devdeep Devdeep: First, thanks for bringing this issue to the list. I greatly appreciate it. Second: Is there a link to this library? --David
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. 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
