Re: [PATCH] storage: fix vstorage backend build

On Mon, 2020-07-13 at 11:52 +0300, Nikolay Shirokovskiy wrote: > On 13.07.2020 09:57, Nikolay Shirokovskiy wrote: >> On 10.07.2020 21:17, Andrea Bolognani wrote: >>> If you look at the list of packages through the provided "repoview" >>> files, the releases from the second repository contain many more: >>> additional categories include things like "Readykernel", Virtuozzo >>> High Availability" and, most interesting to us, "Virtuozzo Storage". >>> >>> As mentioned in my previous message, some of these packages appear to >>> be released not under the (L)GPL but under a "Virtuozzo" license that >>> I haven't been able to find anywhere, and I'm not entirely sure is >>> actually open source. >> >> We have Virtuozzo product and part of it is available as open source >> from openvz.org repo. Virtuozzo Storage is not open source but it >> can be used with very limited storage size without license keys. >> I guess you would want to read license anyway before using Virtuozzo >> Storage packages in CI but I'm going to remove these packages >> requirements anyway as I wrote in reply to Andrea's message. > > After giving it more thought I think it is useful to have vstorage > m4 script as it is. It is useful to detect vstorage-mount binary > path at build time. Although Virtuozzo Storage is not open source > and can not be build for distributions with different binary paths > by community it is a part of different Virtuozzo products and > theoretically speaking the path can be changed from product to product. > So it is useful to have path not hardcoded and not detected at runtime. If runtime detection is good enough for qemu-img, I don't see why it wouldn't be good enough for vstorage too. > Before we fix our repos please take a look at Virtuozzo license at [1] > (note there is different tabs and EULA tab). > > [1] https://www.virtuozzo.com/legal.html Yeah, sorry, but I'm not going to put my name on a patch that results in our build environments suddenly including proprietary software. I'm already not a fan that happening based on principles alone, and I most certainly don't want to deal with any potential fallout from our container images violating the EULA or whatnot.