Open Stack

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