Open Stack

On 2015-01-14, Stefano Maffulli <stefano at openstack.org> wrote:
> 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 paragraph you quote was not about the licensing of the output,
but of the tool itself.

> The image builder can safely
> ignore the license of the individual packages put in the distribution

I'm not sure, you elaborate on it below, see my answer there.

> (especially if those images are not going to be distributed --use vs
> distribution).

Yes. Note though that the  more interesting case is when the images are
going to be distributed. That's part of the scenario for which we need this
project.

> 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's still about the licensing of the meta-tool itself. Building a bootable
image from source most likely involves patching some of the involved sources.
Say we include GNU grep, and we need to patch it for whatever reason.
Then we (the image builder meta-tool) engage in distributing patches
for GPLv3 covered code. Due to the copyleft nature of GPLv3, the patch
must be covered by GPLv3 as well. That is, we are then not in the position
of uniformly licensing the meta-tool according our preferences.

> 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. 

I also likened our planned tool to a compiler, however, there is a catch:
usually the compiler outputs an opaque blob, while the image is a container
for other software. So its also like an archiver. You can't say a tarball
can be distributed with no respect to its content, right?

> 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

Regarding the case when the program "copies parts of itself into the output",
the given case study (Bison) operates via a dedicated licensing excpetion.
If we base our work on a GPL tool that does not have such a lincensing exception,
then we won't be in the position to add one.

However, in this case the container (or aggregate) nature of the image is helping us:
this won't force a lincense on the whole image, only the copied parts, as these are
possible to extract that separately from the aggregate.

>> - 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.

That you don't understand it probably just reflects my confusion.
But just think of the live media of your favourite Linux distro.
That's quite a similar case. So, in summary, I don't think licensing
the images would be an issue; however, probably we are better to
provide some "EULA".

Csaba