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. -- Andrea Bolognani / Red Hat / Virtualization
