cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Schweikert <>
Subject License question
Date Fri, 18 May 2012 17:56:30 GMT
I am not a lawyer, but....

As I ran a diff between the 3.0.1 tarball and the recently released 
3.0.2 tarball I stumbled across a license issue. Having already built 
3.0.1 packages in OBS I might be in trouble already, but I didn't read 
it all and figured I'd ask some questions first.

The source contains a license in build/license that is an EULA and 
appears to be geared toward the Citrix Product. This made me poke around 
to find a page [1] where it clearly states that 3.0 is licensed under 
GPLv3 and 3.1 will be licensed under ASLv2.

In the 3.0.1 and 3.0.2 license it states "The PRODUCT is the Citrix 
proprietary software program in object code form distributed hereunder." 
which would appear to be in conflict with GPLv3 at least, and based on 
my interpretation 3.0.x should still be licensed under GPLv3.

Before I start with my questions let me state that I don't really care 
whether the code if licensed under ASLv2 or GPLv3. I have no intention 
of starting a political flame war or discussion about license choice. I 
am concerned about this from a packagers point of view only.

- It appears to me that build/license should be removed from the source 
code, all branches?

- Should there not be a LICENSE file at the top of the source tree that 
clearly states the license that covers the tree?

- Is the plan to create a 3.1 branch once the code base moves to the ASF 

- How does the license change affect the master branch? After all, 
calling something 3.1 vs. 3.0 is an artifact of the source control 
system, or will this be date/commit based, i.e. as of commit X the 
master branch is considered ASLv2? (And maybe commit X coincides with 
the creation of the 3.1 branch)

- Is there someone from Citrix specifically tasked to remove artifacts 
like this from the code base? It would be difficult for community 
contributors to feel confident/comfortable in sending submit request to 
remove artifacts like this from the code base.



Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead

View raw message