<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 2:32 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Thu, Sep 08, 2016 at 10:24:09AM +0200, Thierry Carrez wrote:<br>
> Avishay Traeger wrote:<br>
> > There are a number of drivers that require closed-source tools to<br>
> > communicate with the storage. 3 others that I've come across recently:<br>
> ><br>
> > * EMC VNX: requires Navisphere CLI v7.32 or higher<br>
> > * Hitachi storage volume driver: requires RAID Manager Ver 01-32-03/01<br>
> > or later for VSP G1000/VSP/HUS VM, Hitachi Storage Navigator Modular<br>
> > 2 (HSNM2) Ver 27.50 or later for HUS 100 Family<br>
> > * Infortrend driver: requires raidcmd ESDS10<br>
><br>
> If those proprietary dependencies are required for operation, those<br>
> would probably violate our licensing policy[1] and should probably be<br>
> removed:<br>
><br>
> "In order to be acceptable as dependencies of OpenStack projects,<br>
> external libraries (produced and published by 3rd-party developers) must<br>
> be licensed under an OSI-approved license that does not restrict<br>
> distribution of the consuming project. The list of acceptable licenses<br>
> includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses<br>
> considered incompatible with this requirement include GPLv2, GPLv3, and<br>
> AGPL."<br>
<br>
</span>That policy is referring to libraries (ie, python modules that we'd<br>
actually "import" at the python level), while the list above seems to be<br>
referring to external command line tools that we merely invoke from the<br>
python code. From a license compatibility POV there's no problem, as there's<br>
a boundary between the open source openstack code, and the closed source<br>
external program. Talking to a closed source external command over stdio,<br>
is conceptually no different to talking to a closed source server over<br>
some remote API.<br>
<br>
Regards,<br>
Daniel<br>
<span class="gmail-HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/<wbr>dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~<wbr>danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">I think I need some clarification here. My initial interpretation was inline with Thierry's comments here</div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> "In order to be acceptable as dependencies of OpenStack projects,</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> external libraries (produced and published by 3rd-party developers) must</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> be licensed under an OSI-approved license that does not restrict</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> distribution of the consuming project. The list of acceptable licenses</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> considered incompatible with this requirement include GPLv2, GPLv3, and</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">> AGPL."</span><br></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">But I also get Daniel's point in the previous message.</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">my understanding when talking to folks about this library (and examples of things that were proposed and rejected by myself in the past):</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">1. It was in fact a module that would be imported by the Python code</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">2. It was not a binary but a source module </span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">3. The module proposed had a proprietary license that specifically prohibited redistribution</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">There have also been proposals over the years for binaries that had restrictive licenses that did NOT allow redistribution. My position in the past was always "if it was questionable or seemed like it *could* cause problems for distribution then simply don't do it".</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">All of that being said, based on feedback here, and the overwhelming feedback I received in Cinders meeting on this yesterday (and not positive feedback), it seems obvious that I must not understand our policies, the ramifications of what's being proposed etc. I'd suggest as I did yesterday that instead of running the risk of my misinterpreting what's being proposed, perhaps Arlon could detail what it is in fact that they are proposing? Some clarification regarding what the closed source piece actually is, what the licensing is, how it works etc might be useful and may prove that my concerns here are completely unwarranted. Or, the rest of the community if fine with it anyway in which case we can move along.</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">Thanks,</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px">John</span></div><br></div></div>