On Tue, 2015-01-13 at 18:28 +0000, Csaba Henk wrote: > What we are puzzled on is the license. This is something we have to > figure out before we think of setting up the project. In general it's > understood that Apache License (v2) is preferred. Question: > is that a strict requirement on Stackforge or just a suggestion?
As fungi said, there are no strong requirements for Stackforge. On Tue, 2015-01-13 at 14:15 -0500, Doug Hellmann wrote: > The foundation does have some rules that apply to official projects, > though I believe those rules, in practice, apply only to things (for lack of a better word) that intend to use an OpenStack trademark. The trademark rules are hopefully going to get more clear as DefCore makes more progress. > - Lot of related previous art are GPL/LGPL licensed in entirety or > partially so we have to know if can use them. I have the impression there are some OpenStack repositories already incorporating LGPL software. IIRC there was a thread on legal-discuss about this. > - Note that the image project is different from standard Openstack > related projects because it's a "meta-tool", like a compiler: > you don't deploy it on site, what you deploy is it's outcome > (a VM image). This makes me thing that it's not a service with a public API, or is it? In other words, do you think that DefCore will consider this project/meta-tool as a factor to decide if a cloud (distribution) is compatible with another? If the answer is not or unlikely then I'd not worry too much about the 'openstack officiality' of this project. > - AFAIU #1: the VM image (the output of the tool) is considered to be > a distribution of all the sofware contained in it, which means that > an image builder has to comply with licensing of these software > individually, and patches that are applied on the sources might be > constrained in terms of licensing (if the source is covered by a > copyleft license). So it's not feasible to have a pure > APLv2 image builder anyway. What licensing of the image builder > itself (ie. not the patches) has an impact on is the "scaffolding" > bundled with the image (init scripts, etc). this is complicated :) If I understood you correctly, you're wrong here: whatever license you pick for your meta-tool, the license of its output (the distribution) won't be affected by it. The image builder can safely ignore the license of the individual packages put in the distribution (especially if those images are not going to be distributed --use vs distribution). I don't understand the sentence: > [the image builder] has to comply with licensing of [...] patches that > are applied on the sources Which sources? What patches is the image builder going to apply, to which package? It may make sense to review how copyright works with GNU Compiler Collection (gcc), if you haven't read that recently. GCC is distributed with strong copyleft and yet it's used to build very proprietary executables. So, it's not true that if you license the manila-image-builder you can only build 'free as in freedom' distributions. The license of a compiler doesn't 'transfer' over to its output. Even if the builder tool puts something of itself into its output (like it copies init-scripts from itself into the image), there is an argument that the output can still be *not* a derivative. The FSF has an article about this case, written to explain GNU bison's behaviour: http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF > - AFAIU #2: the above concerns the one who would like to use and customize > the image builder; regarding the end user who just receives and deploys > the image, and applies changes/updates to it from the distributor > of the image (if there is such a feature), the distributor is free > to specify the terms of usage, as long as the image is made of open > source software. I'm afraid I can't understand this part. I guess you'll have to provide more details and examples of how the tool is supposed to work, what packages it will collect and distribute from whom to whom. The key element to understand which license "transfers" to other software is to find the answer to the question: is this thing a derivative of this other thing? and ask the question iteratively going upstream, from the final output (the image built) all the way up to its individual pieces. HTH IAmNotALawyerThisIsNotALegalAdvice /stef _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
