Hi Sean,
please review these commits in drbdmanage upstream:
http://git.drbd.org/drbdmanage.git/commit/2312d7e7657f98728b6ae1601d8c77010f6adca2
http://git.drbd.org/drbdmanage.git/commit/24ff36ec21f5b7cfdfe38b1888b64eb01f463240
Basically everything behind the dbus API GPL-v3. All files included by
Jeremy Stanley wrote:
> On 2016-12-12 16:44:53 + (+), Duncan Thomas wrote:
> [...]
>> Having read the Openstack rules linked to earlier in the thread
>> ( https://governance.openstack.org/tc/reference/licensing.html )
>> we're clearly violating that.
> [...]
>
> Keep in mind that those gui
On Mon, Dec 12, 2016 at 07:58:17AM +0100, Mehdi Abaakouk wrote:
> Hi,
>
> I have recently seen that drbdmanage python library is no more GPL2 but
> need a end user license agreement [1].
>
> Is this compatible with the driver policy of Cinder ?
>
> [1]
> http://git.drbd.org/drbdmanage.git/commi
On 2016-12-12 16:44:53 + (+), Duncan Thomas wrote:
[...]
> Having read the Openstack rules linked to earlier in the thread
> ( https://governance.openstack.org/tc/reference/licensing.html )
> we're clearly violating that.
[...]
Keep in mind that those guidelines were drafted in collaborati
Agreed. Just saying that if the software is important to the community, but
the distribution/licensing terms are not, there's always a solution. That's
all I was trying to get at. If, however, resources don't avail themselves,
that can also be indicative that the need vs issue isn't overwhelming.
On 12 December 2016 at 16:35, Ash wrote:
> I tend to agree with you, Sean. Also, if there's a concern that some
> project has changed its license, then just create a fork. In the case of
> this previously GPL code, it will at least be re-distributable. In the end,
> I just don't think this is a h
On 12 December 2016 at 16:14, Sean McGinnis wrote:
>
> Honestly, my opinion is it's just fine as it is, and the fact that this
> license has changed doesn't make any difference.
>
> For most external storage there is _something_ that the deployer needs
> to do outside of install and configure Ope
I tend to agree with you, Sean. Also, if there's a concern that some
project has changed its license, then just create a fork. In the case of
this previously GPL code, it will at least be re-distributable. In the end,
I just don't think this is a huge issue that cannot be easily managed.
On Mon, D
On Mon, Dec 12, 2016 at 03:07:23PM +, Duncan Thomas wrote:
> On 12 December 2016 at 14:55, Andreas Jaeger wrote:
>
> >
> > So, what are the steps forward here? Requiring a non-free library like
> > drbdmanage is not acceptable AFAIU,
> >
>
> This is pretty much where things went dead at the
On 12 December 2016 at 14:55, Andreas Jaeger wrote:
>
> So, what are the steps forward here? Requiring a non-free library like
> drbdmanage is not acceptable AFAIU,
>
This is pretty much where things went dead at the summit - there were
various degrees of unacceptability (I was personally bother
On 2016-12-12 15:46, Sean McGinnis wrote:
> On Mon, Dec 12, 2016 at 11:00:41AM +, Duncan Thomas wrote:
>> It's a soft dependency, like most of the vendor specific dependencies - you
>> only need them if you're using a specific backend. We've loads of them in
>> cinder, under a whole bunch of li
On Mon, Dec 12, 2016 at 08:46:55AM -0600, Sean McGinnis wrote:
> On Mon, Dec 12, 2016 at 11:00:41AM +, Duncan Thomas wrote:
> > It's a soft dependency, like most of the vendor specific dependencies - you
> > only need them if you're using a specific backend. We've loads of them in
> > cinder, u
On Mon, Dec 12, 2016 at 11:00:41AM +, Duncan Thomas wrote:
> It's a soft dependency, like most of the vendor specific dependencies - you
> only need them if you're using a specific backend. We've loads of them in
> cinder, under a whole bunch of licenses. There was a summit session
> discussing
On Mon, Dec 12, 2016 at 11:00:41AM +, Duncan Thomas wrote:
It's a soft dependency, like most of the vendor specific dependencies - you
only need them if you're using a specific backend. We've loads of them in
cinder, under a whole bunch of licenses. There was a summit session
discussing it th
It's a soft dependency, like most of the vendor specific dependencies - you
only need them if you're using a specific backend. We've loads of them in
cinder, under a whole bunch of licenses. There was a summit session
discussing it that didn't come to any firm conclusions.
On 12 December 2016 at 1
On Mon, Dec 12, 2016 at 11:52:50AM +0100, Thierry Carrez wrote:
That said, it doesn't seem to be listed as a Cinder requirement right
now ? Is it a new dependency being considered, or is it currently flying
under the radar ?
I think this is because this library is not available on Pypi.
--
Meh
On 2016-12-12 11:52, Thierry Carrez wrote:
> Mehdi Abaakouk wrote:
>> I have recently seen that drbdmanage python library is no more GPL2 but
>> need a end user license agreement [1].
>> Is this compatible with the driver policy of Cinder ?
>
> It's not acceptable as a dependency of an OpenStack p
Mehdi Abaakouk wrote:
> I have recently seen that drbdmanage python library is no more GPL2 but
> need a end user license agreement [1].
> Is this compatible with the driver policy of Cinder ?
It's not acceptable as a dependency of an OpenStack project (be it GPLv2
or using a custom EULA), see:
h
On Mon, 2016-12-12 at 07:58 +0100, Mehdi Abaakouk wrote:
Hi,
I have recently seen that drbdmanage python library is no more GPL2 but
need a end user license agreement [1].
Is this compatible with the driver policy of Cinder ?
[1]
http://git.drbd.org/drbdmanage.git/commitdiff/441dc6a96b0bc6a08d
Hi,
I have recently seen that drbdmanage python library is no more GPL2 but
need a end user license agreement [1].
Is this compatible with the driver policy of Cinder ?
[1]
http://git.drbd.org/drbdmanage.git/commitdiff/441dc6a96b0bc6a08d2469fa5a82d97fc08e8ec1
Regards
--
Mehdi Abaakouk
mail
20 matches
Mail list logo