incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Thrift release legal issues
Date Mon, 17 Aug 2009 01:10:11 GMT

On Aug 16, 2009, at 5:38 PM, Joe Schaefer wrote:

>>
>> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
>>>
>>> I've also found that there are 6 individuals listed in the
>>> Facebook CCLA who do not have ICLAs with us and have accordingly
>>> contacted them as well.
>>
>> Was the Facebook CCLA a software grant and were the 6 individuals  
>> Facebook
>> employees (if not, why were they listed in the CCLA)?
>
> They were not Facebook employees.  The individuals in question were  
> listed
> as exclusions to the covered contributions. See
>
> https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf

Thanks for the clarification.  I would think we would want ICLAs from  
those 6. I don't suppose these folks had to sign anything before the  
code was contributed to Apache? Out of curiosity, what license was the  
code under before it came to Apache?

>
>>
>>>
>>> So the first question is: do we have any contingency strategies
>>> for the likely situation where not all past contributors to Thrift
>>> will have paperwork on file in the near future?  Can Thrift still
>>> cut a release or does that block it?  Thrift was in fact an open
>>> source project prior to coming here, and it *has* released stuff  
>>> under
>>> an alternate license.  Does that mitigate the issue at all?
>>
>> See my comment above.
>>
>>>
>>> The second question regards the LICENSE file.  I'm accustomed to
>>> seeing all the licenses for all the code to be distributed listed
>>> in the LICENSE file, but don't see anywhere within the Incubator
>>> docs that this concept is mandatory.  I've been pushing Thrift to
>>> do this because that's the way I've usually seen it done but the
>>> idea hasn't gained any traction with the thrift devs yet.  Is there
>>> such a policy, does it simply constitute best practice, or am I
>>> barking up the wrong tree?
>>
>> I was under the impression the LICENSE file should contain the  
>> Apache license.
>> All other licenses should be referenced in the NOTICE file. See
>> http://www.apache.org/licenses/.
>
> That's not the way the Apache HTTPD Server manages their LICENSE file.
> Each 3rd party component's corresponding license is included in the
> LICENSE file.

Perhaps I misunderstand how the LICENSE and NOTICE files are to be  
used then. The link above actually includes a link to an HTTPD server  
NOTICE file as an example. That sample NOTICE file does not include  
the actual license text and doesn't contain either the 3rd party  
license or a link to it so it clearly isn't sufficient. However, https://issues.apache.org/jira/browse/LEGAL-31

, which discusses this, is still unresolved.

>>
>>> The third issue is that Thrift intends to distribute with an LGPL
>>> dependency on their build system.  I'm familiar with the scary  
>>> language
>>> adopted by the legal team regarding the LGPL, but don't consider  
>>> this
>>> situation to be problematic since it's just a few Makefiles and  
>>> such.
>>> Will I need to get special permission from legal for this?
>>
>> If they are using Maven 2 and if the LGPL dependency is referenced  
>> as a
>> dependency in the pom such that it is downloaded during the build  
>> and is not
>> distributed with Apache software (or if the build process is  
>> functionally
>> equivalent to this), I personally would have no problem with it  
>> being used as
>> part of the build.
>
> It's a C-style project, with C-style Makefiles.  Nothing is  
> downloaded during
> the build process- the LGPL'd Makefiles in question are in  
> subversion and to
> be distributed within a release package.

My preference is that works under Category X shouldn't be in Apache  
SVN nor should they be distributed as part of an Apache release. I  
believe that is in general alignment with conversations on legal- 
discuss in the past but I would expect that to get answered in the  
Jira issue, should one be created.

Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message