On 13.07.2020 12:16, Andrea Bolognani wrote: > 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. > Ok, given all the license stuff and the fact we can just use runtime binary detection let's go with this variant. I'll send the patch. Nikolay
