Open Stack

On Thu, Sep 8, 2016 at 2:32 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Thu, Sep 08, 2016 at 10:24:09AM +0200, Thierry Carrez wrote:
> > Avishay Traeger wrote:
> > > There are a number of drivers that require closed-source tools to
> > > communicate with the storage.  3 others that I've come across recently:
> > >
> > >   * EMC VNX: requires Navisphere CLI v7.32 or higher
> > >   * Hitachi storage volume driver: requires RAID Manager Ver
> 01-32-03/01
> > >     or later for VSP G1000/VSP/HUS VM, Hitachi Storage Navigator
> Modular
> > >     2 (HSNM2) Ver 27.50 or later for HUS 100 Family
> > >   * Infortrend driver: requires raidcmd ESDS10
> >
> > If those proprietary dependencies are required for operation, those
> > would probably violate our licensing policy[1] and should probably be
> > removed:
> >
> > "In order to be acceptable as dependencies of OpenStack projects,
> > external libraries (produced and published by 3rd-party developers) must
> > be licensed under an OSI-approved license that does not restrict
> > distribution of the consuming project. The list of acceptable licenses
> > includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses
> > considered incompatible with this requirement include GPLv2, GPLv3, and
> > AGPL."
>
> That policy is referring to libraries (ie, python modules that we'd
> actually "import" at the python level), while the list above seems to be
> referring to external command line tools that we merely invoke from the
> python code. From a license compatibility POV there's no problem, as
> there's
> a boundary between the open source openstack code, and the closed source
> external program. Talking to a closed source external command over stdio,
> is conceptually no different to talking to a closed source server over
> some remote API.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
​I think I need some clarification here.  My initial interpretation was
inline with Thierry's comments ​here
> "In order to be acceptable as dependencies of OpenStack projects,
> external libraries (produced and published by 3rd-party developers) must
> be licensed under an OSI-approved license that does not restrict
> distribution of the consuming project. The list of acceptable licenses
> includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses
> considered incompatible with this requirement include GPLv2, GPLv3, and
> AGPL."

But I also get Daniel's point in the previous message.

my understanding when talking to folks about this library (and examples of
things that were proposed and rejected by myself in the past):
1.  It was in fact a module that would be imported by the Python code
2.  It was not a binary but a source module
3.  The module proposed had a proprietary license that specifically
prohibited redistribution

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".

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.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/2567605a/attachment.html>