www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: code contribution licensing question
Date Thu, 13 Jan 2011 17:07:34 GMT
In practical terms, if it's big enough to be a library on github with
a category A license, VCL can just depend on it.

On Thu, Jan 13, 2011 at 11:14 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> On Thu, Jan 13, 2011 at 1:22 AM, Jennifer O'Neill <jennifer626@gmail.com> wrote:
>> The purpose of having all committers sign the ICLA is so that all "Apache"
>> code is licensed uniformly and ASF is better protected if there's a
>> challenge to the ownership of the IP.
>> If a developer wishes to contribute some material amount of code but can't
>> sign the ICLA, then his/her code contribution is evaluated just like any
>> other third-party code licensed under terms other than the ASL v.2.0.  I
>> assume that by the modified BSD, you mean the newer version that excludes
>> the advertising clause.  This license is compatible with the ASL v.2.0 and
>> there are certainly a number of Apache projects with dependencies on
>> BSD-licensed code.  Ultimately, though, it is up to the VCL project
>> committers whether to use any third-party code.
>
> I'd like to draw attention to Jennifer's use of the word 'dependency'
> here.  I agree: if VCL wanted to have an external dependency on a
> BSD-licensed KVM provisioning module then this would be no problem if
> the dependency was documented properly.
>
> 'Including' or 'merging' is a different matter entirely.  One of the
> reasons for the ICLA is that section 3 makes an explicit grant of all
> of the necessary patent licenses that the Contributor may have on the
> combination of this code with the project to which they are
> contributing.  Section 4 clarifies this with respect to individuals
> who have employers.
>
> The net of this is that 'including' or 'merging' of such code is not
> something that we would routinely allow.  That is not to say that it
> can't be done -- if you look around you will find tiny bits of public
> domain code in various projects.  It is a matter of evaluating the
> risks and the benefits on a case by case basis, and (should the
> decision be to proceed) documenting all of this properly in the
> various files that accompany a release.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message