<br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 2:01 PM, Chuck Short <span dir="ltr"><<a href="mailto:chuck.short@canonical.com" target="_blank">chuck.short@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 13-03-19 03:06 PM, Russell Bryant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/19/2013 02:56 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/19/2013 02:16 PM, Russell Bryant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/19/2013 01:54 PM, Russell Bryant wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/19/2013 01:31 PM, Mark McLoughlin wrote:<br>
</blockquote></blockquote>
<snip><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be clear, I'm really not sure whether this is our policy either. I<br>
guess I always assumed it was, but that's based on nothing substantive.<br>
</blockquote>
So Sean, if you were doing a license review, was this the only (A)GPL<br>
dependency you found (are there any GPL deps) ?<br>
</blockquote>
For the record, I was speaking to Sean and neither of us know of any<br>
problematic Python dependencies in the Folsom release. This would only<br>
apply to new dependencies introduced in the Grizzly timeframe.<br>
</blockquote>
The list of new dependencies for Grizzly that got are the following:<br>
<br>
jsonpointer BSD-like 0.5<br>
python-alembic MIT 0.4.2<br>
python-jsonpatch BSD-like 0.10<br>
python-openssl (pyOpenSSL) Apache V2 0.13<br>
python-rtslib AGPL V3 2.1.fb27<br>
python-stevedore Apache V2 0.8<br>
<br>
All the others are fine and license compatible besides python-rtslib.<br>
</blockquote>
Great, thanks. So how about we do this:<br>
<br>
1) Move cinder-rtstool to its own separate repo (rtstool). This could<br>
be on stackforge for convenience, but it would not be an official<br>
OpenStack project.<br>
</blockquote>
<br></div></div>
Sure why dont we ask the cinder people how they want to handle this.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Remove rtslib from the requirements list of Cinder. Don't list<br>
rtstool as a requirement.<br>
</blockquote></div>
How about we email the author of rtslib to re-license it to a more friendlier license and bump the version required by cinder?<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Make sure Cinder can gracefully handle whether or not rtstool is<br>
present on the system.<br>
</blockquote></div>
Afaik rtstool is not enabled by default so this shouldnt be a problem.<div class="im HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) The TC needs to work on clarifying license policy and ensuring that<br>
we have a process in place to make sure the policy is reviewed for each<br>
new dependency.<br>
<br>
5) Cinder folks may want to consider targetd support in Havana. It<br>
would be HTTP access to something (A)GPL licensed as opposed to having<br>
to execute something. Executing something should still be fine though<br>
AFIAK, but IANAL. :-)<br>
<br>
</blockquote></div><span class="HOEnZb"><font color="#888888">
chuck</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a></div></div></blockquote><div> </div></div>So my proposal was/is, leave the LIO driver functionality in the code but do not package the rtslib. The rtslib is the only piece that's AGPL, from there if end users/providers would like to use the LIO driver they can either choose to install/import the library theme selves. We also do in fact hope to have a replacement (read Apache licensed) version of this code going forward.<div>
<br></div><div>Right now the LIO driver and this package are optional configuration items, I think this is a descent solution that provides the driver to those that want to use and and still protects us from the issues of the ridiculous AGPL. To be honest I don't necessarily see how this proposal differs from conflicts between VMWare, Microsoft or Citrix licenses for folks that choose to use those hypervisors? </div>
<div><br></div><div>I've already removed the package entry from pip-requires (and later today that'll be irrelevant anyway when I suck in the OSLO pip/test-requires assuming testing is ok), so I was hoping that would be sufficient. There is a demand for the LIO driver from service providers and enterprise folks, so removing it altogether seems a bit harsh.</div>
<div><br></div><div>That being said, if there is some legal implications still and a concern I'll surely yield on this and just remove any mention of rtslib from the code.</div><div><br></div><div>Thanks,</div><div>John</div>