Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4EB3B1093E for ; Thu, 5 Dec 2013 17:11:03 +0000 (UTC) Received: (qmail 38459 invoked by uid 500); 5 Dec 2013 17:10:44 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 37922 invoked by uid 500); 5 Dec 2013 17:10:37 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 37492 invoked by uid 99); 5 Dec 2013 17:10:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Dec 2013 17:10:35 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lrosen@rosenlaw.com designates 69.89.21.30 as permitted sender) Received: from [69.89.21.30] (HELO qproxy5-pub.mail.unifiedlayer.com) (69.89.21.30) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 05 Dec 2013 17:10:28 +0000 Received: (qmail 23969 invoked by uid 0); 5 Dec 2013 17:10:01 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 5 Dec 2013 17:10:01 -0000 Received: from box597.bluehost.com ([66.147.242.197]) by cmgw4 with id xspw1m0064GF2VN01spz9l; Thu, 05 Dec 2013 09:50:01 -0700 X-Authority-Analysis: v=2.1 cv=YfYuuWhf c=1 sm=1 tr=0 a=NRJ8aB/FPT4S3utBguGD+g==:117 a=NRJ8aB/FPT4S3utBguGD+g==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=7xXQEuv9rCMA:10 a=CAIbOuo8jNoA:10 a=4F77bVRYAAAA:8 a=eqQm58-ZDxgA:10 a=8R_FMjEeVzQA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=TJlWWBcRAAAA:8 a=VnNF1IyMAAAA:8 a=mV9VRH-2AAAA:8 a=pGLkceISAAAA:8 a=yoZLVtSTPqsd1VXljMMA:9 a=5KmWPyS1s-RC5XMj:21 a=BUDZ57OOoZ9uV8dc:21 a=CjuIK1q_8ugA:10 a=9YgvnxIEo9AA:10 a=_FjPflug3ysA:10 a=88iI8knYSJUA:10 a=MSl-tDqOz04A:10 a=tn4vnrMEJvYA:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=-KqoPF3jt2MOcAfJhzYA:9 a=6qzA9QuLwG-VeO2d:21 a=jrDBQmGmEqRHmWH8:21 a=l_Hf5faXO_kezEGc:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rosenlaw.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Reply-To; bh=r/Rylo8SIIj77dE3eLhg4DU12775E1ZAmwzY7+69w3c=; b=lCuOoDmIDZbO5h22WIlditT1O1g1JBTTREaJ0htsFrUEhxkZPmCrgLVxme72a8vhMJRvqT3umnU50k0yHPcnasP3QdH6u74ngyhoBm9wXgWtwJGZT8x0vWUfEeMAtqNj; Received: from [70.36.224.178] (port=23682 helo=Lawrencei) by box597.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Voc7e-0002yw-1F; Thu, 05 Dec 2013 09:49:54 -0700 Reply-To: From: "Lawrence Rosen" To: Cc: "Lawrence Rosen" References: <12a701ceed29$db0e69c0$912b3d40$@rosenlaw.com> <01a601cef121$81169a40$8343cec0$@rosenlaw.com> <021601cef154$3a33e730$ae9bb590$@rosenlaw.com> In-Reply-To: Subject: RE: New versions of CC licenses Date: Thu, 5 Dec 2013 08:49:56 -0800 Organization: Rosenlaw & Einschlag Message-ID: <02e301cef1da$07dc3680$1794a380$@rosenlaw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E4_01CEF196.F9BCA000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBseB/b1X7vSe1nMEU/NEc+cDIWADd+wYxAg3JO/gCNTkjQQCfmg+fAlKz7soCZN9yUgHuMk6uAXyEVoUBBfaMTwJ5/ToImlU0B8A= Content-Language: en-us X-Identified-User: {1397:box597.bluehost.com:rosenla1:rosenlaw.com} {sentby:smtp auth 70.36.224.178 authed with lrosen@rosenlaw.com} X-Virus-Checked: Checked by ClamAV on apache.org ------=_NextPart_000_02E4_01CEF196.F9BCA000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jeff Thompson wrote: > I'm focused on a very narrow question of great practical import. Does a commercial user have to change their pre-existing licenses in order to incorporate the OSS into their product. If the answer is "yes", then the OSS license is not commercially friendly. If its "no", then it is. And I'm focused on a much broader question of greater strategic import. Does Apache have to limit the kinds of contributions it accepts because certain commercial customers don't like certain FOSS licenses? You may not be aware that at least one Apache project (Open Office) has even incorporated GPL contributions (dictionaries) into its distributed product. That train has left the station. What's missing at Apache is a coherent explanation of the rules so that we all know what to expect. That is why several of us have requested that we modify the descriptions of the category A and B licenses to make them intelligible and consistent. Here's the process as I hope it would be: 1. An Apache project is free to incorporate any FOSS contributions as long as the contribution license allows wrapping that contribution into software distributed collectively under the Apache License 2.0. 2. The project must identify those dependencies in its NOTICE file. 3. The project must provide source code to the entire distribution, including those contributions. 4. The project will distribute the entire software under the Apache License 2.0. The rest is up to the user. In particular, as a commercial distributor your company should read the NOTICE file. You can decide for yourselves whether (e.g.,) you want to include in your own products the GPL or CC-BY components in our software. You have enough engineers available to do what it takes to make your distributed software consistent with your own licenses. Don't burden us with your own restricted view of FOSS licensing. Believe me, as a licensing lawyer I'm very sympathetic to your concern that this may open up your own customer licenses for renegotiation. But personally I would never have negotiated a license that included future upgrades without leaving myself open to any upgrades that I think are reasonable.... But the fact that you did so should not result in any restrictions on allowing Apache projects to include FOSS components that make our software better. /Larry Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com ) 3001 King Ranch Rd., Ukiah, CA 95482 Office: 707-485-1242 Linkedin profile: http://linkd.in/XXpHyu From: Jeffrey Thompson [mailto:jthom@us.ibm.com] Sent: Thursday, December 05, 2013 7:15 AM To: legal-discuss@apache.org Subject: Re: New versions of CC licenses Stephen Connolly wrote on 12/05/2013 09:52:32 AM: > On 5 December 2013 14:43, Jeffrey Thompson wrote: >> Stephen, >> I haven't addressed the DRM restriction. I'm talking about the >> license terms under which the customer receives the combined work. > > yes and as long as you can maintain your rights on the individual > components *as* individual components (i.e. extracted from the > combined work) what is the issue if the license terms of the > combined work *as a whole* are more restrictive. I'm focused on a very narrow question of great practical import. Does a commercial user have to change their pre-existing licenses in order to incorporate the OSS into their product. If the answer is "yes", then the OSS license is not commercially friendly. If its "no", then it is. CC-BY is not commercially friendly. It states that the commercial user MUST pass on all rights and cannot prohibited modification or distribution (at least as to those components). So, if a commercial entity had previously agreed with a customer on a license which generally prohibits modification and redistribution (not uncommon), then incorporation of CC-BY components in any software that is going to be provided under that unmodified pre-existing agreement would violate the CC-BY terms. It doesn't matter that the customer is getting MORE rights under the CC-BY license. The rights are different. To the procurement officer at the customer's shop, its more work. S/He has to re-open the agreement, negotiate the modification, get legal approval, etc. Like I said before, its a narrow question, but has a big practical impact. The result is that the customer either (a) won't agree to take the new software or (b) the transaction will be delayed for weeks/months while a new procurement cycle is processed. Think of it as the commercial analog of the OSS license proliferation problem. There's nothing illegal or immoral about every OSS project writing their own OSS license and insisting that the license carry forward through the distribution chain. But, things aren't very efficient that way. It makes consuming the output of other projects harder and creates potential licensing conflicts even though there is no real benefit. Thankfully, most OSS project select established licenses and many choose licenses that permit the code to be distributed under other terms (as long as the rights passed on are a subset of what is received). Jeff Counsel, IBM Software Group ------=_NextPart_000_02E4_01CEF196.F9BCA000 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Jeff Thompson wrote:

> I'm focused on a = very narrow question of great practical import.  Does a commercial = user have to change their pre-existing licenses in order to incorporate = the OSS into their product.  If the answer is "yes", then = the OSS license is not commercially friendly.  If its = "no", then it is.  

And I'm focused on a much broader question of greater strategic = import. Does Apache have to limit the kinds of contributions it accepts = because certain commercial customers don't like certain FOSS licenses? =

 

You may not be aware that at least one Apache project (Open Office) = has even incorporated GPL contributions (dictionaries) into its = distributed product. That train has left the station. What's missing at = Apache is a coherent explanation of the rules so that we all know what = to expect. That is why several of us have requested that we modify the = descriptions of the category A and B licenses to make them intelligible = and consistent.

 

Here's the process as I hope it would be:

 

1. An Apache project is free to incorporate any FOSS = contributions as long as the contribution license allows wrapping that = contribution into software distributed collectively under the Apache = License 2.0.

 

2. The project must identify those dependencies in its NOTICE = file.

 

3. The project must provide source code to the entire distribution, = including those contributions.

 

4. The project will distribute the entire software under the Apache = License 2.0.

 

The rest is up to the user. In particular, as a commercial = distributor your company should read the NOTICE file. You can decide for = yourselves whether (e.g.,) you want to include in your own products the = GPL or CC-BY components in our software. You have enough engineers = available to do what it takes to make your distributed software = consistent with your own licenses. Don't burden us with your own = restricted view of FOSS licensing.

 

Believe me, as a licensing lawyer I'm very sympathetic to your = concern that this may open up your own customer licenses for = renegotiation. But personally I would never have negotiated a license = that included future upgrades without leaving myself open to any = upgrades that I think are reasonable.... But the fact that you did so = should not result in any restrictions on allowing Apache projects to = include FOSS components that make our software = better.

 

/Larry

 

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)=

3001 King Ranch Rd., Ukiah, CA 95482

Office: 707-485-1242

Linkedin profile: http://linkd.in/XXpHyu =

 

From:= = Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Thursday, = December 05, 2013 7:15 AM
To: = legal-discuss@apache.org
Subject: Re: New versions of CC = licenses

 

Stephen Connolly <stephen.alan.connolly@gma= il.com> wrote on 12/05/2013 09:52:32 AM:
> On 5 = December 2013 14:43, Jeffrey Thompson <jthom@us.ibm.com> = wrote:

>> = Stephen,
>>     I haven't addressed the DRM = restriction.  I'm talking about the
>> license = terms under which the customer receives the combined = work.
> =
> yes and as long as you can maintain your rights on = the individual
> components *as* individual components = (i.e. extracted from the
> combined work) what is the = issue if the license terms of the
> combined work *as a = whole* are more restrictive.

I'm focused on a very narrow question of = great practical import.  Does a commercial user have to change = their pre-existing licenses in order to incorporate the OSS into their = product.  If the answer is "yes", then the OSS license is = not commercially friendly.  If its "no", then it is. =  

CC-BY is = not commercially friendly.  It states that the commercial user MUST = pass on all rights and cannot prohibited modification or distribution = (at least as to those components).  So, if a commercial entity had = previously agreed with a customer on a license which generally prohibits = modification and redistribution (not uncommon), then incorporation of = CC-BY components in any software that is going to be provided under that = unmodified pre-existing agreement would violate the CC-BY = terms.

It = doesn't matter that the customer is getting MORE rights under the CC-BY = license.  The rights are different.  To the procurement = officer at the customer's shop, its more work. S/He has to re-open the = agreement, negotiate the modification, get legal approval, etc. =  Like I said before, its a narrow question, but has a big practical = impact.  The result is that the customer either (a) won't agree to = take the new software or (b) the transaction will be delayed for = weeks/months while a new procurement cycle is = processed.

Think = of it as the commercial analog of the OSS license proliferation problem. =  There's nothing illegal or immoral about every OSS project writing = their own OSS license and insisting that the license carry forward = through the distribution chain.  But, things aren't very efficient = that way.  It makes consuming the output of other projects harder = and creates potential licensing conflicts even though there is no real = benefit.  Thankfully, most OSS project select established licenses = and many choose licenses that permit the code to be distributed under = other terms (as long as the rights passed on are a subset of what is = received).

Jeff
Counsel, IBM Software = Group

------=_NextPart_000_02E4_01CEF196.F9BCA000--