You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Lawrence Rosen <lr...@rosenlaw.com> on 2013/11/29 18:38:45 UTC
New versions of CC licenses
Creative Commons has just published version 4 of their licenses, including
CC-BY:
http://creativecommons.org/Version4
The attribution provisions of the earlier version of CC-BY have been
criticized on this list because they go beyond the attribution requirements
of (e.g.,) the Apache License. They allow the original author to demand the
/removal/ of attribution notices from derivative works with which she
disagrees.
I believe those are common sense and reasonable provisions. I wish we had
such provisions in the Apache License. I wish we listed CC-BY as an
acceptable license for inclusion in Apache works.
/Larry
*************** From the Creative Commons FAQ on the version 4 licenses:
What can I do if I offer my material under a Creative Commons license and I
do not like the way someone uses it?
As long as users abide by license terms and conditions, licensors cannot
control how the material is used. However, CC licenses do provide several
mechanisms that allow licensors to choose not to be associated with their
material or to uses of their material with which they disagree.
First, all CC licenses
<http://wiki.creativecommons.org/Faq#Do_I_need_to_be_aware_of_anything_else_
when_providing_attribution.3F> prohibit using the attribution requirement to
suggest that the licensor endorses or supports a particular use. Second,
licensors may waive the attribution requirement, choosing not to be
identified as the licensor, if they wish. Third, if the licensor does not
like how the material has been modified or used, CC licenses require that
the licensee
<http://wiki.creativecommons.org/License_Versions#Licensors_may_request_remo
val_of_attribution> remove the attribution information upon request. (In 3.0
and earlier, this is only a requirement for adaptations and collections; in
4.0, this also applies to the unmodified work.) Finally, anyone modifying
licensed material must
<http://wiki.creativecommons.org/License_Versions#Modifications_and_adaptati
ons_must_be_indicated> indicate that the original has been modified. This
ensures that changes made to the original material--whether or not the
licensor approves of them--are not attributed back to the licensor.
*************** From the Creative Commons announcement of Version 4
licenses:
Common-sense attribution
Version 4.0 includes a slight change to
<http://wiki.creativecommons.org/Frequently_Asked_Questions#How_do_I_properl
y_attribute_material_offered_under_a_Creative_Commons_license.3F>
attribution requirements, designed to better reflect accepted practices. The
licenses explicitly permit licensees to satisfy the attribution requirement
with a link to a separate page for attribution information. This was already
common practice on the internet and possible under earlier versions of the
licenses, and Version 4.0 alleviates any uncertainty about its use.
Enabling more anonymity, when desired
Version 3.0 included a provision allowing a licensor to
<http://wiki.creativecommons.org/Faq#What_can_I_do_if_I_offer_my_work_under_
a_Creative_Commons_license_and_I_do_not_like_the_way_someone_uses_my_work.3F
> request that a licensee remove the attribution from an adaptation, if she
did not want her name associated with it. Version 4.0 expands that provision
to apply not only to adaptations but also to verbatim reproductions of a
work. Licenses now account specifically for situations where licensors wish
to disassociate themselves from uses of their works they object to, even if
their work hasn't been modified or published in a collection with other
works.
Re: New versions of CC licenses
Posted by Luis Villa <lu...@lu.is>.
On Thu, Dec 5, 2013 at 7:25 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> > based on what I know of ... what the embedded device/media-handling
>
> > device world assumes about Apache software, the addition of 2.5/3.0
>
> > to Category A was in error.
>
>
>
> Please explain what that device/media-handling world assumes about Apache
> software.
>
That the licenses software released by the Apache project is licensed under
(i.e., Category A) are as or more permissive than AL 2.0 - i.e., no
significant limitations on use other than attribution. (The CC TPM clause
has historically been a significant limitation for many modern use cases.)
> Is there something specific on our website that leads to those
assumptions?
That licenses permissible for "being a dependency to an Apache product"
must be "similar in terms" to the Apache License[1]; with the common
understanding being that the key measure of "similarity" is permissiveness,
as that is widely considered to be the most important and distinctive
feature of the Apache License.
Luis
[1] http://www.apache.org/legal/resolved.html#category-a
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Luis Villa wrote:
> ... lots of fine licenses, including the one I wrote, aren't in Category
A. :)
Although they should be. There is no reason why (e.g.,) Mozilla software
can't be combined with Apache software and distributed collectively as an
Apache-licensed work, as long as that combination can be justified by an
Apache project on technical grounds as the best solution for Apache
customers. Neither license is viral. The MPL license is
commercially-friendly, isn't it? Just disclose that combination in the
NOTICE file so that nobody downstream is surprised. :-)
> based on what I know of ... what the embedded device/media-handling
> device world assumes about Apache software, the addition of 2.5/3.0
> to Category A was in error.
Please explain what that device/media-handling world assumes about Apache
software. Is there something specific on our website that leads to those
assumptions?
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://www.rosenlaw.com/> )
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: http://linkd.in/XXpHyu
From: Luis Villa [mailto:luis@lu.is]
Sent: Thursday, December 05, 2013 6:34 PM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
On Thu, Dec 5, 2013 at 6:30 PM, Luis Villa <lu...@lu.is> wrote:
On Thu, Dec 5, 2013 at 6:17 PM, Richard Fontana <rf...@redhat.com> wrote:
On Thu, Dec 05, 2013 at 04:51:33PM -0800, Luis Villa wrote:
>
> On Thu, Dec 5, 2013 at 1:46 PM, Shane Curcuru <as...@shanecurcuru.org>
wrote:
>
> Personally I find it extraordinarily unlikely that the ASF will add
current
> CC-* licenses to category A
>
>
> As a point of information, CC BY 2.5 and 3.0 are already in Category A.
Ah, so they are.
(So what has this debate been all about then?)
If you assume they were correctly added to Category A, then there really is
no debate: 4.0 should be in there as well.
I simply think that, based on what I know of the criteria for Category A,
and what the embedded device/media-handling device world assumes about
Apache software, the addition of 2.5/3.0 to Category A was in error.
Which, to be clear, is not a condemnation of CC; lots of fine licenses,
including the one I wrote, aren't in Category A. :)
Luis
Luis
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Luis Villa <lu...@lu.is>.
On Thu, Dec 5, 2013 at 6:30 PM, Luis Villa <lu...@lu.is> wrote:
> On Thu, Dec 5, 2013 at 6:17 PM, Richard Fontana <rf...@redhat.com>wrote:
>
>> On Thu, Dec 05, 2013 at 04:51:33PM -0800, Luis Villa wrote:
>> >
>> > On Thu, Dec 5, 2013 at 1:46 PM, Shane Curcuru <as...@shanecurcuru.org>
>> wrote:
>> >
>> > Personally I find it extraordinarily unlikely that the ASF will add
>> current
>> > CC-* licenses to category A
>> >
>> >
>> > As a point of information, CC BY 2.5 and 3.0 are already in Category A.
>>
>> Ah, so they are.
>>
>> (So what has this debate been all about then?)
>>
>
> If you assume they were correctly added to Category A, then there really
> is no debate: 4.0 should be in there as well.
>
> I simply think that, based on what I know of the criteria for Category A,
> and what the embedded device/media-handling device world assumes about
> Apache software, the addition of 2.5/3.0 to Category A was in error.
>
Which, to be clear, is not a condemnation of CC; lots of fine licenses,
including the one I wrote, aren't in Category A. :)
Luis
> Luis
>
>
>> - RF
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
Re: New versions of CC licenses
Posted by Luis Villa <lu...@lu.is>.
On Thu, Dec 5, 2013 at 6:17 PM, Richard Fontana <rf...@redhat.com> wrote:
> On Thu, Dec 05, 2013 at 04:51:33PM -0800, Luis Villa wrote:
> >
> > On Thu, Dec 5, 2013 at 1:46 PM, Shane Curcuru <as...@shanecurcuru.org>
> wrote:
> >
> > Personally I find it extraordinarily unlikely that the ASF will add
> current
> > CC-* licenses to category A
> >
> >
> > As a point of information, CC BY 2.5 and 3.0 are already in Category A.
>
> Ah, so they are.
>
> (So what has this debate been all about then?)
>
If you assume they were correctly added to Category A, then there really is
no debate: 4.0 should be in there as well.
I simply think that, based on what I know of the criteria for Category A,
and what the embedded device/media-handling device world assumes about
Apache software, the addition of 2.5/3.0 to Category A was in error.
Luis
> - RF
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 04:51:33PM -0800, Luis Villa wrote:
>
> On Thu, Dec 5, 2013 at 1:46 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> Personally I find it extraordinarily unlikely that the ASF will add current
> CC-* licenses to category A
>
>
> As a point of information, CC BY 2.5 and 3.0 are already in Category A.
Ah, so they are.
(So what has this debate been all about then?)
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Luis Villa <lu...@lu.is>.
On Thu, Dec 5, 2013 at 1:46 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Personally I find it extraordinarily unlikely that the ASF will add
> current CC-* licenses to category A
As a point of information, CC BY 2.5 and 3.0 are already in Category A.
Luis
Re: New versions of CC licenses
Posted by Shane Curcuru <as...@shanecurcuru.org>.
This is an interesting thread, and it feels like I'm almost
understanding a tiny bit more of legal copyright theory - thanks for the
discussions with specific citations and detailed interpretations (even
if some seem to differ!).
Personally I find it extraordinarily unlikely that the ASF will add
current CC-* licenses to category A, so my recommendation is to not
worry about this too much. The primary reasons (for me, at least) is
precisely to ensure that the AL remains - and is seen to remain - as
commercially friendly.
- Shane
On 12/4/13 1:56 AM, Luis Villa wrote:
> On Fri, Nov 29, 2013 at 9:38 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
>> I wish we listed CC-BY as an acceptable license for inclusion in Apache
>> works.
>
> As I believe I've noted here before, CC (4.0 and earlier) has an
> anti-DRM provision that makes it a poor fit for the embedded/mobile
> space - a common use case for Apache projects these days. So I'm not
> sure it belongs in "category A". That said, if the decision has
> already been made to overlook that clause (which apparently it has
> been for 2.5 and 3.0) there is nothing else in 4.0 that would be
> problematic.
>
> Luis
>
> ---------------------------------------------------------------------
> 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
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 09:03:36AM -0500, Jeffrey Thompson wrote:
> If Apache decides that it no longer wishes to have a licensing model than
> enables both commercial and OSS use of its code, that one thing. But, until
> that happens, the fact that CC-BY contradicts a commercial licensing model,
Even accepting your whole argument, you have not shown that CC BY
contradicts commercial licensing models in general (leaving aside the
issue of creating an opposition between commercial and open
source). The GPL also doesn't contradict commercial licensing models,
but it does constrain the range of what those models can be.
You seem to be arguing that CC BY contradicts *one* commercial
licensing model, namely one in which it is difficult for the
commercial vendor to update an old license that is regarded as being
in conflict with later-added CC BY stuff. But -- for example --
clearly CC BY need not contradict commercial licensing models where CC
BY material is included in the product from the beginning. So I think
you are using a really narrow definition of "commercially unfriendly".
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 10:00:31 PM:
> I don't understand that business model at all. Is this really what
> happens with your IPLA? It seems that your problem may be
> inconsistent promises that you made to your own customers involving
> future enhancements to your own products.
>
> In any event, this has nothing to do with Apache projects and our
> software. Why should your promises to your customers prevent Apache
> from including new contributions – including under CC-BY – in our
> projects?
Larry,
If Apache decides that it no longer wishes to have a licensing model
than enables both commercial and OSS use of its code, that one thing. But,
until that happens, the fact that CC-BY contradicts a commercial licensing
model, whereas the Apache license does not, should be a sufficient reason
for Apache to be wary about including CC-BY licensed materials in its
projects, your inability to see the conflict notwithstanding.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeffrey Thompson wrote:
If there is a CC-BY set of icons that you want to include in your commercial
product, you cannot do so without changing your license. You may have the
freedom to do that, for example, if you haven't licensed that product to
anyone yet. But, you may not. Your customer may have licensed version 1.0
of the product under a pre-existing agreement that covers upgrades for a
particular period of time. So, when you come out with version 2.0
containing the new and improved icons, your existing customer automatically
receives the right to use that version under the pre-existing license, which
does not contain CC-BY terms. So, you're out of luck. You cannot use CC-BY
licensed icons in your product and simultaneously satisfy the CC-BY license
and your prior agreements with your existing customers. That's why its
inconsistent.
You have confused me completely. Is this your scenario:
1. Version 1 of your product doesn't have CC-BY icons.
2. You licensed version 1 to your customer promising upgrades in the future.
3. You choose to include Apache software containing CC-BY icons in version 2
of your product.
4. Now you say you can't deliver that new product to your customer because
of some "inconsistency"?
I don't understand that business model at all. Is this really what happens
with your IPLA? It seems that your problem may be inconsistent promises that
you made to your own customers involving future enhancements to your own
products.
In any event, this has nothing to do with Apache projects and our software.
Why should your promises to your customers prevent Apache from including new
contributions - including under CC-BY - in our projects? We have a NOTICE
file to inform you of what our projects have chosen to do, and you are free
to remove the CC-BY (or any other) dependencies if you or your customers
don't want them.
Please don't burden Apache with your own licensing idiosyncrasies. Apache
should decide what components to include in its software based primarily on
its value to our projects, and as long as we have the necessary licenses to
distribute our software to you collectively under Apache License 2.0. Read
our NOTICE files for important warnings that might affect your decision to
use our software unaltered. You are free to alter that software if necessary
to conform to your own business models!
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Wednesday, December 04, 2013 2:47 PM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 02:32:53 PM:
> You may not offer or impose any additional or different terms or
> conditions on, or apply any Effective Technological Measures to, the
> Licensed Material if doing so restricts exercise of the Licensed
> Rights by any recipient of the Licensed Material.
>
> 'Licensed Material' means the original stuff put under CC BY.
My point is that the Apache license does not contradict a commercial
licensing model, whereas the CC-BY license does.
If there is a CC-BY set of icons that you want to include in your commercial
product, you cannot do so without changing your license. You may have the
freedom to do that, for example, if you haven't licensed that product to
anyone yet. But, you may not. Your customer may have licensed version 1.0
of the product under a pre-existing agreement that covers upgrades for a
particular period of time. So, when you come out with version 2.0
containing the new and improved icons, your existing customer automatically
receives the right to use that version under the pre-existing license, which
does not contain CC-BY terms. So, you're out of luck. You cannot use CC-BY
licensed icons in your product and simultaneously satisfy the CC-BY license
and your prior agreements with your existing customers. That's why its
inconsistent.
Apache only requires you to provide a copy of the Apache license to your
customer, so when you build version 2.0, you include a Notices files with a
copy of the Apache license describing the fact that the icons are available
under this great open source license. If the customer cares enough about
the icons, it knows where to get them under the Apache license. If it
doesn't, it lives with the previously negotiated license. In neither case
are you in violation of your obligations either to your customer or the open
source project from which you obtained the icons.
> I have to agree with Larry here, at least in the context of the
> specific licenses that have been mentioned in this thread. None of the
> BSD licenses gives you permission to alter the application of the BSD
> license to the original stuff that was under the BSD license
I'm not claiming that anyone other than the copyright owner has the right to
alter the original grant. I'm stating that there is no rule that says that
a licensee has to pass on all of the rights that it received from the
copyright owner. So, as long as the licensee's outbound license is a subset
of the rights obtained, unless there is a specific condition that states
that the outbound license MUST be the same (e.g., the GPL and, it seems,
CC-BY), the licensee is OK.
BTW, this is the entire basis of the FSF's concept of GPL-compatibility. A
license is compatible with the GPL if it provides at least GPL-equivalent
rights and therefore someone can take code under that license and license it
outbound under the GPL. Whether we think that making things GPL-compatible
is a good idea, the existence of the concept of GPL-compatible licenses
proves that Larry is incorrect.
Jeff
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 10:53:16 PM:
> On Wed, Dec 04, 2013 at 05:46:42PM -0500, Jeffrey Thompson wrote:
> > I'm not claiming that anyone other than the copyright owner has the
right to
> > alter the original grant. I'm stating that there is no rule that says
that a
> > licensee has to pass on all of the rights that it received from the
copyright
> > owner.
>
> That's correct, but the copyright owner has to give permission to the
> licensee to pass on fewer than all the rights.
Cite please.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Wed, Dec 04, 2013 at 05:46:42PM -0500, Jeffrey Thompson wrote:
> Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 02:32:53 PM:
>
> > You may not offer or impose any additional or different terms or
> > conditions on, or apply any Effective Technological Measures to, the
> > Licensed Material if doing so restricts exercise of the Licensed
> > Rights by any recipient of the Licensed Material.
> >
> > 'Licensed Material' means the original stuff put under CC BY.
>
> My point is that the Apache license does not contradict a commercial licensing
> model, whereas the CC-BY license does.
> If there is a CC-BY set of icons that you want to include in your commercial
> product, you cannot do so without changing your license. You may have the
> freedom to do that, for example, if you haven't licensed that product to anyone
> yet. But, you may not. Your customer may have licensed version 1.0 of the
> product under a pre-existing agreement that covers upgrades for a particular
> period of time. So, when you come out with version 2.0 containing the new and
> improved icons, your existing customer automatically receives the right to use
> that version under the pre-existing license, which does not contain CC-BY
> terms. So, you're out of luck. You cannot use CC-BY licensed icons in your
> product and simultaneously satisfy the CC-BY license and your prior agreements
> with your existing customers. That's why its inconsistent.
I don't understand the distinction you're drawing here:
> Apache only requires you to provide a copy of the Apache license to your
> customer, so when you build version 2.0, you include a Notices files with a
> copy of the Apache license describing the fact that the icons are available
> under this great open source license. If the customer cares enough about the
> icons, it knows where to get them under the Apache license. If it doesn't, it
> lives with the previously negotiated license. In neither case are you in
> violation of your obligations either to your customer or the open source
> project from which you obtained the icons.
How is that different from the case where the icons are CC BY? You
can't change the license of the icons themselves (assume they're
unchanged from upstream). In the CC BY case, the main thing you have
to do is provide a copy of CC BY (or a link to it), and comply with
some attribution requirement that will be not unlike the NOTICE
preservation requirement in the Apache License 2.0.
You're saying the copies of the icons in version 2.0 -- identical to
upstream -- have their license substituted from the Apache License 2.0
to the proprietary commercial license? So if you extracted those
icons, which presumably you can do, and say they're bit-for-bit
identical to the upstream version, you can't distribute them under the
terms of the Apache License 2.0?
The only difference I see here is that CC BY is quite explicit about
what is almost certainly the case for those other licenses that you
*can't* do this. I'll admit there is a small amount of doubt, but for
the Apache License 2.0 case this is, I think, an unintentional
ambiguity (worth clearing up if there's ever an Apache License 3.0).
> I'm not claiming that anyone other than the copyright owner has the right to
> alter the original grant. I'm stating that there is no rule that says that a
> licensee has to pass on all of the rights that it received from the copyright
> owner.
That's correct, but the copyright owner has to give permission to the
licensee to pass on fewer than all the rights. I see that CC BY does
not give that permission. I don't see where the Apache License 2.0
clearly states that it *does* give that permission.
> BTW, this is the entire basis of the FSF's concept of GPL-compatibility. A
> license is compatible with the GPL if it provides at least GPL-equivalent
> rights and therefore someone can take code under that license and license it
> outbound under the GPL.
I would have to study the history of versions of the GNU Licenses FAQ
to confirm this but I seem to recall that the FSF made a subtle
retreat from that viewpoint around 2008.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 02:32:53 PM:
> You may not offer or impose any additional or different terms or
> conditions on, or apply any Effective Technological Measures to, the
> Licensed Material if doing so restricts exercise of the Licensed
> Rights by any recipient of the Licensed Material.
>
> 'Licensed Material' means the original stuff put under CC BY.
My point is that the Apache license does not contradict a commercial
licensing model, whereas the CC-BY license does.
If there is a CC-BY set of icons that you want to include in your
commercial product, you cannot do so without changing your license. You
may have the freedom to do that, for example, if you haven't licensed that
product to anyone yet. But, you may not. Your customer may have licensed
version 1.0 of the product under a pre-existing agreement that covers
upgrades for a particular period of time. So, when you come out with
version 2.0 containing the new and improved icons, your existing customer
automatically receives the right to use that version under the pre-existing
license, which does not contain CC-BY terms. So, you're out of luck. You
cannot use CC-BY licensed icons in your product and simultaneously satisfy
the CC-BY license and your prior agreements with your existing customers.
That's why its inconsistent.
Apache only requires you to provide a copy of the Apache license to your
customer, so when you build version 2.0, you include a Notices files with a
copy of the Apache license describing the fact that the icons are available
under this great open source license. If the customer cares enough about
the icons, it knows where to get them under the Apache license. If it
doesn't, it lives with the previously negotiated license. In neither case
are you in violation of your obligations either to your customer or the
open source project from which you obtained the icons.
> I have to agree with Larry here, at least in the context of the
> specific licenses that have been mentioned in this thread. None of the
> BSD licenses gives you permission to alter the application of the BSD
> license to the original stuff that was under the BSD license
I'm not claiming that anyone other than the copyright owner has the right
to alter the original grant. I'm stating that there is no rule that says
that a licensee has to pass on all of the rights that it received from the
copyright owner. So, as long as the licensee's outbound license is a
subset of the rights obtained, unless there is a specific condition that
states that the outbound license MUST be the same (e.g., the GPL and, it
seems, CC-BY), the licensee is OK.
BTW, this is the entire basis of the FSF's concept of GPL-compatibility. A
license is compatible with the GPL if it provides at least GPL-equivalent
rights and therefore someone can take code under that license and license
it outbound under the GPL. Whether we think that making things
GPL-compatible is a good idea, the existence of the concept of
GPL-compatible licenses proves that Larry is incorrect.
Jeff
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
CC BY 4.0 (I assume we're now talking about 4.0) 2a5B says:
You may not offer or impose any additional or different terms or
conditions on, or apply any Effective Technological Measures to, the
Licensed Material if doing so restricts exercise of the Licensed
Rights by any recipient of the Licensed Material.
'Licensed Material' means the original stuff put under CC BY.
I have to agree with Larry here, at least in the context of the
specific licenses that have been mentioned in this thread. None of the
BSD licenses gives you permission to alter the application of the BSD
license to the original stuff that was under the BSD license (unless
you want to argue that this is granted implicitly). What's different
about the CC BY clause is the part about Effective Technological
Measures, which I think was Luis's point.
As for the Apache License 2.0, I think it could be made clearer, but
it says in 4d:
You ... may provide additional or different license terms and
conditions for use, reproduction, or distribution of Your
modifications, or for any such Derivative Works as a whole, provided
Your use, reproduction, and distribution of the Work otherwise
complies with the conditions stated in this License.
I think the fact that it speaks of 'such Derivative Works as a whole'
is relevant - original Apache License 2.0 code remains under Apache
License 2.0.
In other words all these licenses affirm that the original license
gets carried forward. That *can't* be a problem under Apache policy
because of a reductio ad absurdum - it would mean that the Apache
License 2.0 itself violates Apache licensing policy.
- RF
On Wed, Dec 04, 2013 at 10:49:02AM -0800, Lawrence Rosen wrote:
> Jeff Thompson wrote:
> > At least from a potential commercial user's perspective,
>
> > Section 2.a.5.B effectively requires carrying forward
>
> > the CC license terms verbatim in the user's license to
>
> > its customer.
>
> > Isn't that a problem from an Apache licensing policy
>
> > perspective?
>
>
>
> No. The Apache License 2.0 license is /also/ carried forward verbatim in the
> commercial licensor's license to its customer. As are the licenses of /each of
> the components/ in that Apache work.
>
>
>
> You can't undo a copyright owner's license by slapping your own proprietary
> license on top of it.
>
>
>
> /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: Wednesday, December 04, 2013 7:03 AM
> To: legal-discuss@apache.org
> Cc: Lawrence Rosen; luis.villa@gmail.com
> Subject: Re: New versions of CC licenses
>
>
>
> Luis,
>
> luis.villa@gmail.com wrote on 12/04/2013 01:56:04 AM:
>
> > As I believe I've noted here before, CC (4.0 and earlier) has an
> > anti-DRM provision that makes it a poor fit for the embedded/mobile
> > space
> . . .
> > there is nothing else in 4.0 that would be
> > problematic.
> >
> > Luis
> >
> I'm not sure I agree with that summary. The anti-DRM provision is more than
> just a "no-technological measures" requirement. At least from a potential
> commercial user's perspective, Section 2.a.5.B effectively requires carrying
> forward the CC license terms verbatim in the user's license to its customer.
> Isn't that a problem from an Apache licensing policy perspective?
>
> The gist of Apache's policy has been that as long as you're passing on the
> notices and otherwise complying with the license, its not a problem if the
> user's commercial terms with their customers are different from the Apache
> license (for example, most commercial licenses prohibit modification, or at
> least void warranties and support, etc if the code is modified). Wouldn't
> anything that changes that basic understanding be problematic (e.g., you MUST
> grant all of the rights that you received)?
>
> Jeff
>
> Counsel, IBM Corporation
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 5 December 2013 14:33, Stephen Connolly
<st...@gmail.com>wrote:
>
>
>
> On 5 December 2013 13:55, Jeffrey Thompson <jt...@us.ibm.com> wrote:
>
>> "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 07:52:07 PM:
>> > Jeffrey Thompson wrote:
>>
>> > > We've had this discussion before. The Apache license does not say
>> > > that it must become a part of the license under which the Apache
>> > > user licenses the resulting product to its customer. It merely
>> > states that
>> > > a copy of the Apache license needs to be provided. This was part of
>> the
>> > > design.
>>
>> > Which design are you referring to? I'm reading the OSD....
>> >
>> > The Apache License applies to all works distributed by ASF. A
>> > contributor's license applies to her contributions included in that
>> > Apache work. There is nothing that a downstream licensor can do to
>> > change that short of requesting new licenses from the licensors.
>>
>> Right. If you don't want to receive the code under the Apache license,
>> you need to talk to the copyright owners and get a separate license. I'm
>> not sure what that has to do with our conversation, though.
>>
>>
>> >
>> > > There is no general copyright principle that says that a licensee has
>> > > to pass on all rights that it received from its licensor. If you
>> > can provide
>> > > a cite to one, please do.
>> >
>> > How does IBM avoid passing on those rights?
>>
>> I didn't say that one could distribute the code without passing on ANY
>> rights. I said one is allowed to distribute the code without passing on
>> ALL OF the rights.
>>
>>
>> > The second sentence of
>> > 17 USC 103(b) says: "The copyright in [compilations and derivative
>> > works] is independent of, and does not affect or enlarge the scope,
>> > duration, ownership, or subsistence of, any copyright protection in
>> > the preexisting material [e.g., contributions]."
>>
>> I'm saying that, broadly speaking, there are 2 types of OSS licenses --
>> ones which don't necessarily require you to change your pre-existing
>> licenses and ones that do. Apache, MIT, BSD, EPL (for executables, not
>> source), etc. are in the former camp. GPL, CC-BY, etc. are in the latter.
>>
>> Is your point that because the copyright in the derivative work is
>> separate, you are free to ignore those provisions of the GPL and CC-BY and
>> distribute your derivative work under your own license terms (e.g., without
>> stating that certain components are licensed to you under the GPL)?
>>
>> If that's not your point, I can't understand why you're quoting this
>> statute.
>>
>>
>> >
>> > There is also an Apache License provision that says almost the same
>> > thing. Richard Fontana quoted section 4d:
>> >
>> > You ... may provide additional or different license terms and
>> > conditions for use, reproduction, or distribution of Your
>> > modifications, or for any such Derivative Works as a whole, provided
>> > Your use, reproduction, and distribution of the Work otherwise
>> > complies with the conditions stated in this License.
>>
>> You may provide your derivative works (to your customers) under your own
>> terms. Great, that's what I'm saying.
>>
>> ... provided you comply with the conditions in the license. Fine.
>> What's the condition that the distribution would not be complying with by
>> using its own terms?
>>
>> There are no conditions in section 1.
>> There are no conditions in section 2.
>> Last sentence of section 3 could be interpreted as a condition, but its
>> really just a limitation on the patent grant n the prior sentence. In any
>> event, it would not be a condition that turns on the user's outbound
>> license.
>>
>> Section 4 -- has conditions.
>> 4.1. Give a copy of the Apache license -- check. No obligation to
>> change the pre-existing license agreement.
>> 4.2. Mark modifications -- check
>> 4.3. Retain notices in the source -- check
>> 4.4 Retain Notices file -- check
>>
>> Section 5, contributions -- not relevant here
>> Section 6, trademarks -- not relevant here
>> Section 7, warranty -- not relevant here
>> Section 8, liability -- not relevant here
>> Section 9, adding warranty terms -- not a condition, but an explicit
>> permission -- and doesn't relate to the outbound licensing terms.
>>
>> I'm out of license. I don't see any condition that requires a
>> distributor to modify its outbound license.
>>
>> > This is not a big burden for Apache licensees, because the
>> > conditions we impose are minimal. See section 4 of the license.
>> > Almost anyone can satisfy those conditions trivially. The same easy
>> > implementation can be said for the BSD and CC-BY licenses.
>>
>> CC-BY says "You may not offer or impose ... different terms ... to the
>> Licensed Material if doing so restricts exercise of the Licensed Rights."
>>
>> That sentence explicitly places a requirement on the outbound license
>> which will likely not be satisfied by most commercial licenses since most
>> commercial licenses prohibit modification and redistribution. There is NO
>> equivalent provision in BSD or Apache.
>>
>>
>> > The conditions you impose on your customers are your own
>> > business, and you are free to wrap our Apache software, along with
>> > your own software, under any license you choose.
>>
>> If "wrapping" means applying terms to the original parts of the combined
>> work, while passing thru the Apache license for the Apache works, it is
>> certainly possible to craft a license that does that. In effect, it would
>> say "Here, Mr. Customer, is a license that covers 90% of the work and this
>> Apache license covers this part over here." But, that's not commercially
>> reasonable for long term software agreements that cover multiple products
>> and multiple versions of products. You don't know that Apache/BSD/CC-BY
>> components are going to be in the products yet since some of them may not
>> have been developed.
>>
>> Customers react poorly to the concept that the supplier can change its
>> software license after the agreement is signed merely because the supplier
>> decided to include an OSS component. So, while logically it works that the
>> supplier could have a license that says that certain terms apply "unless I
>> say otherwise", its not going to be generally acceptable to customers.
>>
>>
>> > Again, I don't know why you and Luis are complaining about CC-BY.
>> > The GPLv3's DRM conditions are far more strict than those of CC-BY.
>> > Nothing in CC-BY requires the disclosure of "complete corresponding
>> > source code" nor even the "source code" at all.
>>
>> I haven't addressed the DRM conditions.
>>
>
> Isn't the mistake you are making in assuming that only one copy of the
> CC-BY licensed stuff is included?
>
> If I were shipping a binary with DRM to prevent modification of my code, I
> would presume (in my IANAL capacity) that the easy way out is to bundle a
> non-DRM copy of the CC-BY licensed stuff in addition to the DRM protected
> stuff.
>
> Thus the receiving user receives the material and all original rights, and
> my custom code can have whatever license it needs.
>
> The end user is free to modify a copy of the icons or whatever that they
> have received, but not free to modify the compiled binary that bundles them.
>
> What kind of DRM could I put on a binary that I am producing...
>
> At its simplest I could just be distributing a .jar file (which is just a
> fancy .zip file after all)
>
> The JAR spec allows for signing of its contents... So I could sign the
> contents with my own certificate... at this point you cannot modify the JAR
> file's contents without either turning off signature verification or
> signing everything with your own certificate.
>
> I could have the primary entry point of my code check what certificate was
> used to sign the code base and bomb out if it is not my signature.
>
> None of the above prevents the end recipient from extracting the CC-BY
> licensed content and exercising their rights *on the CC-BY licensed
> content*. You do not have rights to modify the collective work unless I
> grant them to you. So your rights on the collective work can be less than
> your rights on the individual components provided that I provided I provide
> a means for you to exercise your rights on those individual components *as*
> individual components.
>
> Where I see a difference is that you seem to be implying that the CC-BY
> rights *on the CC-BY licensed content* mean that you are allowed to modify
> the CC-BY content *within the collective work*.
>
> Let's take the icons example...
>
> I see some lovely icons and they are CC-BY licensed.
>
> I need to modify one of the icons to fit my look and feel.
>
> I bundle the whole into an windows.exe with DRM up the wazoo.
>
> My installer (which is what I distribute) will put on your system the .exe
> and a .zip with the icons (both the ones I use unmodified and the ones I
> modified) and the CC-BY attribution, etc. Also the .exe's About window
> gives an URL to the attribution requirements.
>
> Tell me now how your rights under CC-BY are restricted by my DRM on my
> collective work?
>
If the above holds water, the next simplified version of the above is that
the About window's URL includes a download link for the CC-BY icons...
Which really resolves to including a download link in the NOTICE file if
you are an Apache project including CC-BY content
Of course I am not a lawyer... so my mathematical inspired logic may move
too fast or make assumptions which lawyers forbid!
>
> -Stephen
>
>
>>
>>
>> Jeff
>> Counsel, IBM Software Group
>>
>>
>>
>
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Roy Fielding wrote:
> Regardless, the Apache License explicitly allows sublicensing.
> The BSD licenses implicitly permit it as well. The CC-BY license
> explicitly forbids sublicensing. I don't know why, but it is hard
> to argue that it wasn't intentional.
There is no such legal doctrine as an "implicit" license to sublicense. I
know that lots of people believe in it, but that doesn't make it happen.
Sublicensing isn't required for public FOSS projects, since the license is
direct from the licensor to each person on earth. The legal advantage of
this is that there are no issues of privity of contract to argue about.
/Larry
-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Saturday, December 07, 2013 1:18 PM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
On Dec 7, 2013, at 9:25 AM, Richard Fontana wrote:
>
> This would then imply that the 4-clause BSD (with the advertising
> clause) should not be in Category A, since it is widely held (by most
> of those who claim to care about the issue) that the advertising
> clause is incompatible with the GPL. I have even heard of downstream
> commercial entities that have voiced concerns over the use of
> advertising clauses. But both Roy Fielding and JimJag have said that
> all versions of the BSD license, including those with the advertising
> clause, are supposed to be in Category A. I have no view on whether
> that is correct or not, just pointing out what seems like an
> inconsistency to me.
I think that is because you read the terms literally, whereas we read them
with experience of historical (and demonstrated) intent and precedence.
In every case we have considered and discussed with the copyright owners,
their advertising clause has been satisfied by the NOTICE file.
That is, in fact, why we created the NOTICE file. Apache httpd was
originally under the 4-clause BSD.
It is important to understand that the exact wording of the BSD license can
be interpreted with respect to the intent of the original drafters of that
license and the intent of the open source developers that chose it. In all
cases we have seen, that intent is to ensure that their creative work is
correctly attributed where such attributions are customary. The fact that
the wording suggests a much broader attribution is an accident of history.
That accident is commonly understood by open source projects and admitted by
UCB.
So, what we do is distribute such software under the Apache License with the
required advertising in NOTICE, based on what we know of the BSD license
intent. If any such copyright owner chooses to object to that
redistribution, we will address their objections at that time. We do not
expect anyone to do so.
Regardless, the Apache License explicitly allows sublicensing.
The BSD licenses implicitly permit it as well. The CC-BY license explicitly
forbids sublicensing. I don't know why, but it is hard to argue that it
wasn't intentional.
....Roy
---------------------------------------------------------------------
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
Re: New versions of CC licenses
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 7, 2013, at 9:25 AM, Richard Fontana wrote:
>
> This would then imply that the 4-clause BSD (with the advertising
> clause) should not be in Category A, since it is widely held (by most
> of those who claim to care about the issue) that the advertising
> clause is incompatible with the GPL. I have even heard of downstream
> commercial entities that have voiced concerns over the use of
> advertising clauses. But both Roy Fielding and JimJag have said that
> all versions of the BSD license, including those with the advertising
> clause, are supposed to be in Category A. I have no view on whether
> that is correct or not, just pointing out what seems like an
> inconsistency to me.
I think that is because you read the terms literally, whereas we
read them with experience of historical (and demonstrated) intent
and precedence.
In every case we have considered and discussed with the copyright
owners, their advertising clause has been satisfied by the NOTICE file.
That is, in fact, why we created the NOTICE file. Apache httpd
was originally under the 4-clause BSD.
It is important to understand that the exact wording of the BSD
license can be interpreted with respect to the intent of the original
drafters of that license and the intent of the open source developers
that chose it. In all cases we have seen, that intent is to ensure
that their creative work is correctly attributed where such
attributions are customary. The fact that the wording suggests a
much broader attribution is an accident of history. That accident
is commonly understood by open source projects and admitted by UCB.
So, what we do is distribute such software under the Apache License
with the required advertising in NOTICE, based on what we know of
the BSD license intent. If any such copyright owner chooses to
object to that redistribution, we will address their objections
at that time. We do not expect anyone to do so.
Regardless, the Apache License explicitly allows sublicensing.
The BSD licenses implicitly permit it as well. The CC-BY license
explicitly forbids sublicensing. I don't know why, but it is hard
to argue that it wasn't intentional.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Sat, Dec 07, 2013 at 05:24:23AM -0500, Sam Ruby wrote:
> To facilitate the creation of such derivative works, the ASF makes an attempt
> to avoid including works that are provided under licenses that are more
> restrictive than the ASF's own license.
>
> CC-By appears to be such a license. Whether or not you agree with Jeff, it is
> the case that both the Mozilla foundation and the FSF have deemed that CC-BY is
> incompatible with their licenses.
This would then imply that the 4-clause BSD (with the advertising
clause) should not be in Category A, since it is widely held (by most
of those who claim to care about the issue) that the advertising
clause is incompatible with the GPL. I have even heard of downstream
commercial entities that have voiced concerns over the use of
advertising clauses. But both Roy Fielding and JimJag have said that
all versions of the BSD license, including those with the advertising
clause, are supposed to be in Category A. I have no view on whether
that is correct or not, just pointing out what seems like an
inconsistency to me.
A point that I think Larry may have been making (unless I
misunderstood it) was that it makes sense to look at things by
specific situation. Especially so for something like CC BY, since it
will most often appear to cover discrete, easily removable or
separable or substitutable things (as in Jeff's hypothetical about CC
BY icons).
For all I know the FSF would say that a CC BY icon in an otherwise
GPL-licensed work is an example of 'mere aggregation', meaning that
the incompatibility of CC BY with the GPL (if in fact the FSF holds
that view) does not arise in that common context. In the case of MPL
2.0, it's difficult for me to see how a CC BY icon could be
incompatible with MPL 2.0 software, since that would seem to be an
example of a permitted 'Larger Work'.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Sat, Dec 07, 2013 at 01:50:44PM -0800, Lawrence Rosen wrote:
> Jeff Thompson wrote:
>
> > I am saying, as between B and C, if they've agreed to exchange the code under
> the GPL, as between those two, that's the license.
>
> I agree with that. So also if Red Hat takes software from the Linux Foundation
> under the GPL and agrees with its customers to make that available under a
> commercial license, then as between them the commercial license is the deal.
> Perhaps Richard and other Linux vendor attorneys who are on this list can tell
> us: Does anybody believe that this private deal between Red Hat and its
> customers erases the effect of the GPL on that Linux software?
Certainly, the private deal does not erase the effect of the GPL on
Linux software (the derivative work that is based on code ultimately
taken from kernel.org).
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
If not, I have some contacts at Creative Commons I could refer you to.
- RF
----- Original Message -----
> Is there anyone on this list from CC or who can speak
> authoritatively on their behalf?
>
> I, for one, would appreciate at least *some* insight
> from their/your point of view... If we rec' none, then
> we are left to try to determine it, which is good for
> no one.
>
> On Dec 9, 2013, at 12:28 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> >
> > On Dec 9, 2013, at 9:34 AM, Stephen Connolly
> > <st...@gmail.com> wrote:
> >>
> >> If that is the case it would seem that this thread is mostly a storm in a
> >> teacup... but I agree that it would be good if somebody (i.e. you) could
> >> engage with the CC-BY authors to confirm that this was their intent.
> >>
> >
> > To me this seems the logical next step: we can continue
> > to go around and around and debate the letter, but all
> > that is, imo at least, secondary to the what their intent
> > was and is. I consider this almost a parallel to how we
> > understand and honor the 4-clause BSD...
> >
> > So who will take this action on??
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 9 December 2013 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
> On Mon, Dec 9, 2013 at 9:34 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>>
>>
>> It seems to me that the structure of phrasing and document structure
>> makes it crystal clear that 2.a.5.A and 2.a.5.B are referring to one and
>> the same thing, namely the implicit offer from the original Licensor of
>> Licensed Rights to any downstream recipient irrespective of any 3rd party
>> license agreements that were involved in the downstream recipient becoming
>> a downstream recipient.
>>
>
> How does this work if the content in question is modified by either the
> ASF or by the licensee?
>
>From reading it, I see there is
> 3.a.4 If You Share Adapted Material You produce, the Adapter's License
You apply must not prevent recipients of the Adapted Material from
complying with this Public License.
So from that and
> 1.b *Adapter's License* means the license You apply to Your Copyright and
Similar Rights in Your contributions to Adapted Material in accordance with
the terms and conditions of this Public License.
if we are modifying and distributing *the modifications* under AL2.0, as
long as we comply with CC-BY 4.0 (i.e. NOTICE) and as long as we do not
prevent others from receiving their license grant to the original
unmodified Licensed Material then it would seem to me from my pedantic
mathematical logical interpretation that it could well be Cat A.... but I
know nothing of the imperfect ways of the law... esp when said law is based
on at least 3 different traditions and need interpretation with respect to
many countries to be fully of use...
> Quoting from Category B[1] "...and for which that source is unmodified and
> unlikely to be changed anyway..."
>
> - Sam Ruby
>
> [1] http://www.apache.org/legal/resolved.html#category-b
>
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Dec 9, 2013 at 9:34 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
>
> It seems to me that the structure of phrasing and document structure makes
> it crystal clear that 2.a.5.A and 2.a.5.B are referring to one and the same
> thing, namely the implicit offer from the original Licensor of Licensed
> Rights to any downstream recipient irrespective of any 3rd party license
> agreements that were involved in the downstream recipient becoming a
> downstream recipient.
>
How does this work if the content in question is modified by either the ASF
or by the licensee?
Quoting from Category B[1] "...and for which that source is unmodified and
unlikely to be changed anyway..."
- Sam Ruby
[1] http://www.apache.org/legal/resolved.html#category-b
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
Is there anyone on this list from CC or who can speak
authoritatively on their behalf?
I, for one, would appreciate at least *some* insight
from their/your point of view... If we rec' none, then
we are left to try to determine it, which is good for
no one.
On Dec 9, 2013, at 12:28 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> On Dec 9, 2013, at 9:34 AM, Stephen Connolly <st...@gmail.com> wrote:
>>
>> If that is the case it would seem that this thread is mostly a storm in a teacup... but I agree that it would be good if somebody (i.e. you) could engage with the CC-BY authors to confirm that this was their intent.
>>
>
> To me this seems the logical next step: we can continue
> to go around and around and debate the letter, but all
> that is, imo at least, secondary to the what their intent
> was and is. I consider this almost a parallel to how we
> understand and honor the 4-clause BSD...
>
> So who will take this action on??
>
>
> ---------------------------------------------------------------------
> 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
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2013, at 9:34 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> If that is the case it would seem that this thread is mostly a storm in a teacup... but I agree that it would be good if somebody (i.e. you) could engage with the CC-BY authors to confirm that this was their intent.
>
To me this seems the logical next step: we can continue
to go around and around and debate the letter, but all
that is, imo at least, secondary to the what their intent
was and is. I consider this almost a parallel to how we
understand and honor the 4-clause BSD...
So who will take this action on??
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 9 December 2013 14:23, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> Stephen Connolly <st...@gmail.com> wrote on 12/09/2013
> 08:58:47 AM:
>
>
> >> The single point that this
> >> whole discussion started on was the difference between AL2.0 and CC-
> >> BY. Under AL2.0, B can add a restriction to its license. Under CC-
> >> BY, B can't. In both cases rights are available directly from A,
> >> and B's actions don't negate those separate rights.
>
> >
> > Maybe I am mis-reading CC-BY 4.0
> >
> > 2.a.5 Downstream recipients.
>
> > B. No downstream restrictions. You may not offer or impose any
> > additional or different terms or conditions on, or apply any
> > Effective Technological Measures to, the Licensed Material if doing
> > so restricts exercise of the Licensed Rights by any recipient of the
> > Licensed Material.
>
> >
> > So my reading is that under CC-BY 4.0 C receives an implicit offer
> > from A to the content included by B and B is not allowed to restrict
> > C's ability to take up that offer.
>
> If the language of 2.a.5.B was limited to the actual effect of B's
> separate terms (as in, "any terms offered by you do not actually restrict
> the recipient's rights to exercise these License Rights") then my question
> wouldn't apply. But, it says "you may not offer ... different terms ...".
>
>
Well you are now playing "partial quoting" which is a dangerous game... it
is "exercise of the Licensed Rights" that these "different terms" may not
restrict. Since which would seem only exist by virtue of 2.a.5.A which even
uses the term "exercise the Licensed Rights"...
It seems to me that the structure of phrasing and document structure makes
it crystal clear that 2.a.5.A and 2.a.5.B are referring to one and the same
thing, namely the implicit offer from the original Licensor of Licensed
Rights to any downstream recipient irrespective of any 3rd party license
agreements that were involved in the downstream recipient becoming a
downstream recipient.
If that is the case it would seem that this thread is mostly a storm in a
teacup... but I agree that it would be good if somebody (i.e. you) could
engage with the CC-BY authors to confirm that this was their intent.
-Stephen
> Maybe a commercial distributor could get comfortable that the additional
> terms don't actually restrict modification of the CC-BY material
> notwithstanding the fact that the additional terms purport to do so
> (possibly true, because of the grant by the original author to any
> recipient), but if the commercial distributor didn't want to take that
> risk, it'd need to modify its license terms.
>
> Alternatively, the CC-BY authors could clarify this issue and add a
> comment somewhere that this language doesn't actually prohibit someone from
> including these additional terms in their license, it just points out that
> the terms won't be effective because of the structure of the CC-BY grants.
> That would be helpful.
>
>
> Jeff
> Counsel, IBM Software Group
>
>
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Stephen Connolly <st...@gmail.com> wrote on 12/09/2013
08:58:47 AM:
>> The single point that this
>> whole discussion started on was the difference between AL2.0 and CC-
>> BY. Under AL2.0, B can add a restriction to its license. Under CC-
>> BY, B can't. In both cases rights are available directly from A,
>> and B's actions don't negate those separate rights.
>
> Maybe I am mis-reading CC-BY 4.0
>
> 2.a.5 Downstream recipients.
> B. No downstream restrictions. You may not offer or impose any
> additional or different terms or conditions on, or apply any
> Effective Technological Measures to, the Licensed Material if doing
> so restricts exercise of the Licensed Rights by any recipient of the
> Licensed Material.
>
> So my reading is that under CC-BY 4.0 C receives an implicit offer
> from A to the content included by B and B is not allowed to restrict
> C's ability to take up that offer.
If the language of 2.a.5.B was limited to the actual effect of B's separate
terms (as in, "any terms offered by you do not actually restrict the
recipient's rights to exercise these License Rights") then my question
wouldn't apply. But, it says "you may not offer ... different terms ...".
Maybe a commercial distributor could get comfortable that the additional
terms don't actually restrict modification of the CC-BY material
notwithstanding the fact that the additional terms purport to do so
(possibly true, because of the grant by the original author to any
recipient), but if the commercial distributor didn't want to take that
risk, it'd need to modify its license terms.
Alternatively, the CC-BY authors could clarify this issue and add a comment
somewhere that this language doesn't actually prohibit someone from
including these additional terms in their license, it just points out that
the terms won't be effective because of the structure of the CC-BY grants.
That would be helpful.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 9 December 2013 03:04, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> Engel Nyst <en...@gmail.com> wrote on 12/08/2013 09:21:13 PM:
>
>
> > On 12/07/2013 09:32 PM, Jeffrey Thompson wrote:
> > > Think if it this way, if A licensed B the code under AL2.0 as a private
> > > deal and not one that A has ever made available to anyone else. Does
> it
> > > change your mind on whether C should be able to exercise AL2.0 rights
> to
> > > that code after it receives them from B under the GPL? I would say the
> > > answer to that questions HAS TO BE yes, it does affect the answer. C
> > > doesn't have an offer from A under AL2.0, so C's only avenue of rights
> is
> > > from B and B's grant is under the GPL, so that's what C is stuck with.
> > >
> >
> > It is not clear to me what means "A licensed B the code under AL2.0 as a
> > private deal".
>
> Specifically, I meant that A offered the code to B under AL2.0, but didn't
> make the same offer to anyone else. The offer was solely to B.
>
>
> >
> > Does it mean "A made an agreement with B that they give *B* and only B,
> > /by the text of the agreement/, a license that looks like AL2.0"?
>
> I didn't mean to imply that there was any agreement between A and B that A
> wouldn't offer the code under the AL2.0 to anyone else -- that is, I wasn't
> referring to an exclusive license or anything like that -- just that A
> wasn't making the code generally available. As an example, if two parties
> got together to do some joint work on a project, they could offer each
> other any contributions to the joint code under AL2.0. That doesn't mean
> that each author is obligated to offer their code to anyone else under
> AL2.0, but it doesn't mean that they're prohibited either.
>
> Also, note that I didn't say that B is prohibited from continuing the
> chain of AL2.0 grants and B can certainly make the code available broadly
> under AL2.0, in which case, A's grants would be available to folks through
> B's action. I was trying to distinguish the situation where A's offer is
> to the public generally from the situation where A's offer of the code was
> only made to B.
>
> I hope that that's slightly clearer than mud.
>
>
> > A is the only copyright holder of the /original work/. As far as C is
> > concerned, B can combine the license of A with their own terms (AL2.0
> > allows it) and the practical effect on C can very well be restrictive.
>
> OK, B can apply a license to the combined work that, for example,
> prohibits redistribution.
>
>
> > But as *licensing rights* are concerned, as also explained in this
> > thread, AL2.0 makes clear that no matter what terms are added, they
> > should not be construed as modifying AL2.0 for the original work.
>
> If what you mean is that the license offer from A still exists and C can
> take advantage of it, then I agree. The single point that this whole
> discussion started on was the difference between AL2.0 and CC-BY. Under
> AL2.0, B can add a restriction to its license. Under CC-BY, B can't. In
> both cases rights are available directly from A, and B's actions don't
> negate those separate rights.
>
Maybe I am mis-reading CC-BY 4.0
2.a.5 Downstream recipients.
> A. Offer from the Licensor – Licensed Material. Every recipient of the
> Licensed Material automatically receives an offer from the Licensor to
> exercise the Licensed Rights under the terms and conditions of this Public
> License.
> B. No downstream restrictions. You may not offer or impose any additional
> or different terms or conditions on, or apply any Effective Technological
> Measures to, the Licensed Material if doing so restricts exercise of the
> Licensed Rights by any recipient of the Licensed Material.
>
So my reading is that under CC-BY 4.0 C receives an implicit offer from A
to the content included by B and B is not allowed to restrict C's ability
to take up that offer.
In other words, to return to the IBM and the icons...
IBM has a license with Acme for the XYZ product that bundles some icons
that are CC-BY released by FooBar Inc.
IBM can have a nice restrictive set of terms... but IBM is not allowed to
limit Acme's ability to take up FooBar's CC-BY license that is implicitly
offered to them under CC-BY as a downstream recipient...
In other words, unless IBM's contract specifically ban's Acme from
receiving content from FooBar or from entering into an agreement with
FooBar.
I think, from my reading, that the difference here with the AL2.0 is that
CC-BY4.0 includes an implicit *offer* of a license from the original
copyright holder.
So to take the case where A offers content to B only under AL2.0, and then
B offers combined content to C under propriatary license... that cannot
happen with CC-BY4.0
With CC-BY 4.0 when A offers the content to B under CC-BY4.0 they are also
extending an implicit offer to any downstream recipients, C, D, E, etc...
but those are direct relationships from A to C, D, E, etc. The 2.a.5.B term
is stating that B may not prevent C, D, E, etc from exercising their rights
to the implicit offer in 2.a.5.A and establishing a direct license from A
for the licensed content.
-Stephen
>
>
> > I am somehow amazed by your insistence to erase them completely. I do
> > not think your understanding is correct.
>
> I'm not trying to erase them completely, merely focusing on one very
> practical point that affects commercial licensors -- whether B would have
> to modify its existing commercial licenses when incorporating A's OSS
> software. With AL2.0, I don't believe they need to do so, though they
> certainly need to include notices, a copy of the AL2.0, etc. With CC-BY,
> they might have to, since CC-BY4 explicitly says that you can't include any
> terms that attempt to restrict the CC-BY rights.
>
> Again, rights that are available directly from A to C pursuant to A's OSS
> license of choice is a different issue, at least for the original point of
> this discussion.
>
>
> > I think your perspective is heavily biased by a permanent assumption
> > that only sole/exclusive licenses can exist, so you try to reduce an
> > open license to a set of those [sort of]. I don't think that in (most)
> > open licensing world, such understanding exists, nor practice.
>
> I don't believe I have that assumption.
>
> Jeff
> Counsel, IBM Software Group
>
>
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Engel Nyst <en...@gmail.com> wrote on 12/08/2013 09:21:13 PM:
> On 12/07/2013 09:32 PM, Jeffrey Thompson wrote:
> > Think if it this way, if A licensed B the code under AL2.0 as a private
> > deal and not one that A has ever made available to anyone else. Does
it
> > change your mind on whether C should be able to exercise AL2.0 rights
to
> > that code after it receives them from B under the GPL? I would say the
> > answer to that questions HAS TO BE yes, it does affect the answer. C
> > doesn't have an offer from A under AL2.0, so C's only avenue of rights
is
> > from B and B's grant is under the GPL, so that's what C is stuck with.
> >
>
> It is not clear to me what means "A licensed B the code under AL2.0 as a
> private deal".
Specifically, I meant that A offered the code to B under AL2.0, but didn't
make the same offer to anyone else. The offer was solely to B.
>
> Does it mean "A made an agreement with B that they give *B* and only B,
> /by the text of the agreement/, a license that looks like AL2.0"?
I didn't mean to imply that there was any agreement between A and B that A
wouldn't offer the code under the AL2.0 to anyone else -- that is, I wasn't
referring to an exclusive license or anything like that -- just that A
wasn't making the code generally available. As an example, if two parties
got together to do some joint work on a project, they could offer each
other any contributions to the joint code under AL2.0. That doesn't mean
that each author is obligated to offer their code to anyone else under
AL2.0, but it doesn't mean that they're prohibited either.
Also, note that I didn't say that B is prohibited from continuing the chain
of AL2.0 grants and B can certainly make the code available broadly under
AL2.0, in which case, A's grants would be available to folks through B's
action. I was trying to distinguish the situation where A's offer is to
the public generally from the situation where A's offer of the code was
only made to B.
I hope that that's slightly clearer than mud.
> A is the only copyright holder of the /original work/. As far as C is
> concerned, B can combine the license of A with their own terms (AL2.0
> allows it) and the practical effect on C can very well be restrictive.
OK, B can apply a license to the combined work that, for example, prohibits
redistribution.
> But as *licensing rights* are concerned, as also explained in this
> thread, AL2.0 makes clear that no matter what terms are added, they
> should not be construed as modifying AL2.0 for the original work.
If what you mean is that the license offer from A still exists and C can
take advantage of it, then I agree. The single point that this whole
discussion started on was the difference between AL2.0 and CC-BY. Under
AL2.0, B can add a restriction to its license. Under CC-BY, B can't. In
both cases rights are available directly from A, and B's actions don't
negate those separate rights.
> I am somehow amazed by your insistence to erase them completely. I do
> not think your understanding is correct.
I'm not trying to erase them completely, merely focusing on one very
practical point that affects commercial licensors -- whether B would have
to modify its existing commercial licenses when incorporating A's OSS
software. With AL2.0, I don't believe they need to do so, though they
certainly need to include notices, a copy of the AL2.0, etc. With CC-BY,
they might have to, since CC-BY4 explicitly says that you can't include any
terms that attempt to restrict the CC-BY rights.
Again, rights that are available directly from A to C pursuant to A's OSS
license of choice is a different issue, at least for the original point of
this discussion.
> I think your perspective is heavily biased by a permanent assumption
> that only sole/exclusive licenses can exist, so you try to reduce an
> open license to a set of those [sort of]. I don't think that in (most)
> open licensing world, such understanding exists, nor practice.
I don't believe I have that assumption.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Engel Nyst <en...@gmail.com>.
On 12/07/2013 09:32 PM, Jeffrey Thompson wrote:
> Think if it this way, if A licensed B the code under AL2.0 as a private
> deal and not one that A has ever made available to anyone else. Does it
> change your mind on whether C should be able to exercise AL2.0 rights to
> that code after it receives them from B under the GPL? I would say the
> answer to that questions HAS TO BE yes, it does affect the answer. C
> doesn't have an offer from A under AL2.0, so C's only avenue of rights is
> from B and B's grant is under the GPL, so that's what C is stuck with.
>
It is not clear to me what means "A licensed B the code under AL2.0 as a
private deal".
Does it mean "A made an agreement with B that they give *B* and only B,
/by the text of the agreement/, a license that looks like AL2.0"?
That would not be AL2.0. It's easy to use the concept (and I see this in
certain communities) "[permissive-license-here] to B", in particular I
see "BSD to B". People seem to understand the term, by comparison with
the license text I assume, with a restriction added. But to me (I never
use the term), that's not AL2.0, if it's granted only to B, *by the
license text*.
I believe the term obscures a significant difference: a license "AL2.0
text, but amended to apply only to B, excluding C and everyone else" in
the /license text/ is a proprietary license. Clearly proprietary. It has
only stylistic similitude with AL2.0, conceptually it's very different
than AL2.0.
All open licenses are granted by the copyright holder to everyone. Not
to B, excluding everyone else. Not /by the license/.
It doesn't matter in practice, most of the time, because B acts as
recipient; if D is not a recipient, nothing happens. But when C becomes
a recipient in some form, I don't understand *from where* can B take the
right to completely override [thus, change] the license A gave to C for
the /original work/ inside.
If B goes to C and tells them "I have from A a license to me and only
me, excluding you. Now, I'm giving you these rights on everything inside
this package: [proprietary agreement follows]", then I believe B is
incorrect. A is the only source of *licensing rights* for the original
work, and A has granted AL2.0 to everyone, not only to B. Not /by the
license/.
A is the only copyright holder of the /original work/. As far as C is
concerned, B can combine the license of A with their own terms (AL2.0
allows it) and the practical effect on C can very well be restrictive.
But as *licensing rights* are concerned, as also explained in this
thread, AL2.0 makes clear that no matter what terms are added, they
should not be construed as modifying AL2.0 for the original work.
Switching an open license to a proprietary license between A and B seems
to me a significant modification *of A's license*.
I don't see how can B can claim they can do that. Not saying A's license
cannot be considered sort of this way, for many practical purposes, but
you're talking about licensing rights.
It seems to me your theory is that an open license would be entirely
equivalent with "AL2.0 but only to B, or AL2.0 but only to C, or AL2.0
to D[...]". That is, a dual-, tri-, [no of downloads from
upstream]-license. A dual-, tri-, n- proprietary license. I do not
believe your understanding is correct.
In my reading, C doesn't have to go get more rights from somewhere else
(i.e. upstream) in order to have AL2.0. When they receive the /original
work/, they have AL2.0 on it, with or without some additional terms [if
B sets them] to obey to, or practical problems, which might of course
restrict their exercise of AL2.0 rights.
Please note that I have no relation with Apache. I'm a BSD licensor,
among others, which is the same situation here (in my reading). Feel
free to ignore this message for the purpose of this discussion, I just
find it very interesting.
I do not think BSD license /from the copyright holder/ is a simple sum
of sorts of proprietary agreements, and I am surprised by your
insistence to erase it completely. I don't see why you need to.
It already allows you to restrict C, with additional terms between B and
C, and/or withholding source, and/or making modifications under your
license and introducing practical issues for C.
BSD, AL2.0, CC-BY already allow you almost anything.
I am somehow amazed by your insistence to erase them completely. I do
not think your understanding is correct.
I think your perspective is heavily biased by a permanent assumption
that only sole/exclusive licenses can exist, so you try to reduce an
open license to a set of those [sort of]. I don't think that in (most)
open licensing world, such understanding exists, nor practice.
B is not the only licensor to C, even when they channel /in practice/ to
C, the rights from A with added restrictive terms on top of.
Also, I'd note, as AGPL-licensed projects contributor, I never consider
that a BSD or AL2.0 component license is "erased" (though I'm not
entirely convinced it's the same mechanism that seems to "erase" it as
the switch to a proprietary license is, either).
Thank you for the discussion. I've been watching it, and it has been
very instructive.
--
~enyst
"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so
that we have legally your permission to distribute your CC-licensed words?"
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 9 December 2013 16:48, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Mon, Dec 9, 2013 at 11:11 AM, Lawrence Rosen <lr...@rosenlaw.com>wrote:
>
>>
>>
>> But don't exclude the virtues of the CC-BY license (for some licensors!)
>> simply because you didn't consider all possible attribution mechanisms when
>> you entered private deals with your customers.
>>
>>
> Can we please refrain from putting words in other people's mouths? It is
> bad enough that you made a public accusation without any evidence. I
> suggest that we stick to actual concerns that have been expressed, and not
> invent strawmen.
>
But I thought that was just how Larry roles...
Oh well...
;-)
>
> What I have seen is Louis expressing concern over "an anti-DRM provision",
> and Jeff expressing concern over "carrying forward the CC license terms
> verbatim in the user's license to its customer".
>
> Can anybody else cite any other concerns expressed over the use of this
> license within the context of the packages released by ASF PMCs?
>
> - Sam Ruby
>
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Dec 9, 2013 at 11:11 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
>
>
> But don't exclude the virtues of the CC-BY license (for some licensors!)
> simply because you didn't consider all possible attribution mechanisms when
> you entered private deals with your customers.
>
>
Can we please refrain from putting words in other people's mouths? It is
bad enough that you made a public accusation without any evidence. I
suggest that we stick to actual concerns that have been expressed, and not
invent strawmen.
What I have seen is Louis expressing concern over "an anti-DRM provision",
and Jeff expressing concern over "carrying forward the CC license terms
verbatim in the user's license to its customer".
Can anybody else cite any other concerns expressed over the use of this
license within the context of the packages released by ASF PMCs?
- Sam Ruby
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
Both of you take this off-list. I will not allow you both
to continue your squabbles here... It's getting quite old
and tiresome.
On Dec 9, 2013, at 4:42 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Mon, Dec 9, 2013 at 4:26 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> I wrote to Jeff Thompson:
>
> > As long as you honor the requirements of Apache License 2.0,
> > including section 4, then I will retract.
>
>
> Jeff Thompson responded:
>
>
> > I don't see any quotes, so I take that as an indication that you had misunderstood this discussion and you have no actual support for your previous allegations. Can we please keep this discussion at least tangentially related to the matter at hand?
>
>
> I seem to recall you saying earlier in this long thread that IBM does not need to pass along the Apache license for copies and derivative works of ASF software that you distribute. Is that the case or not? That would be a violation of AL2, Section 4.
>
>
> I encourage you to provide a citation where he made that statement.
>
>
> Sam Ruby wrote:
>
> > It is bad enough that you made a public accusation without any evidence.
>
>
>
> I thought I was quoting Jeffrey. If not, I'm sure he'll correct me, and I'm eager to be shown I'm wrong.
>
>
>
> In the meantime, I would appreciate your recusing yourself from this discussion about IBM policies and practices regarding Apache software.
>
>
> This is not a discussion about IBM policies and practices. If you know of a specific violation by IBM, I encourage you to provide something more than an accusation. If you indeed find something, I will readily recuse myself from THAT discussion.
>
> Before on this list, in the middle of a discussion we were having with Jeff, you closed down the discussion about an earlier JIRA issue and sided with your own IBM company attorney. You are personally entitled to do so, but as a board member at Apache you should avoid any conflict of interest, particularly for something as important as IBM's procedures for distributing Apache software and derivative works thereof and for acknowledging the copyrights and licenses of Apache and its contributors.
>
>
> No decisions were made, the relevant JIRA is still open.
>
> https://issues.apache.org/jira/browse/LEGAL-167
>
> There was a separate JIRA where you misunderstood the intent and scope of a W3C experiment, and you, yourself, marked that as closed.
>
> https://issues.apache.org/jira/browse/LEGAL-179
>
>
> /Larry
>
>
> - Sam Ruby
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
I would like to ask people to please:
1. Stick to the topic.
2. Not play childish "pile-on" games.
If people cannot stop being a troll, or feeding a troll,
I will ask you personally to leave.
Clear? Good.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Dec 9, 2013 at 4:26 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> I wrote to Jeff Thompson:
>
> > As long as you honor the requirements of Apache License 2.0,
> > including section 4, then I will retract.
>
> Jeff Thompson responded:
>
> > I don't see any quotes, so I take that as an indication that you had
> misunderstood this discussion and you have no actual support for your
> previous allegations. Can we please keep this discussion at least
> tangentially related to the matter at hand?
>
> I seem to recall you saying earlier in this long thread that IBM does not
> need to pass along the Apache license for copies and derivative works of
> ASF software that you distribute. Is that the case or not? That would be a
> violation of AL2, Section 4.
>
I encourage you to provide a citation where he made that statement.
Sam Ruby wrote:
>
> > It is bad enough that you made a public accusation without any
> evidence.
>
>
>
> I thought I was quoting Jeffrey. If not, I'm sure he'll correct me, and
> I'm eager to be shown I'm wrong.
>
>
>
> In the meantime, I would appreciate your recusing yourself from this
> discussion about IBM policies and practices regarding Apache software.
>
This is not a discussion about IBM policies and practices. If you know of
a specific violation by IBM, I encourage you to provide something more than
an accusation. If you indeed find something, I will readily recuse myself
from THAT discussion.
> Before on this list, in the middle of a discussion we were having with
> Jeff, you closed down the discussion about an earlier JIRA issue and sided
> with your own IBM company attorney. You are personally entitled to do so,
> but as a board member at Apache you should avoid any conflict of interest,
> particularly for something as important as IBM's procedures for
> distributing Apache software and derivative works thereof and for
> acknowledging the copyrights and licenses of Apache and its contributors.
>
No decisions were made, the relevant JIRA is still open.
https://issues.apache.org/jira/browse/LEGAL-167
There was a separate JIRA where you misunderstood the intent and scope of a
W3C experiment, and you, yourself, marked that as closed.
https://issues.apache.org/jira/browse/LEGAL-179
> /Larry
>
- Sam Ruby
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2013, at 6:36 PM, Doug Cutting <cu...@apache.org> wrote:
> On Mon, Dec 9, 2013 at 2:52 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> But when we approach Creative Commons, we should understand our own intentions. For example, is it our intention to limit FOSS contributions to our own projects if one or more of our commercial friends and partners doesn't like the third party license? Or if it will mean that they will have to renegotiate their commercial licenses? Or if it will affect their DRM policies? Or should we set our own criteria for acceptable contributions and acceptable licenses?
>
>
> In many cases our commercial friends and partners are us. Lots of folks have built businesses assuming the ASF's current license policy. As with incompatible API changes, such changes to our license policy should be made only reluctantly and with overwhelming motivation.
>
No one is proposing any such changes to our policy. Nor is
anyone suggesting that such a change would be made willy-nilly
and with no regard to the impact it would create to others.
Certainly the whole crux is whether or not adding CC-BY 4
as Cat-A would, or would not, cause a policy change.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Doug Cutting <cu...@apache.org>.
On Mon, Dec 9, 2013 at 2:52 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> But when we approach Creative Commons, we should understand our own
> intentions. For example, is it our intention to limit FOSS contributions to
> our own projects if one or more of our commercial friends and partners
> doesn't like the third party license? Or if it will mean that they will
> have to renegotiate their commercial licenses? Or if it will affect their
> DRM policies? Or should we set our own criteria for acceptable
> contributions and acceptable licenses?
>
In many cases our commercial friends and partners are us. Lots of folks
have built businesses assuming the ASF's current license policy. As with
incompatible API changes, such changes to our license policy should be made
only reluctantly and with overwhelming motivation.
Doug
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2013, at 5:52 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
>
> What we should NOT do, please, is to keep treating third party licenses in an ad hoc fashion as we've been doing for the past few years. This isn't just about CC-BY. There are lots of copyrighted works in the wild that might be excellent contributions for Apache projects. It makes no sense to analyze each of them in our current haphazard way, divining the meaning of Apache's ambiguous Third Party License Policy anew each time another license is proposed.
>
To be blunt, I think that the understanding of our
policy regarding 3rd party licenses is well understood
enough to help make those determinations. What causes
problems is the conflicting legal opinions on how
various licenses interact with that policy, or even
if it affects or touches the policy at all. I think
that this thread shows that the core tenets of our
policy are well understood enough.
> But with Jim's suggestion in the wind, and with me and others out of wind, I'm winding this thread down. I'll only speak up to object if anyone tries to short circuit the discussion that Jim suggests should take place with Creative Commons or tries to decide this issue before it is fully understood.
I agree.
BTW, I've been made aware that the CC's GC is on-route to
a conference and will be unavailable for a non-insignificant
amount of time, so we will need to put this on hold for
a bit of time. Until then, we are in a holding pattern.
Thx to all for their time and legal insights...
Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
I apologize to Jeffrey and IBM. I have reviewed Jeff's earlier notes here
and I misunderstood his earlier emails. He actually said this on 12/4:
The gist of Apache's policy has been that as long as you're passing on the
notices and otherwise complying with the license, its not a problem if the
user's commercial terms with their customers are different from the Apache
license (for example, most commercial licenses prohibit modification, or at
least void warranties and support, etc if the code is modified).
This seems to indicate that IBM in fact aware that it must pass along the
notices and comply with Apache License Section 4. I misspoke. I'm sorry.
I believe we still differ about what this means for our customers. I have
asserted that this indicates that the Apache License 2.0 continues to apply
to the original Apache software incorporated into IBM's products; that
license is not extinguished by the new commercial license under which IBM
distributes its products, any more than the GPL is extinguished on Linux by
Red Hat or Oracle commercial licenses. In a practical and legal sense, IBM
can add things like warranties, services, support, indemnity, etc., but it
can't take away from its customers any of the original rights to the work
that Apache gave to the entire world.
I'm carefully agreeing with Jeff's assertion that IBM can offer Apache
software to IBM's customers under a limited set of Apache's terms and
conditions. As long as users receive the original license and NOTICES, they
know what they are getting and where they can get the original work for
free, and Apache doesn't care about the commercial relationship at all.
But where this matters is when Apache elects to include third party software
(or other copyrighted materials) under one of many other FOSS licenses that
are available to us, into our software. Now THOSE license terms also apply
to portions of the Apache work, and so we have to understand the effects of
THOSE licenses also.
We have argued here for months about CC-BY, for example. Opinions about this
license differ widely. Unfortunately, this list has also been peppered with
untrue statements about that license, including false assertions that it has
been rejected by other FOSS organizations. Quite frankly, Jim Jagielski just
made the most intelligent comment in this thread in days, namely to discuss
this directly with the Creative Commons folks:
To me this seems the logical next step: we can continue to go around and
around and debate the letter, but all that is, imo at least, secondary to
the what their intent was and is. I consider this almost a parallel to how
we understand and honor the 4-clause BSD...
That is also what FSF is doing, according to Eben Moglen. I know that W3C is
still in conversation with Creative Commons about a license for their
standards. That is what Apache and other companies participating on this
list should do.
But when we approach Creative Commons, we should understand our own
intentions. For example, is it our intention to limit FOSS contributions to
our own projects if one or more of our commercial friends and partners
doesn't like the third party license? Or if it will mean that they will have
to renegotiate their commercial licenses? Or if it will affect their DRM
policies? Or should we set our own criteria for acceptable contributions and
acceptable licenses?
What we should NOT do, please, is to keep treating third party licenses in
an ad hoc fashion as we've been doing for the past few years. This isn't
just about CC-BY. There are lots of copyrighted works in the wild that might
be excellent contributions for Apache projects. It makes no sense to analyze
each of them in our current haphazard way, divining the meaning of Apache's
ambiguous Third Party License Policy anew each time another license is
proposed.
But with Jim's suggestion in the wind, and with me and others out of wind,
I'm winding this thread down. I'll only speak up to object if anyone tries
to short circuit the discussion that Jim suggests should take place with
Creative Commons or tries to decide this issue before it is fully
understood.
Good night.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/>
www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Lawrence Rosen [mailto:lrosen@rosenlaw.com]
Sent: Monday, December 09, 2013 1:26 PM
To: legal-discuss@apache.org
Cc: Lawrence Rosen
Subject: RE: New versions of CC licenses
I wrote to Jeff Thompson:
> As long as you honor the requirements of Apache License 2.0,
> including section 4, then I will retract.
Jeff Thompson responded:
> I don't see any quotes, so I take that as an indication that you had
misunderstood this discussion and you have no actual support for your
previous allegations. Can we please keep this discussion at least
tangentially related to the matter at hand?
I seem to recall you saying earlier in this long thread that IBM does not
need to pass along the Apache license for copies and derivative works of ASF
software that you distribute. Is that the case or not? That would be a
violation of AL2, Section 4.
Sam Ruby wrote:
> It is bad enough that you made a public accusation without any evidence.
I thought I was quoting Jeffrey. If not, I'm sure he'll correct me, and I'm
eager to be shown I'm wrong.
In the meantime, I would appreciate your recusing yourself from this
discussion about IBM policies and practices regarding Apache software.
Before on this list, in the middle of a discussion we were having with Jeff,
you closed down the discussion about an earlier JIRA issue and sided with
your own IBM company attorney. You are personally entitled to do so, but as
a board member at Apache you should avoid any conflict of interest,
particularly for something as important as IBM's procedures for distributing
Apache software and derivative works thereof and for acknowledging the
copyrights and licenses of Apache and its contributors.
/Larry
From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Monday, December 09, 2013 10:38 AM
To: legal-discuss@apache.org
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/09/2013 11:11:44 AM:
> Jeff Thompson wrote:
> > Larry,
> > What conversation have you been following? If you're going to
> > accuse me and/or IBM of violating the Apache license, please provide
> > specific statements that I've made that support those accusations.
> > If any statements that I've made have been misconstrued, I'll
> > clarify them. If you can't produce any statements that I've made
> > that support your allegations, I expect a retraction.
>
> As long as you honor the requirements of Apache License 2.0,
> including section 4, then I will retract.
I don't see any quotes, so I take that as an indication that you had
misunderstood this discussion and you have no actual support for your
previous allegations. Can we please keep this discussion at least
tangentially related to the matter at hand?
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/09/2013 04:26:13 PM:
> Jeff Thompson responded:
> > I don't see any quotes, so I take that as an indication that you
> > had misunderstood this discussion and you have no actual support for
> > your previous allegations. Can we please keep this discussion at
> > least tangentially related to the matter at hand?
> I seem to recall you saying earlier in this long thread that IBM
> does not need to pass along the Apache license for copies and
> derivative works of ASF software that you distribute.
Larry,
Seeming to recall things is no justification. There is no way that we
can determine whether I was inartful in one of my statements or you
misunderstood something that I wrote if you continue to be vague and
unclear. Either quote a statement that you think supports your allegations
or stop making them.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
I wrote to Jeff Thompson:
> As long as you honor the requirements of Apache License 2.0,
> including section 4, then I will retract.
Jeff Thompson responded:
> I don't see any quotes, so I take that as an indication that you had
misunderstood this discussion and you have no actual support for your
previous allegations. Can we please keep this discussion at least
tangentially related to the matter at hand?
I seem to recall you saying earlier in this long thread that IBM does not
need to pass along the Apache license for copies and derivative works of ASF
software that you distribute. Is that the case or not? That would be a
violation of AL2, Section 4.
Sam Ruby wrote:
> It is bad enough that you made a public accusation without any evidence.
I thought I was quoting Jeffrey. If not, I'm sure he'll correct me, and I'm
eager to be shown I'm wrong.
In the meantime, I would appreciate your recusing yourself from this
discussion about IBM policies and practices regarding Apache software.
Before on this list, in the middle of a discussion we were having with Jeff,
you closed down the discussion about an earlier JIRA issue and sided with
your own IBM company attorney. You are personally entitled to do so, but as
a board member at Apache you should avoid any conflict of interest,
particularly for something as important as IBM's procedures for distributing
Apache software and derivative works thereof and for acknowledging the
copyrights and licenses of Apache and its contributors.
/Larry
From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Monday, December 09, 2013 10:38 AM
To: legal-discuss@apache.org
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/09/2013 11:11:44 AM:
> Jeff Thompson wrote:
> > Larry,
> > What conversation have you been following? If you're going to
> > accuse me and/or IBM of violating the Apache license, please provide
> > specific statements that I've made that support those accusations.
> > If any statements that I've made have been misconstrued, I'll
> > clarify them. If you can't produce any statements that I've made
> > that support your allegations, I expect a retraction.
>
> As long as you honor the requirements of Apache License 2.0,
> including section 4, then I will retract.
I don't see any quotes, so I take that as an indication that you had
misunderstood this discussion and you have no actual support for your
previous allegations. Can we please keep this discussion at least
tangentially related to the matter at hand?
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/09/2013 11:11:44 AM:
> Jeff Thompson wrote:
> > Larry,
> > What conversation have you been following? If you're going to
> > accuse me and/or IBM of violating the Apache license, please provide
> > specific statements that I've made that support those accusations.
> > If any statements that I've made have been misconstrued, I'll
> > clarify them. If you can't produce any statements that I've made
> > that support your allegations, I expect a retraction.
>
> As long as you honor the requirements of Apache License 2.0,
> including section 4, then I will retract.
I don't see any quotes, so I take that as an indication that you had
misunderstood this discussion and you have no actual support for your
previous allegations. Can we please keep this discussion at least
tangentially related to the matter at hand?
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff Thompson wrote:
> Larry,
What conversation have you been following? If you're going to accuse me
and/or IBM of violating the Apache license, please provide specific
statements that I've made that support those accusations. If any statements
that I've made have been misconstrued, I'll clarify them. If you can't
produce any statements that I've made that support your allegations, I
expect a retraction.
As long as you honor the requirements of Apache License 2.0, including
section 4, then I will retract. Do you distribute the Apache License, along
with the other licenses listed in our NOTICE files, with every IBM
distribution that includes Apache software?
Since the beginning of FOSS there have been attribution requirements in
licenses. I presume that they are important to most authors. I'd describe
many of those provisions as attempts to accomplish with attribution notices
what trademark law otherwise provides in a far more complicated legal way.
As a result, we have created a hodgepodge of notice rules in the BSD, MIT,
MPL, GPL, AL2, etc., licenses that make consistent procedures difficult to
implement, particularly for commercial vendors. It is a shame that it is so
complicated. But as for the Apache License 2.0, IBM attorneys helped draft
it, so its provisions should not be deemed onerous to IBM.
As you point out, CC-BY has its own somewhat unique version of those notice
requirements as well as other provisions designed to protect the reputation
of the author and to guarantee the continuing availability of the published
work. I'm sorry that you didn't consider that license when you drafted IBM's
earlier commercial licenses. But don't exclude the virtues of the CC-BY
license (for some licensors!) simply because you didn't consider all
possible attribution mechanisms when you entered private deals with your
customers.
Best regards,
/Larry
From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Monday, December 09, 2013 5:22 AM
To: legal-discuss@apache.org
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/08/2013 09:10:36 PM:
> Jeff Thompson wrote:
> > I'm happy we put that issue to bed.
>
> Jeff, please don't exaggerate. Unfortunately we didn't put anything
> important to bed except the conclusion that GPL-licensed works MUST
> BE DISCLOSED. You still refuse to treat Apache works with the same
> respect for its license as we give to the GPL.
Larry,
What conversation have you been following? If you're going to accuse me
and/or IBM of violating the Apache license, please provide specific
statements that I've made that support those accusations. If any statements
that I've made have been misconstrued, I'll clarify them. If you can't
produce any statements that I've made that support your allegations, I
expect a retraction.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/08/2013 09:10:36 PM:
> Jeff Thompson wrote:
> > I'm happy we put that issue to bed.
>
> Jeff, please don't exaggerate. Unfortunately we didn't put anything
> important to bed except the conclusion that GPL-licensed works MUST
> BE DISCLOSED. You still refuse to treat Apache works with the same
> respect for its license as we give to the GPL.
Larry,
What conversation have you been following? If you're going to accuse
me and/or IBM of violating the Apache license, please provide specific
statements that I've made that support those accusations. If any
statements that I've made have been misconstrued, I'll clarify them. If
you can't produce any statements that I've made that support your
allegations, I expect a retraction.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff Thompson wrote:
> I'm happy we put that issue to bed.
Jeff, please don't exaggerate. Unfortunately we didn't put anything
important to bed except the conclusion that GPL-licensed works MUST BE
DISCLOSED. You still refuse to treat Apache works with the same respect for
its license as we give to the GPL.
As Richard Fontana keeps pointing out, we are also stymied apparently
because IBM negotiated certain private deals in the past with its customers,
and that is interfering with Apache's ability to decide for itself which
FOSS contributions we may accept in the future for /our/ projects. You want
your commercial needs to override our technical decisions.
The fact that most other distributors of FOSS software, including everyone I
know who distributes Linux, are more diligent in their disclosures, should
alert you to your problem. Most FOSS licenses require the posting of notices
and the disclosure of FOSS license terms, even those licenses that don't
require the posting of source code - even the Apache License 2.0.
We can't keep ignoring the fact that IBM may not be honoring Apache License
section 4. In particular, you say that you don't have to disclose the
application of the Apache License to software originally obtain from ASF (AL
section 4(a) requires that!). And furthermore, if we choose to include
components from third parties, you insist that you don't have to disclose
those contributions.
I find your conclusion particularly remarkable because the words of the
Apache License are so clear in section 4. And IBM attorneys were the ones
who most contributed to the drafting of that license. Why are you now
interpreting those provisions out of the license?
I know that certain folks here want this discussion to be limited to one
license (CC-BY) that we're not now certain any Apache project yet needs, but
the problem you have highlighted is profound. We need to conclude this issue
one way or the other, on this list or on other lists where more FOSS
attorneys will participate in the discussion. But we obviously can't let IBM
alone dictate the ways that the Apache License must be honored.
Best regards,
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Sunday, December 08, 2013 5:35 PM
To: legal-discuss@apache.org
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/07/2013 04:50:44 PM:
> Jeff Thompson wrote:
> > I am saying, as between B and C, if they've agreed to exchange the
> code under the GPL, as between those two, that's the license.
>
> I agree with that.
Great. I'm happy we put that issue to bed.
> So also if Red Hat takes software from the Linux
> Foundation under the GPL and agrees with its customers to make that
> available under a commercial license, then as between them the
> commercial license is the deal.
Don't agree with you on that one, but as you point out, that's an issue
between RH and the Linux contributors. As I read the GPL, there are terms
that say you have to pass on the GPL code under the GPL terms and no other
license, so the analogy between that an the AL2.0 fails.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/07/2013 04:50:44 PM:
> Jeff Thompson wrote:
> > I am saying, as between B and C, if they've agreed to exchange the
> code under the GPL, as between those two, that's the license.
>
> I agree with that.
Great. I'm happy we put that issue to bed.
> So also if Red Hat takes software from the Linux
> Foundation under the GPL and agrees with its customers to make that
> available under a commercial license, then as between them the
> commercial license is the deal.
Don't agree with you on that one, but as you point out, that's an issue
between RH and the Linux contributors. As I read the GPL, there are terms
that say you have to pass on the GPL code under the GPL terms and no other
license, so the analogy between that an the AL2.0 fails.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff Thompson wrote:
> I am saying, as between B and C, if they've agreed to exchange the code
under the GPL, as between those two, that's the license.
I agree with that. So also if Red Hat takes software from the Linux
Foundation under the GPL and agrees with its customers to make that
available under a commercial license, then as between them the commercial
license is the deal. Perhaps Richard and other Linux vendor attorneys who
are on this list can tell us: Does anybody believe that this private deal
between Red Hat and its customers erases the effect of the GPL on that Linux
software?
If IBM takes Apache Hadoop and makes it available to its customers under a
commercial license, then the mutual promises between IBM and its customers
define that transaction. I presume IBM will promise all sorts of warranties,
indemnity, and other protections that will encourage customers to pay for
free software. But that doesn't extinguish the Apache License and the
licensing requirements that ASF demands of all downstream licensees.
> Think if it this way, if A licensed B the code under AL2.0 as a private
deal and not one that A has ever made available to anyone else. Does it
change your mind on whether C should be able to exercise AL2.0 rights to
that code after it receives them from B under the GPL? I would say the
answer to that questions HAS TO BE yes, it does affect the answer. C
doesn't have an offer from A under AL2.0, so C's only avenue of rights is
from B and B's grant is under the GPL, so that's what C is stuck with.
And I agree with that also. Indeed, I have sometimes encouraged the
/private/ licensing of code under the AL2 license, for example using AL2 as
a /contribution license/ for projects or companies that are satisfied with
obtaining AL2 rights privately. That's entirely up to the licensor and the
private licensee. I recently even helped negotiate a private /amended/ AL2
license between my client and Google that changed certain patent terms to
satisfy the Android project. I make my living doing private deals. :-)
But that's not Apache! We don't do private deals. If IBM or LibreOffice or
anyone else wants our software, it is made available publicly on our website
to all on equal terms. Enjoy it, but honor our license.
And either honor the special licenses of our contributors identified in our
NOTICE file, or remove those contributions from our code before you
distribute it.
Best,
/Larry
From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Saturday, December 07, 2013 11:33 AM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
Richard Fontana <rf...@redhat.com> wrote on 12/07/2013 12:54:22 AM:
> But okay, maybe "*needs* to read" is debatable. Depends on the
> circumstances. In Jeff's hypothetical above, suppose I'm C and I want
> to use the A code in some GPL-incompatibly-licensed product or
> project. Sure, I can say that the A code got magically transformed
> into GPL code and is tainted forever, forcing me either to find an
> upstream copy or variant (which won't always be easy or suitable) or
> to accept that the A code is stuck in a GPL state or to find or write
> some substitute. But if it's clear enough upon analysis that the A
> code was ALv2 and was not adapted in such a way that the adaptation
> would have to be licensed under GPL (a common scenario), then I ought
> to look at what ALv2 says and see what options that gives me.
I think that Richard's question might help eliminate one source of
disagreement. I'm not saying that B's inclusion of A's code in a GPL
licensed product somehow extinguishes A's offer of that code under the
AL2.0.
I am saying, as between B and C, if they've agreed to exchange the code
under the GPL, as between those two, that's the license. If C knows that
the code is also available under AL2.0 from A, unless there's some other
contractual obligation that C has that prevents it from doing so, C can
exercise AL2.0 rights to that code without having to go get an upstream copy
or do anything else. But, just because those rights are available, it
doesn't mean that B is participating in the conveyance of those AL2.0
rights.
As I described in an earlier note, copyright creates a right to prohibit
certain conduct, but A can't enforce a copyright prohibition on copying if
it has licensed the person its trying to enforce against. So, if C exercises
AL2.0 rights to that code it actually received under the GPL, but for which
it has confirmed that it benefits from A's public offer of AL2.0 rights, who
could sue it under the copyright act to stop it from exercising full AL2.0
rights? B can't because its not the copyright owner. A can't because it
offered (and C accepted) rights under AL2.0. So, C is safe. This has
NOTHING to do with B passing on AL2.0 rights to C.
Think if it this way, if A licensed B the code under AL2.0 as a private deal
and not one that A has ever made available to anyone else. Does it change
your mind on whether C should be able to exercise AL2.0 rights to that code
after it receives them from B under the GPL? I would say the answer to that
questions HAS TO BE yes, it does affect the answer. C doesn't have an offer
from A under AL2.0, so C's only avenue of rights is from B and B's grant is
under the GPL, so that's what C is stuck with.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Jim Jagielski <ji...@jaguNET.com> wrote on 12/09/2013 08:35:18 AM:
> From: Jim Jagielski <ji...@jaguNET.com>
> To: "legal-discuss@apache.org Discuss" <le...@apache.org>,
> Date: 12/09/2013 08:35 AM
> Subject: Re: New versions of CC licenses
>
>
> On Dec 8, 2013, at 9:10 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> >
> > I understand, but Apache's policy of public offers doesn't change
> the law of copyright licensing.
> >
>
> I understand that, but I'm still now sure where and how this
> affects us, the ASF. If this whole discussion is based on
> actions or policies that the ASF doesn't take part in, then
> I fail to see how this is an ASF issue.
I don't think that it changes anything that ASF has to do. We were
discussing precisely what terms could apply between an Apache consumer (B)
and its customer (C). My statement is that, notwithstanding Apache's
policy of making a public offer under the AL2.0, once B gets the code it
can (in its license) pass on only a subset of AL2.0 rights (e.g., B's
license terms can prohibit modification). That doesn't mean that C still
doesn't have available the public offer from ASF under AL2.0, its just the
B is not participating in that part of the transaction.
This all started with Larry's proposal of CC-BY. I pointed out that there
is language in it that seems to state that B can't prohibit modification of
the included CC-BY material. At that point, we went off on a tangent of
whether AL2.0 prevents B from prohibiting modification of included AL2.0
code. Again, I'm focusing specifically just on the terms of the license
between B and C. Any rights that C has directly from A is a different
question.
As far as I'm concerned, ASF doesn't need to do anything. But, if it plans
in adopting CC-BY as a Category A license (which as I understand it is the
category of licenses for which there are no restriction on how material
under that license is incorporated into ASF projects), then I think it
should seek clarification of that anti-DRM paragraph in CC-BY because it
could cause problems. At the very least, as Larry and Richard suggested,
the projects need to be designed to enable quick and easy removal of the
CC-BY material and consumers of that project need to be put on notice of
the potential problem.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Dec 9, 2013 at 8:35 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Dec 8, 2013, at 9:10 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> >
> > I understand, but Apache's policy of public offers doesn't change the
> law of copyright licensing.
>
> I understand that, but I'm still now sure where and how this
> affects us, the ASF. If this whole discussion is based on
> actions or policies that the ASF doesn't take part in, then
> I fail to see how this is an ASF issue.
>
One way to resolve this discussion would be to recognize that we don't have
consensus and remove Creative Commons Attribution
<http://creativecommons.org/licenses/by/3.0/>2.5 and 3.0 (commonly referred
to as either CC-A or CC-BY) from the Previously Asked Questions page[1]
entirely.
I suggest that we will have a much easier time dealing with specific
questions like whether or not a specific PMC can ship a specific slide deck
that is licensed under CC-BY as accompanying documentation for their
project.
- Sam Ruby
[1] http://www.apache.org/legal/resolved.html
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 8, 2013, at 9:10 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
>
> I understand, but Apache's policy of public offers doesn't change the law of copyright licensing.
>
I understand that, but I'm still now sure where and how this
affects us, the ASF. If this whole discussion is based on
actions or policies that the ASF doesn't take part in, then
I fail to see how this is an ASF issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Jim Jagielski <ji...@jaguNET.com> wrote on 12/08/2013 07:15:56 PM:
> On Dec 7, 2013, at 2:32 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> >
> > Think if it this way, if A licensed B the code under AL2.0 as a
> private deal and not one that A has ever made available to anyone
> else. Does it change your mind on whether C should be able to
> exercise AL2.0 rights to that code after it receives them from B
> under the GPL? I would say the answer to that questions HAS TO BE
> yes, it does affect the answer. C doesn't have an offer from A
> under AL2.0, so C's only avenue of rights is from B and B's grant is
> under the GPL, so that's what C is stuck with.
>
>
> But how does this affect the ASF at all? We license our code to anyone
> and everyone under the ALv2, so in the above scenario, C would already
> have a pre-existing ability to use the code under ALv2 no
> matter what B does. And the ASF never does "private deals"...
I understand, but Apache's policy of public offers doesn't change the law
of copyright licensing.
Larry and Richard were arguing that licensing law requires that full AL2.0
rights be passed on by B to C even though there is nothing in AL2.0 that
says that. If there were a rule of interpretation for software licenses
that did imply such an obligation, it would be independent of whether A's
offer was public or private.
> All we want is to make sure that no matter what B tells C,
> that for the parts of B that came from A, C knows that it
> can also get those parts from A, under ALv2, no matter
> the license that B provided to C in the derivative work.
>
> So in the above, C *always* has an offer from A under ALv2. Always.
Right. I agree 100%. That's what the section 4 conditions implement. B
must provide C a copy of AL2.0, etc., etc. That doesn't change the terms
of the license grant between B and C, though. But, more to your point,
nothing in the license grant between B and C would change the availability
of A's grant to C under AL2.0 either. If A's offer is made generally
available to the public, it remains available to C notwithstanding B's
license terms.
I think all of us in this conversation agree on that result (though, I
think some of us might disagree on the particulars of how we get there).
What started all of this was the observation that CC-BY is different
because it REQUIRES that B's license to C include all of the CC-BY rights,
which AL2.0 does not.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 7, 2013, at 2:32 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
>
> Think if it this way, if A licensed B the code under AL2.0 as a private deal and not one that A has ever made available to anyone else. Does it change your mind on whether C should be able to exercise AL2.0 rights to that code after it receives them from B under the GPL? I would say the answer to that questions HAS TO BE yes, it does affect the answer. C doesn't have an offer from A under AL2.0, so C's only avenue of rights is from B and B's grant is under the GPL, so that's what C is stuck with.
But how does this affect the ASF at all? We license our code to anyone
and everyone under the ALv2, so in the above scenario, C would already
have a pre-existing ability to use the code under ALv2 no
matter what B does. And the ASF never does "private deals"...
All we want is to make sure that no matter what B tells C,
that for the parts of B that came from A, C knows that it
can also get those parts from A, under ALv2, no matter
the license that B provided to C in the derivative work.
So in the above, C *always* has an offer from A under ALv2. Always.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/07/2013 12:54:22 AM:
> But okay, maybe "*needs* to read" is debatable. Depends on the
> circumstances. In Jeff's hypothetical above, suppose I'm C and I want
> to use the A code in some GPL-incompatibly-licensed product or
> project. Sure, I can say that the A code got magically transformed
> into GPL code and is tainted forever, forcing me either to find an
> upstream copy or variant (which won't always be easy or suitable) or
> to accept that the A code is stuck in a GPL state or to find or write
> some substitute. But if it's clear enough upon analysis that the A
> code was ALv2 and was not adapted in such a way that the adaptation
> would have to be licensed under GPL (a common scenario), then I ought
> to look at what ALv2 says and see what options that gives me.
I think that Richard's question might help eliminate one source of
disagreement. I'm not saying that B's inclusion of A's code in a GPL
licensed product somehow extinguishes A's offer of that code under the
AL2.0.
I am saying, as between B and C, if they've agreed to exchange the code
under the GPL, as between those two, that's the license. If C knows that
the code is also available under AL2.0 from A, unless there's some other
contractual obligation that C has that prevents it from doing so, C can
exercise AL2.0 rights to that code without having to go get an upstream
copy or do anything else. But, just because those rights are available, it
doesn't mean that B is participating in the conveyance of those AL2.0
rights.
As I described in an earlier note, copyright creates a right to prohibit
certain conduct, but A can't enforce a copyright prohibition on copying if
it has licensed the person its trying to enforce against. So, if C
exercises AL2.0 rights to that code it actually received under the GPL, but
for which it has confirmed that it benefits from A's public offer of AL2.0
rights, who could sue it under the copyright act to stop it from exercising
full AL2.0 rights? B can't because its not the copyright owner. A can't
because it offered (and C accepted) rights under AL2.0. So, C is safe.
This has NOTHING to do with B passing on AL2.0 rights to C.
Think if it this way, if A licensed B the code under AL2.0 as a private
deal and not one that A has ever made available to anyone else. Does it
change your mind on whether C should be able to exercise AL2.0 rights to
that code after it receives them from B under the GPL? I would say the
answer to that questions HAS TO BE yes, it does affect the answer. C
doesn't have an offer from A under AL2.0, so C's only avenue of rights is
from B and B's grant is under the GPL, so that's what C is stuck with.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Fri, Dec 06, 2013 at 08:34:33PM -0500, Sam Ruby wrote:
> On Fri, Dec 6, 2013 at 4:39 PM, Richard Fontana <rf...@redhat.com> wrote:
>
> On Fri, Dec 06, 2013 at 04:10:23PM -0500, Jeffrey Thompson wrote:
> > In my hypo from a few notes ago, A distributes software to B under AL2.0.
> B
> > combines it with GPL code and distributes the result to C under the GPL.
> As
> > far as C is concerned, the GPL is the only license it needs to read in
> order to
> > understand what rights it gets from B, even for A's code. AL2.0 is in
> the
> > notices file and C can review that if it wants to, but if there ever is a
> > dispute between B and C, the license of record, the terms that get
> submitted to
> > the court for interpretation, is the GPL, right?
>
> Maybe, maybe not, depending on what the dispute is about. "The only
> license it needs to read" is not correct. C needs to read the Apache
> License 2.0 to understand fully the rights it is getting and the
> requirements or obligations it has to upstream licensors.
>
> The Apache License does not *vanish*.
>
>
> I'm having trouble reconciling this with what the LibreOffice community does
> (with our blessing!). Note that there are no mentions at all of Apache on
> either of the following pages:
>
> http://www.libreoffice.org/download/license/
> http://www.libreoffice.org/about-us/faq/licensing-faq/
>
> That project certainly gives the strong impression that LGPL2 (and MPL) are
> "the only license it needs to read"... for licensees of that project.
I won't speak of LibreOffice which is a unique case for many reasons. :)
But okay, maybe "*needs* to read" is debatable. Depends on the
circumstances. In Jeff's hypothetical above, suppose I'm C and I want
to use the A code in some GPL-incompatibly-licensed product or
project. Sure, I can say that the A code got magically transformed
into GPL code and is tainted forever, forcing me either to find an
upstream copy or variant (which won't always be easy or suitable) or
to accept that the A code is stuck in a GPL state or to find or write
some substitute. But if it's clear enough upon analysis that the A
code was ALv2 and was not adapted in such a way that the adaptation
would have to be licensed under GPL (a common scenario), then I ought
to look at what ALv2 says and see what options that gives me.
In the open source universe there are lots of projects that I would
say are, in presenting the software to the world, hiding (to some
degree) the licensing complexity of the software they release. This is
not done to deceive anyone; I think it's just thought that it's enough
to give the user the opportunity to find out as much information as
the project itself was able to find out. There's a high level of trust
inherent in the whole system that it is possible to find out a
satisfactory amount of information. (This has implications for
proprietary software since typically such software incorporates code
that originates with open source projects.) I stopped complaining
about this complexity-hiding practice long ago; it's a cultural
fixture and there's not much I can do about it.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 07:11:48PM -0500, Richard Fontana wrote:
> On Thu, Dec 05, 2013 at 07:00:08PM -0500, Jeffrey Thompson wrote:
> > Copyright is U.S. federal law, not state law.
>
> Licenses are creatures of state law.
Actually thinking of at least one issue where federal courts have
passed on copyright licenses, this may not be entirely true, so I'll
revise that to hybrid federal/state. :)
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 07:00:08PM -0500, Jeffrey Thompson wrote:
> Copyright is U.S. federal law, not state law.
Licenses are creatures of state law.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2013, at 6:03 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Mon, Dec 9, 2013 at 5:32 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> I do see Jeff's point, but "commercially friendly" does not
> mean "that a company will never have to change their
> commercial license" but rather that they will always have
> the ability (and dare I say it, freedom) to create a commercial
> offering based on the code and do so under a commercial
> license.
>
> Do you feel the same way about compatibility with the Mozilla Public License or the GPL?
>
> http://www.mozilla.org/MPL/license-policy.html#Licenses_Compatible_with_the_MPL
> http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
>
off-topic.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Dec 9, 2013 at 5:32 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> I do see Jeff's point, but "commercially friendly" does not
> mean "that a company will never have to change their
> commercial license" but rather that they will always have
> the ability (and dare I say it, freedom) to create a commercial
> offering based on the code and do so under a commercial
> license.
>
Do you feel the same way about compatibility with the Mozilla Public
License or the GPL?
http://www.mozilla.org/MPL/license-policy.html#Licenses_Compatible_with_the_MPL
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
- Sam Ruby
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Jim Jagielski <ji...@jaguNET.com> wrote on 12/09/2013 05:32:36 PM:
> FWIW, I find Richard's explanations and descriptions more
> in keeping with the intent and goals of expected of Cat-A
> licenses. I see no need for us to remove CC-A and CC-BY
> (2.5 and 3) from Cat-A and, at present, do not see a
> major compelling reason that 4 would also not be Cat-A.
Jim,
I'd agree 100% with Richard that there is no problem IF the CC-BY
language doesn't require a commercial licensor to change its terms, but
really addresses preserving the separate grant by A directly to C. As you
mentioned, definitive guidance from the CC-BY authors would be very
helpful. If it turns out that my initial worry was unfounded, I'd be
exceedingly happy about that.
Per your other note, I'm putting my pen away now.
Jeff
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, I find Richard's explanations and descriptions more
in keeping with the intent and goals of expected of Cat-A
licenses. I see no need for us to remove CC-A and CC-BY
(2.5 and 3) from Cat-A and, at present, do not see a
major compelling reason that 4 would also not be Cat-A.
I do see Jeff's point, but "commercially friendly" does not
mean "that a company will never have to change their
commercial license" but rather that they will always have
the ability (and dare I say it, freedom) to create a commercial
offering based on the code and do so under a commercial
license.
I don't consider the matter closed, but I think the
discussion should focus on how, if at all, this
affects our projects' and PMCs' ability to release
code. From what I can see and understand, adding 4
to Cat-A doesn't harm the project or the code at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/08/2013 11:05:52 PM:
> On Sun, Dec 08, 2013 at 08:46:52PM -0500, Jeffrey Thompson wrote:
> > Most commercial software licenses prohibit modification and
redistribution.
> >
> > CC-BY requires, as I read the language, that you distribute the
> CC-BY content
> > under terms with authorize modification and redistribution.
>
> CC BY 4.0 specifically says:
>
> You may not offer or impose any additional or different terms or
> conditions on, or apply any Effective Technological Measures to, the
> Licensed Material if doing so restricts exercise of the Licensed
> Rights by any recipient of the Licensed Material.
>
> And:
>
> If You Share Adapted Material You produce, the Adapter's License You
> apply must not prevent recipients of the Adapted Material from
> complying with this Public License.
>
> "Licensed Material" is the original stuff you get under CC BY. The
> definition of "Adapted Material" is:
>
> material subject to Copyright and Similar Rights that is derived
> from or based upon the Licensed Material and in which the Licensed
> Material is translated, altered, arranged, transformed, or otherwise
> modified in a manner requiring permission under the Copyright and
> Similar Rights held by the Licensor.
>
> Taking all that together... I'm not sure you're right.
Well, I'm not sure I'm right either. Its a brand new license, hasn't been
interpreted by a court, and I haven't seen guidance on that point from
CC-BY. If what they mean, and if what comes to be the general
interpretation, is that restrictions between B and C are OK because C
always has the direct grant available from A, then that'll resolve my
question. However, I don't think we can assume that interpretation. Maybe
a simple request for clarification from the CC-BY authors would help.
> Suppose your commercially-licensed product is delivered in source code
> form, and it includes a copyrightable ASF project Apache License 2.0
> source file that is textually identical to the upstream
> ASF-distributed source file. It includes the typical ASF project
> header. I am not clear on whether you are contending that this
> identical downstream *copy* cannot be modified or redistributed
> because your commercial license says that modification and
> redistribution are prohibited. Is this *copy* tainted, such that I
> have to go to apache.org to get a digitally identical copy of the same
> file (or to make it more interesting, a copy that is different only in
> some trivial way with no copyright significance)? If your view is that
> I can exercise ALv2 rights in that file without going to apache.org,
> then I think you are saying that ALv2 and CC BY 4.0 are largely
> similar.
I'm not saying that any copy is tainted, or that C has to go get another
download of the AL2.0 software. I brought up the issue of whether or not B
has to change its license terms, that's it.
> Here we ought to recognize the reality that CC BY is typically not
> applied to software, even when it covers things included in
> largely-software works. CC BY is more likely to be applied to image
> files or formal documentation (and formal documentation under a CC
> license isn't typically bundled with upstream software releases). This
> is stuff that has a separable quality to it that I'd agree might not
> be so obviously true if we were talking about a bunch of source code
> files.
But, if CC-BY material is bundled with software (say, images), then we
still have the problem. But I take your point. Unfortunately, in my
travels, I've seen too many CC-BY licensed software projects.
>
> In the typical case, if the commercial licensor is so concerned about
> the prospect of CC BY material it can easily identify and remove it at
> low cost before product shipment. Get rid of the upstream
> documentation, replace the images. I believe Larry has made a point
> similar to this.
Right. And, as I understood Category A, it was intended to be the
collection of licenses for which the recipient wouldn't have to worry about
that. Category B was for licenses where the recipient needed to take some
care.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Sun, Dec 08, 2013 at 08:46:52PM -0500, Jeffrey Thompson wrote:
> Most commercial software licenses prohibit modification and redistribution.
>
> CC-BY requires, as I read the language, that you distribute the CC-BY content
> under terms with authorize modification and redistribution.
CC BY 4.0 specifically says:
You may not offer or impose any additional or different terms or
conditions on, or apply any Effective Technological Measures to, the
Licensed Material if doing so restricts exercise of the Licensed
Rights by any recipient of the Licensed Material.
And:
If You Share Adapted Material You produce, the Adapter's License You
apply must not prevent recipients of the Adapted Material from
complying with this Public License.
"Licensed Material" is the original stuff you get under CC BY. The
definition of "Adapted Material" is:
material subject to Copyright and Similar Rights that is derived
from or based upon the Licensed Material and in which the Licensed
Material is translated, altered, arranged, transformed, or otherwise
modified in a manner requiring permission under the Copyright and
Similar Rights held by the Licensor.
Taking all that together... I'm not sure you're right. What CC BY 4.0
seems to be saying is that your derivative work license, which perhaps
can otherwise be arbitrarily restrictive, cannot block the derivative
work licensee from exercising CC BY rights in, and complying with the
upstream CC BY obligations applicable to, the *original stuff*.
Suppose your commercially-licensed product is delivered in source code
form, and it includes a copyrightable ASF project Apache License 2.0
source file that is textually identical to the upstream
ASF-distributed source file. It includes the typical ASF project
header. I am not clear on whether you are contending that this
identical downstream *copy* cannot be modified or redistributed
because your commercial license says that modification and
redistribution are prohibited. Is this *copy* tainted, such that I
have to go to apache.org to get a digitally identical copy of the same
file (or to make it more interesting, a copy that is different only in
some trivial way with no copyright significance)? If your view is that
I can exercise ALv2 rights in that file without going to apache.org,
then I think you are saying that ALv2 and CC BY 4.0 are largely
similar.
> To me, that means that the CC-BY license is not compatible with commercial
> software licenses, since its very likely that you can't take CC-BY licensed
> software and distribute it under your existing commercial software license.
Here we ought to recognize the reality that CC BY is typically not
applied to software, even when it covers things included in
largely-software works. CC BY is more likely to be applied to image
files or formal documentation (and formal documentation under a CC
license isn't typically bundled with upstream software releases). This
is stuff that has a separable quality to it that I'd agree might not
be so obviously true if we were talking about a bunch of source code
files.
In the typical case, if the commercial licensor is so concerned about
the prospect of CC BY material it can easily identify and remove it at
low cost before product shipment. Get rid of the upstream
documentation, replace the images. I believe Larry has made a point
similar to this.
But even if we imagine CC BY is being applied to software (or the
commercial licensor can't easily avoid retention of all the CC BY
nonsoftware stuff, though that seems unlikely): the only possibly
problematic scenario seems to be the one you've raised, namely, the
*existing* commercial license that failed to account for the possible
(present or later) inclusion of third-party components under licenses
having the feature you are saying exists in CC BY. While revising the
commercial license is trivial, renegotiating deals with customers may
very well not be.
But I'm not sure why that's the only way to ensure adequate compliance
with CC BY, particularly for the typical CC BY licensor. They chose a
license that broadly speaking allowed for proprietary derivative
works. They deliberately did not choose CC BY-SA, or the CC BY-NC.
They just want it to be clear to your customers that, regardless of
what the commercial license says, the original stuff under CC BY isn't
being subjected to additional restrictions. Seems to me there are
various ways in which one could make that clear without having to
revise the commercial license.
> Does it seem to you that we are going around in circles?
Probably to some degree. :) Apologies to legal-discuss.
- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/08/2013 09:25:13 PM:
> Jeff Thomson wrote:
> > Most commercial software licenses prohibit
> > modification and redistribution.
> But they can't prohibit the modification and redistribution of the
> FOSS bits within it.
If what you mean is that the commercial software vendor wouldn't be able to
enforce the prohibition by a copyright suit, yes, I agree 100%. B isn't
the owner of the copyright and absent an exclusive license to that code,
can't enforce any of the exclusive rights. Only A can effectively assert
copyright to that code.
> And they must disclose the presence of the FOSS
> bits and inform customers of its licenses.
Yep.
> Other than that, you can refuse to support or service modified
> software, and you can refuse to accept responsibility for
> redistributed software, and you can refuse to allow the
> redistribution of your private bits. Nobody is preventing you from
> reaching reasonable commercial terms with your customers.
Yep.
>
> > Does it seem to you that we are going around in circles?
> Yes. Please stop rotating....
:-)
So, are we done, at least as far as the practical results of AL2.0 goes?
If A licenses code to B under AL2.0, it seems like you agree that B can
license a combined work to C under a proprietary license that includes, for
example, a general prohibition on modification. I think we also agree
that, at least as to A's code, if C goes ahead and modifies it, B can't sue
under the copyright act to stop it because only A can do that. As you
point out, there may be other repercussions on the relationship between B &
C.
The problem that I had from the beginning though, is that I don't think we
can have the same progression with CC-BY material since CC-BY says that you
can't include any terms that purport to prevent the exercise of any of the
CC-BY rights (e.g., modification). So, B can't license the combined work
to C under a proprietary license that includes a general prohibition on
modification.
So, I'm back to the original problem. If an Apache project includes CC-BY
material, the consumer of that code has to treat it specially. Either it
has to remove the CC-BY material or it has to change its commercial license
terms.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff Thomson wrote:
> Most commercial software licenses prohibit
> modification and redistribution.
But they can't prohibit the modification and redistribution of the FOSS bits
within it. And they must disclose the presence of the FOSS bits and inform
customers of its licenses.
Other than that, you can refuse to support or service modified software, and
you can refuse to accept responsibility for redistributed software, and you
can refuse to allow the redistribution of your private bits. Nobody is
preventing you from reaching reasonable commercial terms with your
customers.
> Does it seem to you that we are going around in circles?
Yes. Please stop rotating....
/Larry
From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
Sent: Sunday, December 08, 2013 5:47 PM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
Richard Fontana <rf...@redhat.com> wrote on 12/07/2013 05:45:03 PM:
> On Sat, Dec 07, 2013 at 03:02:46PM -0500, Jeffrey Thompson wrote:
>
> [...]
> > You've made tremendously great leaps of reasoning here, especiallysince
your
> > conclusion directly contradicts the license author's stated policy
> of creating
> > a license that permits commercial licensing of the code.
>
> The meaning of 'permits commercial licensing of the code' is not clear
> to me.
Most commercial software licenses prohibit modification and redistribution.
CC-BY requires, as I read the language, that you distribute the CC-BY
content under terms with authorize modification and redistribution.
To me, that means that the CC-BY license is not compatible with commercial
software licenses, since its very likely that you can't take CC-BY licensed
software and distribute it under your existing commercial software license.
Does it seem to you that we are going around in circles?
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/07/2013 05:45:03 PM:
> On Sat, Dec 07, 2013 at 03:02:46PM -0500, Jeffrey Thompson wrote:
>
> [...]
> > You've made tremendously great leaps of reasoning here, especiallysince
your
> > conclusion directly contradicts the license author's stated policy
> of creating
> > a license that permits commercial licensing of the code.
>
> The meaning of 'permits commercial licensing of the code' is not clear
> to me.
Most commercial software licenses prohibit modification and redistribution.
CC-BY requires, as I read the language, that you distribute the CC-BY
content under terms with authorize modification and redistribution.
To me, that means that the CC-BY license is not compatible with commercial
software licenses, since its very likely that you can't take CC-BY licensed
software and distribute it under your existing commercial software license.
Does it seem to you that we are going around in circles?
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Sat, Dec 07, 2013 at 03:02:46PM -0500, Jeffrey Thompson wrote:
[...]
> You've made tremendously great leaps of reasoning here, especially since your
> conclusion directly contradicts the license author's stated policy of creating
> a license that permits commercial licensing of the code.
The meaning of 'permits commercial licensing of the code' is not clear
to me. If we return to CC BY, you seemed to be saying that what made
CC BY 'commercially unfriendly' -- which I assume is related to this
concept of 'permitting commercial licensing' -- is that later
inclusion of CC BY material might be in conflict with an earlier
product license that was drafted on the assumption that the product
could never possibly include CC BY material. What made CC BY
'commercially unfriendly', therefore, was that it violated a
downstream license nonrevisability principle.
It seemed from what you were saying that if CC BY icons are included
in a product at the outset, and the product license is drafted in
whatever way is thought necessary to comply with CC BY, then there
could be no argument of commercial unfriendliness in that case. Thus
in general CC BY is not 'commercially unfriendly' -- it's only
unfriendly in those cases where there's a license in place prior to
inclusion (or awareness of inclusion) of the CC BY material.
The 'downstream license nonrevisability principle' had never occurred
to me as something that might be thought key to what 'permitting
commercial licensing' ought to mean. I have to be skeptical about
whether the ALv2 authors had this nonrevisability principle in mind
when ALv2 was being drafted. I believe they wanted to allow
proprietary derivative works of ALv2 material in the same way that
Creative Commons wants to allow proprietary derivative works of CC BY
material.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Jim Jagielski <ji...@jaguNET.com> wrote on 12/08/2013 07:06:53 PM:
> On Dec 7, 2013, at 3:02 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> >
> > You're explicitly contradicting yourself. AL2.0 expressly says
> one can license "the Derivative Work as a whole" under their own
> terms, not "the Derivative Work as a collection under your own terms
> with the Work being licensed under AL2.0".
> >
>
> The intent though is that people should know that inside that larger
work
> is some ALv2 licensed code that, no matter what the license of
> the larger work as a whole is under, and that they can have access to it
> (the bits) and such access is under ALv2.
Yes, though I'd prefer to say it more precisely -- B (the distributor) has
to inform C (the recipient) that it received the AL2.0 code under the
AL2.0, provide the recipient a copy of the AL2.0 so that it knows what
those rights are, and retain all copyright and proprietary notices so that
C knows that the code came from A (the author). If A's offer is made
available to C, for example if its a public offer on an OSS website, C can
certainly take advantage of those rights if it chooses to do so.
None of that means that the transaction beween B and C includes the AL2.0
license terms, which is what Richard is saying.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 7, 2013, at 3:02 PM, Jeffrey Thompson <jt...@us.ibm.com> wrote:
>
> You're explicitly contradicting yourself. AL2.0 expressly says one can license "the Derivative Work as a whole" under their own terms, not "the Derivative Work as a collection under your own terms with the Work being licensed under AL2.0".
>
The intent though is that people should know that inside that larger work
is some ALv2 licensed code that, no matter what the license of
the larger work as a whole is under, and that they can have access to it
(the bits) and such access is under ALv2.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/07/2013 01:48:29 AM:
> Correct, but it must also be acknowledged that ALv2 does not say "You
> *may* offer terms that restrict exercise of the rights under this
> License by any recipient *as to the Work*".
Right, it doesn't. As I explained, it doesn't need to. There is no
generally applicable copyright licensing rule that says you can't pass on
fewer rights. You try to make a case below that the Apache license
contains language from which you can infer an intent to impose that
restriction. That's fair. If the license imposes the restriction, then it
does. But, if the license does not, then the restriction does not exist.
> This is significant because ALv2 is not entirely silent on the
> issue. It says that recipients of the Work or Derivative Works must be
> given a copy of ALv2. Why? The answer is surely not attribution, which
> is handled by other provisions. Life would be simpler for everyone if
> there were no requirement to include the upstream license text, if it
> really is meant to serve no purpose.
It seems obvious that it serves the purpose of informing the recipient that
the code is also available under the AL2.0 license.
>
> And again the key statement is this, in section 4:
>
> You may add Your own copyright statement to Your modifications and
> may provide additional or different license terms and conditions for
> use, reproduction, or distribution of Your modifications, or for any
> such Derivative Works as a whole, provided Your use, reproduction,
> and distribution of the Work otherwise complies with the conditions
> stated in this License.
>
> I suppose one interesting thing is the fact that this sentence is in
> the license at all;
I agree that its technically unnecessary and likely was included to make
sure that certain GPL interpretations weren't imposed on this license.
> And then this sentence contains a condition: "provided Your use [etc.]
> of *the Work* otherwise complies with the conditions stated in this
> License". This sentence is drawing a distinction between
> "modifications to the Work" and "such Derivative Works as a whole", on
> the one hand, and "the Work", the originally-licensed thing, on the
> other.
Yes, because it wants to make the point that, notwithstanding the fact that
you might be licensing your product under the AL2.0, you (as the creator of
the derivative work) must comply with your obligations (e.g., section 4) as
to the code you received (e.g., the Work). What's confusing about that?
It doesn't say that the AL2.0 terms must be used when you license the Work
as part of your Product. If Apache wanted to do that, there were very
clear ways to say it.
> The Work continues to exist, and the conditions of ALv2
> continue to apply to it. The licensee's downstream recipient is
> getting the Work (as part of some Derivative Work, perhaps) along with
> a copy of the ALv2 text. In trying to make sense of this whole
> sentence, I must conclude that it embodies the view that the portions
> of the 'Derivative Work as a whole' that are 'the Work' remain
> governed solely by ALv2, and cannot be supplemented by more
> restrictive terms. The ultimate end user is getting an ALv2 license
> for the Work, and that is why ALv2 requires Derivative Works to
> include copies of ALv2, since otherwise it would be completely
> pointless.
You're explicitly contradicting yourself. AL2.0 expressly says one can
license "the Derivative Work as a whole" under their own terms, not "the
Derivative Work as a collection under your own terms with the Work being
licensed under AL2.0".
You've made tremendously great leaps of reasoning here, especially since
your conclusion directly contradicts the license author's stated policy of
creating a license that permits commercial licensing of the code.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby wrote:
> ... it is the case that both the Mozilla foundation and the FSF
> have deemed that CC-BY is incompatible with their licenses
With respect to FSF, I just received the following note from Eben Moglen:
FSF has made no statements concerning any of the CC 4.0 licenses. FSF and its legal advisers have been in productive conversation with CC throughout the license development and discussion process. FSF will make any statements concerning the CC licenses in the same format that it employs with respect to other licenses, when it has completed its review of the final versions just released, and to be released.
I'll report any responses I receive about the Mozilla Foundation opinion, or perhaps one of the Mozilla attorneys on this list will respond directly.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Saturday, December 07, 2013 2:24 AM
To: Legal Discuss
Subject: Re: New versions of CC licenses
<snip>
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Dec 7, 2013 at 1:48 AM, Richard Fontana <rf...@redhat.com> wrote:
> So if there is a reason to keep CC BY 4.0 (or, retroactively, earlier
> versions of CC BY) out of 'Category A', it should not be for this
> reason.
>
Clearly you and Jeff differ over this. Fair enough.
But during the course of this discussion, we have established that there
are some licenses that are less restrictive than the Apache License. And
some that are more restrictive. And that while the ASF welcomes
contributions back, it doesn't require them. In fact, we welcome people to
create derivative works and distribute those works under different
(specifically: more restrictive) terms. Furthermore, absolutely nobody has
taken the position that should this be done that it in any way affects the
ability of others to obtain and use the original (unenhanced) version.
To facilitate the creation of such derivative works, the ASF makes an
attempt to avoid including works that are provided under licenses that are
more restrictive than the ASF's own license.
CC-By appears to be such a license. Whether or not you agree with Jeff, it
is the case that both the Mozilla foundation and the FSF have deemed that
CC-BY is incompatible with their licenses. Producing software that is
consumable by people that use the latest versions of those licenses is an
explicit goal of the ASF.
Further reading:
https://issues.apache.org/jira/browse/LEGAL-167
I would suggest that we go ahead and resolve that JIRA at this time.
- Sam Ruby
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Fri, Dec 06, 2013 at 04:27:42PM -0500, Jeffrey Thompson wrote:
> "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/06/2013 03:55:46 PM:
>
> > IBM can satisfy the Apache License easily by honoring the
> > redistribution conditions in AL section 4. IBM can satisfy the CC-BY
> > license in almost exactly the same way.
>
> Larry,
> I don't see anything in AL section 4, that says "You may not offer ... terms
> [that] restrict[] exercise of the License Rights by any recipient...".
Correct, but it must also be acknowledged that ALv2 does not say "You
*may* offer terms that restrict exercise of the rights under this
License by any recipient *as to the Work*".
This is significant because ALv2 is not entirely silent on the
issue. It says that recipients of the Work or Derivative Works must be
given a copy of ALv2. Why? The answer is surely not attribution, which
is handled by other provisions. Life would be simpler for everyone if
there were no requirement to include the upstream license text, if it
really is meant to serve no purpose.
And again the key statement is this, in section 4:
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions for
use, reproduction, or distribution of Your modifications, or for any
such Derivative Works as a whole, provided Your use, reproduction,
and distribution of the Work otherwise complies with the conditions
stated in this License.
I suppose one interesting thing is the fact that this sentence is in
the license at all; it says what I think we'd all assume would be true
if the sentence were absent. I am not familiar with the drafting
history of ALv2 but my guess is that this sentence, like the
definition given for 'Derivative Work', is a reference to the history
of interpretation of the GPL, then certainly the most dominant and
influential open source license. This is a sentence that is making
clear that ALv2 is *not* adopting the kind of copyleft policy that was
associated with certain prevailing interpretations of the GPL by 2004.
In any case, the inclusion of the sentence is helpful. It does clearly
say that "modifications" can be under "additional or different license
terms"; it then says that "such Derivative Works as a whole" (the
meaning of which is unclear, but seems to me to contain an echo of
GPLv2 section 2) can be under "additional or different license
terms".
But it is important to note that this very detailed sentence fails to
say that "You may provide additional or different license terms and
conditions for use, reproduction, or distribution of the Work
itself". Why did the drafters of ALv2 go to the trouble of writing
this lengthy sentence, and *omit* the granting of permission to use
"additional or different license terms" for the Work, if they intended
it not only to be allowed but to be a common use case?
And then this sentence contains a condition: "provided Your use [etc.]
of *the Work* otherwise complies with the conditions stated in this
License". This sentence is drawing a distinction between
"modifications to the Work" and "such Derivative Works as a whole", on
the one hand, and "the Work", the originally-licensed thing, on the
other. The Work continues to exist, and the conditions of ALv2
continue to apply to it. The licensee's downstream recipient is
getting the Work (as part of some Derivative Work, perhaps) along with
a copy of the ALv2 text. In trying to make sense of this whole
sentence, I must conclude that it embodies the view that the portions
of the 'Derivative Work as a whole' that are 'the Work' remain
governed solely by ALv2, and cannot be supplemented by more
restrictive terms. The ultimate end user is getting an ALv2 license
for the Work, and that is why ALv2 requires Derivative Works to
include copies of ALv2, since otherwise it would be completely
pointless.
All this is what CC BY is saying as well, the difference being that CC
BY is clearer (and far more verbose). The concept is the same. You can
make derivative works over which you have a copyright interest. You
can license the derivative work under a more restrictive license. But
you have no permission to license the original material under a more
restrictive license.
So if there is a reason to keep CC BY 4.0 (or, retroactively, earlier
versions of CC BY) out of 'Category A', it should not be for this
reason.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/05/2013 03:53:45 PM:
> Ultimately the problem is that the old license was not drafted well by
> not accounting for the possibility that there might be some
> third-party component under a license that has to be passed through to
> the customer, an extremely common occurrence in commercial
> software. Most of the stock commercial software licenses I see these
> days have some formulaic clause that refers to this possibility.
Yes, its a stock clause that I see often, as well. Its also a stock clause
that large software procurement organizations are very familiar with and
for any sufficiently large procurement deal its a stock clause that is
redlined out on the first draft.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 08:49:56AM -0800, Lawrence Rosen wrote:
> 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?
Assuming Jeffrey's interpretation of CC BY and the Apache License 2.0
is correct, the argument seems to be that "commercially friendly"
means "downstream commercial entity never has to adjust its license in
any way no matter what happens". I am not entirely unsympathetic to
this because I know from experience at Red Hat that updating older
global product licenses is a big pain and can be impractical.
Nevertheless if there is some argument that an old commercial license
has become problematic because it didn't account for the possibility
that one day CC BY *icons* might be included in a later version of the
product ... I'm not so sympathetic to that. It's not a fatal flaw -
the customer is going to get a product that will make clear that the
icons are covered by CC BY. The vendor can add a notice in the
directory where the icons appear that CC BY, as to those icons,
supersedes the old product license. There must be many practical
solutions to this issue that will be acceptable to the CC BY licensor
as well as to the vendor.
Ultimately the problem is that the old license was not drafted well by
not accounting for the possibility that there might be some
third-party component under a license that has to be passed through to
the customer, an extremely common occurrence in commercial
software. Most of the stock commercial software licenses I see these
days have some formulaic clause that refers to this possibility.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby quoted from a blog post:
> To drive the point home: there is a one-way compatibility between the Apache License, Version 2, and [L]GPLv3, in that one can take code under ALv2, create a derivative work, and distribute that work under the terms of [L]GPLv3. The reverse is not true.
In Apache's typical projects where CC-BY might be relevant, we're not creating what anyone would call a "derivative work" of the CC-BY work. (Even if we did create such a derivative work of the CC-BY work, that is also allowed without infecting any other work!) And so the above naive statement about "one-way compatibility" (which is naive because it overstates the reverse situation) has nothing whatsoever to do with the inclusion of (e.g.) a CC-BY icon in an Apache project.
As I read our Apache License 2.0 and CC-BY 4.0, absolutely nothing would prevent IBM or LibreOffice or anyone else from combining such Apache software into their commercial or FOSS products. As you point out, this "is intentional and by design." OTOH, absolutely nothing would absolve them from responsibility to comply with the terms of Apache License 2.0, namely: "You must give any other recipients of the Work or Derivative Works a copy of this License; and...." And when they read in our NOTICE file that we have included a CC-BY contribution (which satisfies the CC-BY notice requirements, by the way), they can decide for themselves if that is compatible with their own outbound licenses.
/Larry
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Saturday, December 07, 2013 9:21 AM
To: Legal Discuss; Lawrence Rosen
Subject: Re: New versions of CC licenses
On Sat, Dec 7, 2013 at 11:41 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
Sam, thanks for finding that blog post [1]. Here's the final sentence of that post:
For the advantage of all users, I encourage everyone interested in working on the OpenOffice codebase to draw his own conclusions. Mine are clear; help us at Apache or be so kind to release it on Apache, too. That's the way to reach the broadest possible user base for your feature. A lot of users will thank you for it :-)
I am delighted to read this. The notion that our contributors would also want to cooperate with other non-Apache projects by contributing to both is one of the blessings of the open source development paradigm. And because /that contributor/ gave /his contribution/ to /both/ Apache and LibreOffice, there is no license incompatibility for us or LibreOffice to worry about. This situation is simple to analyze and has nothing to do with the issue we're now debating.
An excerpt from the blog post showing the relevance to this discussion:
It shows the flow of source between Apache OpenOffice and projects based on the general OpenOffice codebase thanks to the permissive Apache 2 License (ALv2 <http://www.apache.org/licenses/LICENSE-2.0.html> ). I added my stuff to Apache with the goal to get it into all OpenOffice derivatives, and that's exactly what ALv2 allows, as this example shows.
To drive the point home: there is a one-way compatibility between the Apache License, Version 2, and [L]GPLv3, in that one can take code under ALv2, create a derivative work, and distribute that work under the terms of [L]GPLv3. The reverse is not true.
The GPL set of licenses are in no way unique in this regard. The same thing is true for the latest version of the Mozilla public license. And for a number of proprietary licenses.
My point is that this isn't considered unfortunate by the Apache Software Foundation, it is intentional and by design.
And the third party licensing policy is a part of that. Originally developed by Cliff, it categories licenses based on their affect on the ability of our licensees to make use of our work.
Note also that this blog post isn't an official Apache announcement that our Apache License can be ignored by LibreOffice.
I beg you, please stop the use of straw mans. Absolutely nobody has suggested that.
The point is that it is quite possible for third parties to comply with the terms of our license and distribute the results under different terms, and that the Apache Software Foundation is entirely OK with that.
- Sam Ruby
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Dec 7, 2013 at 11:41 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Sam, thanks for finding that blog post [1]. Here's the final sentence of
> that post:
>
>
>
> For the advantage of all users, I encourage everyone interested in working
> on the OpenOffice codebase to draw his own conclusions. Mine are clear;
> help us at Apache or be so kind to release it on Apache, too. That's the
> way to reach the broadest possible user base for your feature. A lot of
> users will thank you for it :-)
>
>
>
> I am delighted to read this. The notion that our contributors would also
> want to cooperate with other non-Apache projects by contributing to both is
> one of the blessings of the open source development paradigm. And because
> /that contributor/ gave /his contribution/ to /both/ Apache and
> LibreOffice, there is no license incompatibility for us or LibreOffice to
> worry about. This situation is simple to analyze and has nothing to do with
> the issue we're now debating.
>
>
An excerpt from the blog post showing the relevance to this discussion:
It shows the flow of source between Apache OpenOffice and projects based on
the general OpenOffice codebase thanks to the permissive Apache 2 License (
ALv2 <http://www.apache.org/licenses/LICENSE-2.0.html>). I added my stuff
to Apache with the goal to get it into all OpenOffice derivatives, and
that's exactly what ALv2 allows, as this example shows.
To drive the point home: there is a one-way compatibility between the
Apache License, Version 2, and [L]GPLv3, in that one can take code under
ALv2, create a derivative work, and distribute that work under the terms of
[L]GPLv3. The reverse is not true.
The GPL set of licenses are in no way unique in this regard. The same
thing is true for the latest version of the Mozilla public license. And
for a number of proprietary licenses.
My point is that this isn't considered unfortunate by the Apache Software
Foundation, it is intentional and by design.
And the third party licensing policy is a part of that. Originally
developed by Cliff, it categories licenses based on their affect on the
ability of our licensees to make use of our work.
> Note also that this blog post isn't an official Apache announcement that
> our Apache License can be ignored by LibreOffice.
>
I beg you, please stop the use of straw mans. Absolutely nobody has
suggested that.
The point is that it is quite possible for third parties to comply with the
terms of our license and distribute the results under different terms, and
that the Apache Software Foundation is entirely OK with that.
- Sam Ruby
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam, thanks for finding that blog post [1]. Here's the final sentence of that post:
For the advantage of all users, I encourage everyone interested in working on the OpenOffice codebase to draw his own conclusions. Mine are clear; help us at Apache or be so kind to release it on Apache, too. That's the way to reach the broadest possible user base for your feature. A lot of users will thank you for it :-)
I am delighted to read this. The notion that our contributors would also want to cooperate with other non-Apache projects by contributing to both is one of the blessings of the open source development paradigm. And because /that contributor/ gave /his contribution/ to /both/ Apache and LibreOffice, there is no license incompatibility for us or LibreOffice to worry about. This situation is simple to analyze and has nothing to do with the issue we're now debating.
Note also that this blog post isn't an official Apache announcement that our Apache License can be ignored by LibreOffice. The comments on that blog post ["Great work" and "this is cool"] have no relationship to Apache Foundation policy or licensing requirements.
/Larry
[1] https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Saturday, December 07, 2013 8:26 AM
To: Legal Discuss; Lawrence Rosen
Subject: Re: New versions of CC licenses
On Sat, Dec 7, 2013 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
Sam Ruby wrote:
> I'm having trouble reconciling this with what the LibreOffice
> community does (with our blessing!). Note that there are no
> mentions at all of Apache on either of the following pages:
Why would we have blessed that? Our license explicitly requires of everyone: "You must give any other recipients of the Work or Derivative Works a copy of this License; and...." This is not so onerous that LibreOffice can ignore it.
Apache gives licenses, not blessings.
I may have been loose with my words, but the ASF OpenOffice project publicly posted that they were happy about this occurring, and why:
https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating
/Larry
- Sam Ruby
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Dec 7, 2013 at 11:05 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Sam Ruby wrote:
>
> > I'm having trouble reconciling this with what the LibreOffice
>
> > community does (with our blessing!). Note that there are no
>
> > mentions at all of Apache on either of the following pages:
>
> Why would we have blessed that? Our license explicitly requires of
> everyone: "You must give any other recipients of the Work or Derivative
> Works a copy of this License; and...." This is not so onerous that
> LibreOffice can ignore it.
>
>
>
> Apache gives licenses, not blessings.
>
>
I may have been loose with my words, but the ASF OpenOffice project
publicly posted that they were happy about this occurring, and why:
https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating
> /Larry
>
- Sam Ruby
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby wrote:
> I'm having trouble reconciling this with what the LibreOffice
> community does (with our blessing!). Note that there are no
> mentions at all of Apache on either of the following pages:
Why would we have blessed that? Our license explicitly requires of everyone: "You must give any other recipients of the Work or Derivative Works a copy of this License; and...." This is not so onerous that LibreOffice can ignore it.
Apache gives licenses, not blessings.
/Larry
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Friday, December 06, 2013 5:35 PM
To: Legal Discuss
Subject: Re: New versions of CC licenses
On Fri, Dec 6, 2013 at 4:39 PM, Richard Fontana <rf...@redhat.com> wrote:
On Fri, Dec 06, 2013 at 04:10:23PM -0500, Jeffrey Thompson wrote:
> In my hypo from a few notes ago, A distributes software to B under AL2.0. B
> combines it with GPL code and distributes the result to C under the GPL. As
> far as C is concerned, the GPL is the only license it needs to read in order to
> understand what rights it gets from B, even for A's code. AL2.0 is in the
> notices file and C can review that if it wants to, but if there ever is a
> dispute between B and C, the license of record, the terms that get submitted to
> the court for interpretation, is the GPL, right?
Maybe, maybe not, depending on what the dispute is about. "The only
license it needs to read" is not correct. C needs to read the Apache
License 2.0 to understand fully the rights it is getting and the
requirements or obligations it has to upstream licensors.
The Apache License does not *vanish*.
I'm having trouble reconciling this with what the LibreOffice community does (with our blessing!). Note that there are no mentions at all of Apache on either of the following pages:
http://www.libreoffice.org/download/license/
http://www.libreoffice.org/about-us/faq/licensing-faq/
That project certainly gives the strong impression that LGPL2 (and MPL) are "the only license it needs to read"... for licensees of that project.
- Sam Ruby
Re: New versions of CC licenses
Posted by Engel Nyst <en...@gmail.com>.
On 12/07/2013 03:34 AM, Sam Ruby wrote:
> On Fri, Dec 6, 2013 at 4:39 PM, Richard Fontana <rf...@redhat.com> wrote:
>
>> On Fri, Dec 06, 2013 at 04:10:23PM -0500, Jeffrey Thompson wrote:
>>> In my hypo from a few notes ago, A distributes software to B under
>>> AL2.0. B combines it with GPL code and distributes the result to C under
>>> the GPL. As far as C is concerned, the GPL is the only license it needs
>>> to read in order to understand what rights it gets from B, even for A's
>>> code. AL2.0 is in the notices file and C can review that if it wants to,
>>> but if there ever is a dispute between B and C, the license of record,
>>> the terms that get submitted to the court for interpretation, is the GPL,
>>> right?
>> Maybe, maybe not, depending on what the dispute is about. "The only
>> license it needs to read" is not correct. C needs to read the Apache
>> License 2.0 to understand fully the rights it is getting and the
>> requirements or obligations it has to upstream licensors.
>>
>> The Apache License does not *vanish*.
>>
>
> I'm having trouble reconciling this with what the LibreOffice community
> does (with our blessing!). Note that there are no mentions at all of
> Apache on either of the following pages:
>
> http://www.libreoffice.org/download/license/
> http://www.libreoffice.org/about-us/faq/licensing-faq/
>
> That project certainly gives the strong impression that LGPL2 (and MPL) are
> "the only license it needs to read"... for licensees of that project.
>
If I choose a random package from LibreOffice, libreoffice-base, and I
look at Debian's "Copyright" file for it, I see:
http://ftp-master.metadata.debian.org/changelogs/main/libr/libreoffice/libreoffice_3.5.4+dfsg2-0+deb7u2_copyright
I see inside AL2.0, for example for Apache Lucene package:
> Files: ext-sources/*lucene*
> Copyright: Copyright 2004 The Apache Software Foundation
> Copyright: Copyright 2005 The Apache Software Foundation
> Copyright: Copyright 2007 The Apache Software Foundation
> License: Apache-2.0
I also see SPL1.0, BSD 3 and 4 clause, W3C, a modified BSD 4-clause, and
even GPLv1 and GPLv2.
I chose to look at Debian because I trust Debian to find immediately
reliable information on the package licensing.
If I wanted to take and modify Apache Lucene, I might be able to do so
from here, under AL 2.0. I'd make more checks in this case for various
reasons (i.e. what exactly the package contains, is it complete and
unmodified), but for a first sight, it doesn't look to me like AL 2.0 is
not AL 2.0 for it.
Also, I would not and could not conclude from these pages, that GPL v1
and GPL v2 were *erased*, and replaced with LGPL v3 or MPL 1.1. :)
--
~enyst
"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so
that we have legally your permission to distribute your CC-licensed words?"
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Dec 6, 2013 at 4:39 PM, Richard Fontana <rf...@redhat.com> wrote:
> On Fri, Dec 06, 2013 at 04:10:23PM -0500, Jeffrey Thompson wrote:
> > In my hypo from a few notes ago, A distributes software to B under
> AL2.0. B
> > combines it with GPL code and distributes the result to C under the GPL.
> As
> > far as C is concerned, the GPL is the only license it needs to read in
> order to
> > understand what rights it gets from B, even for A's code. AL2.0 is in
> the
> > notices file and C can review that if it wants to, but if there ever is a
> > dispute between B and C, the license of record, the terms that get
> submitted to
> > the court for interpretation, is the GPL, right?
>
> Maybe, maybe not, depending on what the dispute is about. "The only
> license it needs to read" is not correct. C needs to read the Apache
> License 2.0 to understand fully the rights it is getting and the
> requirements or obligations it has to upstream licensors.
>
> The Apache License does not *vanish*.
>
I'm having trouble reconciling this with what the LibreOffice community
does (with our blessing!). Note that there are no mentions at all of
Apache on either of the following pages:
http://www.libreoffice.org/download/license/
http://www.libreoffice.org/about-us/faq/licensing-faq/
That project certainly gives the strong impression that LGPL2 (and MPL) are
"the only license it needs to read"... for licensees of that project.
- Sam Ruby
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Fri, Dec 06, 2013 at 04:10:23PM -0500, Jeffrey Thompson wrote:
> In my hypo from a few notes ago, A distributes software to B under AL2.0. B
> combines it with GPL code and distributes the result to C under the GPL. As
> far as C is concerned, the GPL is the only license it needs to read in order to
> understand what rights it gets from B, even for A's code. AL2.0 is in the
> notices file and C can review that if it wants to, but if there ever is a
> dispute between B and C, the license of record, the terms that get submitted to
> the court for interpretation, is the GPL, right?
Maybe, maybe not, depending on what the dispute is about. "The only
license it needs to read" is not correct. C needs to read the Apache
License 2.0 to understand fully the rights it is getting and the
requirements or obligations it has to upstream licensors.
The Apache License does not *vanish*.
Why does the Apache License 2.0 require inclusion of the license text,
after all? It could easily have said that distributors are free to
delete the ALv2 license file. The Artistic License 2.0, as I recall,
allows this, by design.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
Sorry, the "You keep asserting this but" isn't directly relevant to
the quoted part of what you said. :)
I agree that some open source projects choose licenses that permit
code to be distributed under other terms (in a narrow, strict sense)
but I am saying this is not obviously true of the Apache License 2.0.
On Thu, Dec 05, 2013 at 04:30:47PM -0500, Richard Fontana wrote:
> On Thu, Dec 05, 2013 at 10:15:25AM -0500, Jeffrey Thompson wrote:
>
> > 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).
> [...]
> > 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).
>
> You keep asserting this but I do not think you are correct. The
> general rule in the US, though it is a state law issue, is that you
> need explicit permission to pass on a proper subset of rights received
> as to the original material. CC BY clearly denies this permission. I
> think the Apache License 2.0 is best read as denying this right, and
> that view is consistent with what I've heard some ASF people say on
> this list (for example, in one of the AOO vs. LibreOffice threads that
> came up a year or so ago).
>
> - Richard
>
>
> ---------------------------------------------------------------------
> 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
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/05/2013 04:30:47 PM:
> From: Richard Fontana <rf...@redhat.com>
> To: legal-discuss@apache.org,
> Date: 12/05/2013 04:31 PM
> Subject: Re: New versions of CC licenses
>
> On Thu, Dec 05, 2013 at 10:15:25AM -0500, Jeffrey Thompson wrote:
>
> > CC-BY is not commercially friendly. It states that the commercialuser
MUST
> > pass on all rights and cannot prohibited modification or
> distribution (at least
> > as to those components).
> [...]
> > 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).
>
> You keep asserting this but I do not think you are correct. The
> general rule in the US, though it is a state law issue, is that you
> need explicit permission to pass on a proper subset of rights received
> as to the original material.
Ahhhhhhh!
Sigh.
Copyright is U.S. federal law, not state law.
Your belief is interesting, but unsupported by actual legal principles.
See my prior note.
Sorry, but I have to go get my day job done.
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Fri, Dec 06, 2013 at 09:47:36AM -0500, Sam Ruby wrote:
> My understanding is that the MPL version 4
(assume you mean 2 :)
> and the GPL version 3 are more
> restrictive than the Apache License, Version 2.
That's probably close enough to being true that I'm comfortable with
saying it's true.
> My understanding is that the Apache License, Version 2 is widely considered to
> be "compatible" with both licenses, in the sense that Apache code may be
> incorporated into products that are released under the Mozilla and GPL
> licenses.
>
> Is my understanding wrong?
No ...
One parenthetical note - I am not sure you're right about the "widely
considered" part. I sometimes use phrases like that myself, when
speaking of similar things. But the reality is that the issue is
esoteric. The small number of people who care about things like this
tend to be satisfied that the drafters/stewards of GPLv3 and MPLv2 say
that ALv2 is compatible with those licenses and seem to mean some
notion of incorporability under the umbrella of the apparently more
restrictive license.
But leaving that aside, what "incorporated in" and "released under"
actually mean -- what's actually going on legally -- seems to really
be what is being disputed here. The meaning of the concepts may be
less clear or more debatable than you might be assuming. I am not even
sure I know what you mean when you use the word 'product'. And some of
this seems to go beyond what's purely legal and into commercial (and
open source community) custom.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/06/2013 03:55:46 PM:
> IBM can satisfy the Apache License easily by honoring the
> redistribution conditions in AL section 4. IBM can satisfy the CC-BY
> license in almost exactly the same way.
Larry,
I don't see anything in AL section 4, that says "You may not offer ...
terms [that] restrict[] exercise of the License Rights by any
recipient...". That's in CC-BY 4.0. Are you saying that it doesn't
actually mean what I think it means? If I'm wrong, then great. Is there a
place on the CC-BY website that explains that?
Jeff
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff,
The Apache License granted by ASF to its software is to everyone, not just
IBM. The CC-BY license is to everyone, not just IBM. You seem to be focused
on sublicensing but I don't understand the relevance to our discussion. Your
commercial sublicenses are your own concern, and I'm certain you add lots of
commercial terms to those sublicenses that we at Apache don't care about.
IBM can satisfy the Apache License easily by honoring the redistribution
conditions in AL section 4. IBM can satisfy the CC-BY license in almost
exactly the same way. Nothing in either license allows you to hide from your
customers the fact that you are distributing the Apache and CC-BY works to
them. [1] The only difference is that the CC-BY licensor can require you to
/remove/ her attribution notice. You can easily satisfy these simple
obligations on behalf of your commercial customers, or omit the CC-BY
components altogether.
Regarding the TPM requirement of CC-BY: As I described, you are not hiding
the Apache and CC-BY software presence in your commercial products. Even if
you use TPM in your products to protect the versions that you distribute,
your website can easily refer people to Apache for the original source!
/Larry
[1] Apache License section 4(a): "You must give any other recipients of the
Work or Derivative Works a copy of this License; and...."
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Friday, December 06, 2013 11:31 AM
To: legal-discuss@apache.org
Subject: Re: New versions of CC licenses
Jim Jagielski <ji...@jaguNET.com> wrote on 12/06/2013 06:33:05 AM:
>
> On Dec 5, 2013, at 4:30 PM, Richard Fontana <rf...@redhat.com> wrote:
> >
> > You keep asserting this but I do not think you are correct. The
> > general rule in the US, though it is a state law issue, is that you
> > need explicit permission to pass on a proper subset of rights received
> > as to the original material.
. . .
> +1
>
The fact that Richard doesn't think I'm correct, notwithstanding, his
statement of the law is incorrect. You do not need explicit permission to
pass on a subset of rights. The reason why derives from the basic structure
of copyright itself. Unfortunately, this will take a couple of minutes. I
hope no one is too bored.
Copyright is a government granted monopoly on the right to perform certain
actions with respect to creative works. US Copyright law provides six basic
exclusive rights: reproduction, modification, distribution, public
performance, public display, and digital audio transmission (ignoring moral
rights which are somewhat supported in US Law and the quasi-right of access
created by the DMCA).
If you're not performing one of those actions or even if you are, but you
fall within one of the statutory exceptions (such as fair use, library
rights, etc.), you do not need permission from the copyright owner to do
what you are doing. So, reading a book? Great. No copyright right needed.
"Reading" isn't a granted exclusive right.
The structure of the legal regime is that you're allowed to do anything you
want, unless you infringe one of the exclusive rights granted by Title 17 of
the US Code.
If you want to take advantage of one of the exclusive rights, you need
permission. If you're granted permission, the scope of that permission
controls what you are allowed or not allowed to do. If I have permission to
make 1 copy of a book, that's what I get to do -- make 1 copy of the book.
If the permission doesn't say anything about how I have to make the copy,
when I can make the copy, or any other details, the restrictions do not
exist. Only that which is specified in the permission grant (i.e., license)
applies. Of course, ambiguities need to be resolved when they are present,
but generally, if there are no restrictions, none are implied.
So, if I enter into a license agreement with a publisher of a book to be
able to print and distribute up to 50 physical copies of that work (invoking
2 exclusive rights, the right of reproduction and the right of
distribution), I'm good as long as I say within the 4 corners of that
license agreement. There might be region limitations in the distribution
right grant. If there are, I can only offer those copies for sale within
that region. If there are no limitations, I can offer those copies anywhere
I want.
The end user of a physical book needs no copyright grant to use the book as
intended. Therefore, there is no need for the distributor to grant me the
right to pass on any of my license rights and no right to do that would be
implied in the absence of specific language. On the other hand, if I'm
distributing e-books and the end user is making a copy of the work by
downloading it from my site, then I would need to be able to authorize the
end user to make that copy (otherwise the end user would be an infringer).
Normally, the license agreement would explicitly provide me with that right,
but even if the agreement were silent on that point, the context makes it
clear that copies are being made by the user and a court, if presented with
the question, would very likely infer the right to pass on the permission to
make the copy. However, in no event would anyone even think of imposing on
me an obligation to provide all of my rights to make and distribute copies
to the end user.
The basic structure of copyright is that only specific rights are exclusive
to the author and that only things that infringe one of those rights are
prohibited. Anything not prohibited is permitted. That's why, unless the
right to distribute says that you must pass on all rights, a licensee is
under no such obligation.
Copyright has been around for over 300 years. While I can understand that
someone who is looking only at OSS licenses might conclude that it would
make sense to have a rule that says you have to pass on all rights, unless
given explicit permission otherwise. However, it would make no sense for
any other situation -- not books, not music, not maps, not even commercial
software. Software licenses don't have special rules. Software is treated
as a literary work under the US Copyright law and inherits all of the rules
and practices that have developed since the first US copyright act in 1790.
And remember, software wasn't even explicitly a subject of copyright in the
US until the 1980 CONTU amendment to the 1976 Copyright Act.
The purpose of a rule of construction is to give effect to the most likely
intent of the parties absent specific guidance in the license. Richard is
proposing the existence of a rule of construction that says, in the absence
of a statement otherwise, a license must pass on all rights it obtained from
the licensor when it distributes a work.
Honestly, what is the chance that the development of US Copyright Law during
the almost 200 years between 1790 and 1980 would include a rule of
construction that created a default obligation on a licensee that made
absolutely no sense for any copyrightable work that existed prior to 1980?
It's not like they knew OSS was going to show up at some point in the future
and make the rule of construction useful.
So, if Richard wants to propose that that rule of construction exists, he
needs to prove it. Neither he, nor Larry, has provide a cite to a case or
statute that even implies such a rule. I'm assuming that, for Richard, he
hasn't looked at the history of the Copyright Law and its application in
industries outside of OSS, but Larry should know better. I'm starting to
strongly suspect that Larry is allowing his desire for a particular legal
rule to overshadow the actual statute and caselaw.
Jeff
Counsel, IBM Software Group
(apologies for the length of the post)
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Jim Jagielski <ji...@jaguNET.com> wrote on 12/06/2013 06:33:05 AM:
>
> On Dec 5, 2013, at 4:30 PM, Richard Fontana <rf...@redhat.com> wrote:
> >
> > You keep asserting this but I do not think you are correct. The
> > general rule in the US, though it is a state law issue, is that you
> > need explicit permission to pass on a proper subset of rights received
> > as to the original material.
. . .
> +1
>
The fact that Richard doesn't think I'm correct, notwithstanding, his
statement of the law is incorrect. You do not need explicit permission to
pass on a subset of rights. The reason why derives from the basic
structure of copyright itself. Unfortunately, this will take a couple of
minutes. I hope no one is too bored.
Copyright is a government granted monopoly on the right to perform certain
actions with respect to creative works. US Copyright law provides six
basic exclusive rights: reproduction, modification, distribution, public
performance, public display, and digital audio transmission (ignoring moral
rights which are somewhat supported in US Law and the quasi-right of access
created by the DMCA).
If you're not performing one of those actions or even if you are, but you
fall within one of the statutory exceptions (such as fair use, library
rights, etc.), you do not need permission from the copyright owner to do
what you are doing. So, reading a book? Great. No copyright right
needed. "Reading" isn't a granted exclusive right.
The structure of the legal regime is that you're allowed to do anything you
want, unless you infringe one of the exclusive rights granted by Title 17
of the US Code.
If you want to take advantage of one of the exclusive rights, you need
permission. If you're granted permission, the scope of that permission
controls what you are allowed or not allowed to do. If I have permission
to make 1 copy of a book, that's what I get to do -- make 1 copy of the
book. If the permission doesn't say anything about how I have to make the
copy, when I can make the copy, or any other details, the restrictions do
not exist. Only that which is specified in the permission grant (i.e.,
license) applies. Of course, ambiguities need to be resolved when they are
present, but generally, if there are no restrictions, none are implied.
So, if I enter into a license agreement with a publisher of a book to be
able to print and distribute up to 50 physical copies of that work
(invoking 2 exclusive rights, the right of reproduction and the right of
distribution), I'm good as long as I say within the 4 corners of that
license agreement. There might be region limitations in the distribution
right grant. If there are, I can only offer those copies for sale within
that region. If there are no limitations, I can offer those copies
anywhere I want.
The end user of a physical book needs no copyright grant to use the book as
intended. Therefore, there is no need for the distributor to grant me the
right to pass on any of my license rights and no right to do that would be
implied in the absence of specific language. On the other hand, if I'm
distributing e-books and the end user is making a copy of the work by
downloading it from my site, then I would need to be able to authorize the
end user to make that copy (otherwise the end user would be an infringer).
Normally, the license agreement would explicitly provide me with that
right, but even if the agreement were silent on that point, the context
makes it clear that copies are being made by the user and a court, if
presented with the question, would very likely infer the right to pass on
the permission to make the copy. However, in no event would anyone even
think of imposing on me an obligation to provide all of my rights to make
and distribute copies to the end user.
The basic structure of copyright is that only specific rights are exclusive
to the author and that only things that infringe one of those rights are
prohibited. Anything not prohibited is permitted. That's why, unless the
right to distribute says that you must pass on all rights, a licensee is
under no such obligation.
Copyright has been around for over 300 years. While I can understand that
someone who is looking only at OSS licenses might conclude that it would
make sense to have a rule that says you have to pass on all rights, unless
given explicit permission otherwise. However, it would make no sense for
any other situation -- not books, not music, not maps, not even commercial
software. Software licenses don't have special rules. Software is treated
as a literary work under the US Copyright law and inherits all of the rules
and practices that have developed since the first US copyright act in 1790.
And remember, software wasn't even explicitly a subject of copyright in the
US until the 1980 CONTU amendment to the 1976 Copyright Act.
The purpose of a rule of construction is to give effect to the most likely
intent of the parties absent specific guidance in the license. Richard is
proposing the existence of a rule of construction that says, in the absence
of a statement otherwise, a license must pass on all rights it obtained
from the licensor when it distributes a work.
Honestly, what is the chance that the development of US Copyright Law
during the almost 200 years between 1790 and 1980 would include a rule of
construction that created a default obligation on a licensee that made
absolutely no sense for any copyrightable work that existed prior to 1980?
It's not like they knew OSS was going to show up at some point in the
future and make the rule of construction useful.
So, if Richard wants to propose that that rule of construction exists, he
needs to prove it. Neither he, nor Larry, has provide a cite to a case or
statute that even implies such a rule. I'm assuming that, for Richard, he
hasn't looked at the history of the Copyright Law and its application in
industries outside of OSS, but Larry should know better. I'm starting to
strongly suspect that Larry is allowing his desire for a particular legal
rule to overshadow the actual statute and caselaw.
Jeff
Counsel, IBM Software Group
(apologies for the length of the post)
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/06/2013 04:48:44 PM:
> > What do you mean by "distribute them under different licenses"?
> I mean precisely what we at Apache (and many other FOSS projects) do
> with BSD and MIT software that we include in our software. I also
> mean what projects do who take Apache software and distribute it
> under the GPL, or companies under proprietary licenses.
That doesn't answer the question. I'm trying to get precise as to what
terms apply to C.
Code from A is licensed to B under BSD. B adds some of its own code and
licenses the combined work to C under the Apache license. B is
distributing A's code under a "different license" from what it received the
code under. If that's the case, as between B and C, the ONLY license that
is relevant in a dispute between B and C is AL2.0. If A shows up and
claims that B exceeded its authority, of course BSD terms come into the
picture then because the transaction between A and B is now in question,
but that's not what I'm asking. Just between B and C, what are the terms?
On the other hand, if what you are saying is that B distributes the
combined work to C, but A's code is licensed to C under the BSD and B's
code and any copyright in the collection is licensed to C under the AL2.0,
then I don't see how that's a different license. In that case, in a
dispute between B and C, both the BSD license and the AL2.0 are relevant
licenses.
Which case do you mean when you say "distribute under different licenses"?
Either is possible, as far as I can tell. But, I wouldn't call the second
structure as distributing A's code under a different license. I'd call it
passing A's license on to C.
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
> What do you mean by "distribute them under different licenses"?
I mean precisely what we at Apache (and many other FOSS projects) do with
BSD and MIT software that we include in our software. I also mean what
projects do who take Apache software and distribute it under the GPL, or
companies under proprietary licenses.
We encourage that! We even allow sublicensing for those who want to add more
terms and conditions.
But we don't claim that it affects in any way the underlying license for the
included software.
You keep saying that you can give fewer rights than you got from the
original licensor. Maybe so in some negotiated commercial transaction with
unsophisticated customers, but you can't take away rights that the original
licensor gave to the entire world. No FOSS licensor has ever said you could
do that.
As for what FSF says, I'd encourage them to speak for themselves here. But I
don't believe they have ever successfully prevented any software distributor
from combining GPL software /in the non-derivative-work way/ with other FOSS
software under a single non-GPL collective work license. And I've never
heard of them threatening any Apache project that might want to do that
combination for the convenience of its customers. They can rest assured that
their GPL license remains intact on their GPL software for the entire world
to use.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Friday, December 06, 2013 1:10 PM
To: legal-discuss@apache.org
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/06/2013 03:31:54 PM:
> SITUTATION 1: You are describing the situation where Apache /gives/
> FOSS works to others who then distribute them under different
> licenses.
Larry,
What do you mean by "distribute them under different licenses"?
In my hypo from a few notes ago, A distributes software to B under AL2.0. B
combines it with GPL code and distributes the result to C under the GPL. As
far as C is concerned, the GPL is the only license it needs to read in order
to understand what rights it gets from B, even for A's code. AL2.0 is in
the notices file and C can review that if it wants to, but if there ever is
a dispute between B and C, the license of record, the terms that get
submitted to the court for interpretation, is the GPL, right? If not, then
you're using English wrong.
> SITUATION 2: I'm also concerned about properly describing the
> situation where Apache /takes/ FOSS works of others and then
> distributes them under the Apache License.
You may or may not be able to do that, depending on what the original
license is. I'm confident that if we asked the FSF, they wouldn't say that
we can incorporate their GPL code into an Apache project and license it
outbound under AL2.0. At best, Apache can include the GPL code in its
project and provide 2 licenses -- AL2.0 for everything not virally impacted
by the GPL code, and GPL for the remainder. But, that's not distributing
the project "under the Apache License" in any reasonable interpretation of
that phrase.
I'm sure that there is a logic to your approach, but for the life of me, I
can't divine what it is. Can you explain?
Jeff
Counsel, IBM Software Group.
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/06/2013 03:31:54 PM:
> SITUTATION 1: You are describing the situation where Apache /gives/
> FOSS works to others who then distribute them under different
> licenses.
Larry,
What do you mean by "distribute them under different licenses"?
In my hypo from a few notes ago, A distributes software to B under AL2.0.
B combines it with GPL code and distributes the result to C under the GPL.
As far as C is concerned, the GPL is the only license it needs to read in
order to understand what rights it gets from B, even for A's code. AL2.0
is in the notices file and C can review that if it wants to, but if there
ever is a dispute between B and C, the license of record, the terms that
get submitted to the court for interpretation, is the GPL, right? If not,
then you're using English wrong.
> SITUATION 2: I'm also concerned about properly describing the
> situation where Apache /takes/ FOSS works of others and then
> distributes them under the Apache License.
You may or may not be able to do that, depending on what the original
license is. I'm confident that if we asked the FSF, they wouldn't say that
we can incorporate their GPL code into an Apache project and license it
outbound under AL2.0. At best, Apache can include the GPL code in its
project and provide 2 licenses -- AL2.0 for everything not virally impacted
by the GPL code, and GPL for the remainder. But, that's not distributing
the project "under the Apache License" in any reasonable interpretation of
that phrase.
I'm sure that there is a logic to your approach, but for the life of me, I
can't divine what it is. Can you explain?
Jeff
Counsel, IBM Software Group.
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Dec 6, 2013 at 3:31 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Sam Ruby asked: > Am I mistaken in my understanding?
>
>
>
> As far as that concrete example goes, you're right.
>
Thanks.
SITUTATION 1: You are describing the situation where Apache /gives/ FOSS
> works to others who then distribute them under different licenses. You
> described our goal correctly for that example, although this does not mean
> that diligent downstream distributors shouldn't read our NOTICE files for
> potential limitations and risks (e.g., copyright, patent, trademark)
> associated with those Apache software products. There may be some risks
> that downstream distributors aren't commercially willing to take, which is
> the reason for our full disclosure policy.
>
>
I'm uncomfortable with the word 'give' here in that our role is more
passive. We make our software available to everybody without
discrimination, and we welcome people to make our software available under
other licenses, as long as they follow the terms of our license.
>
>
> SITUATION 2: I'm also concerned about properly describing the situation
> where Apache /takes/ FOSS works of others and then distributes them under
> the Apache License. We should allow non-Apache components only when an
> Apache project can justify it (as for GPL dictionaries in Open Office) and
> only when any downstream licensing risks are clearly understood and
> accepted by the project PMC itself. Under such a policy, a PMC could accept
> CC-BY icons that can easily be removed and replaced by downstream
> distributors who might not want that risk. It is a situation-specific
> analysis that should take place. What can Apache do with such works so that
> we don't adversely affect SITUATION 1?
>
>
>
> This is what our Third Party Licensing Policy fails to articulate. We
> identify licenses by name rather than understanding the purpose for our
> projects' use of non-Apache contributions in specific cases, and without
> asking relevant questions about the creation of /derivative works/. So when
> Eclipse, and Mozilla, and Linux, and many other projects create FOSS
> software that they allow us to incorporate into our Apache software, it is
> foolish to avoid them simply because some commercial distributor downstream
> doesn't agree with what our Apache project wants to do. All our software
> will be FOSS, and all of it will be collectively under Apache License 2.0,
> and customers can take it or leave it or change it, just as you described.
>
By contrast, I am quite comfortable with the word 'takes' here. This
involves a deliberate action on our part.
I will also note that what you are describing here (clearly communicating
the additional risks and limitations, and limiting the usage to cases where
the the component is optional) is the essence of Categories B and Category
X.
http://www.apache.org/legal/resolved.html#category-b
http://www.apache.org/legal/3party.html#options
/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
>
- Sam Ruby
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby asked: > Am I mistaken in my understanding?
As far as that concrete example goes, you're right.
SITUTATION 1: You are describing the situation where Apache /gives/ FOSS works to others who then distribute them under different licenses. You described our goal correctly for that example, although this does not mean that diligent downstream distributors shouldn't read our NOTICE files for potential limitations and risks (e.g., copyright, patent, trademark) associated with those Apache software products. There may be some risks that downstream distributors aren't commercially willing to take, which is the reason for our full disclosure policy.
SITUATION 2: I'm also concerned about properly describing the situation where Apache /takes/ FOSS works of others and then distributes them under the Apache License. We should allow non-Apache components only when an Apache project can justify it (as for GPL dictionaries in Open Office) and only when any downstream licensing risks are clearly understood and accepted by the project PMC itself. Under such a policy, a PMC could accept CC-BY icons that can easily be removed and replaced by downstream distributors who might not want that risk. It is a situation-specific analysis that should take place. What can Apache do with such works so that we don't adversely affect SITUATION 1?
This is what our Third Party Licensing Policy fails to articulate. We identify licenses by name rather than understanding the purpose for our projects' use of non-Apache contributions in specific cases, and without asking relevant questions about the creation of /derivative works/. So when Eclipse, and Mozilla, and Linux, and many other projects create FOSS software that they allow us to incorporate into our Apache software, it is foolish to avoid them simply because some commercial distributor downstream doesn't agree with what our Apache project wants to do. All our software will be FOSS, and all of it will be collectively under Apache License 2.0, and customers can take it or leave it or change it, just as you described.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Friday, December 06, 2013 11:50 AM
To: Legal Discuss; Lawrence Rosen
Subject: Re: New versions of CC licenses
On Fri, Dec 6, 2013 at 2:19 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
Sam Ruby wrote:
> It is my understanding that one could take a product released under the Apache License, Version 2.0, incorporate it into a product, and release the result under the terms of GPL v3. I believe that a similar statement can be made concerning MPL v2. And for various proprietary licenses.
That is right. And vice versa (excluding proprietary licenses) as long as by /incorporate/ you don't mean /create and distribute a derivative work/.
Again, I may have been unclear.
Perhaps a concrete example would help.
I believe that LibreOffice may take the SVG import feature from Apache Open Office, modify it as they see fit -- thereby creating a derivative work -- and release the result under the terms of LGPLv3. Furthermore, they are under no obligation to either contribute this result back to Apache Open Office, nor are they even required to license the derivative work that they produced under the terms of the Apache License, Version 2.0.
For reference:
https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating
http://www.libreoffice.org/download/license/
Am I mistaken in my understanding?
- Sam Ruby
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Dec 6, 2013 at 2:19 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Sam Ruby wrote:
>
> > It is my understanding that one could take a product released under the
> Apache License, Version 2.0, incorporate it into a product, and release the
> result under the terms of GPL v3. I believe that a similar statement can
> be made concerning MPL v2. And for various proprietary licenses.
>
>
>
> That is right. *And vice versa* (excluding proprietary licenses) as long
> as by /incorporate/ you don't mean /create and distribute a derivative
> work/.
>
>
Again, I may have been unclear.
Perhaps a concrete example would help.
I believe that LibreOffice may take the SVG import feature from Apache Open
Office, modify it as they see fit -- thereby creating a derivative work --
and release the result under the terms of LGPLv3. Furthermore, they are
under no obligation to either contribute this result back to Apache Open
Office, nor are they even required to license the derivative work that they
produced under the terms of the Apache License, Version 2.0.
For reference:
https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating
http://www.libreoffice.org/download/license/
Am I mistaken in my understanding?
- Sam Ruby
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby wrote:
> It is my understanding that one could take a product released under the Apache License, Version 2.0, incorporate it into a product, and release the result under the terms of GPL v3. I believe that a similar statement can be made concerning MPL v2. And for various proprietary licenses.
That is right. And vice versa (excluding proprietary licenses) as long as by /incorporate/ you don't mean /create and distribute a derivative work/.
Even if you do create and distribute a derivative work, that is allowed under the condition that the derivative works of the GPL/MPL components themselves be under the non-Apache license. Everyone now understands that about reciprocal FOSS licenses, and commercial companies live with (or without!) that "restriction" all the time. Given that our goal is not to surprise our customers with unexpected license restrictions, downstream distributors can read our NOTICE files and take easy precautions /if they create and distribute a derivative work/. As I said before, that is already commercially necessary due diligence.
Furthermore, customers who merely copy and use and distribute our software without modification can ignore the entire issue; we comply with all licenses, therefore they comply.
The only logical inconsistency between licenses is if you create a derivative work of /both/ an MPL and GPL combination simultaneously and as an integrated derivative work. I don't know anyone who tries that. It was interesting for me to see that, because of their goal to be friendly to the GPL, the new version of the MPL itself now allows that unique derivative work combination with GPL software for those downstream distributors who want it. :-) But that has nothing to do with anything that happens at Apache.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Friday, December 06, 2013 10:16 AM
To: Legal Discuss; Lawrence Rosen
Subject: Re: New versions of CC licenses
On Fri, Dec 6, 2013 at 12:42 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
Sam Ruby wrote:
> My understanding is that the Apache License, Version 2 is widely considered to be "compatible" with both licenses, in the sense that Apache code may be incorporated into products that are released under the Mozilla and GPL licenses.
And my understanding is that the reverse is also true, as long as you don't try to distribute a derivative work of Mozilla or GPL software under the Apache License.
I may have been unclear. It is my understanding that one could take a product released under the Apache License, Version 2.0, incorporate it into a product, and release the result under the terms of GPL v3. I believe that a similar statement can be made concerning MPL v2. And for various proprietary licenses.
All one needs to do is to comply with the terms of the Apache License, none of which preclude you from doing the above.
What am I missing?
- Sam Ruby
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Dec 6, 2013 at 12:42 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Sam Ruby wrote:
>
>
> > My understanding is that the Apache License, Version 2 is widely
> considered to be "compatible" with both licenses, in the sense that Apache
> code may be incorporated into products that are released under the Mozilla
> and GPL licenses.
>
> And my understanding is that the reverse is also true, as long as you
> don't try to distribute a derivative work of Mozilla or GPL software under
> the Apache License.
>
I may have been unclear. It is my understanding that one could take a
product released under the Apache License, Version 2.0, incorporate it into
a product, and release the result under the terms of GPL v3. I believe
that a similar statement can be made concerning MPL v2. And for various
proprietary licenses.
All one needs to do is to comply with the terms of the Apache License, none
of which preclude you from doing the above.
What am I missing?
- Sam Ruby
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Sam Ruby wrote:
> My understanding is that the MPL version 4 and the GPL version 3 are more restrictive than the Apache License, Version 2.
Ranking licenses on a scale of "restrictiveness" has never proven useful. Better to ask if the license allows the recipient to do what he needs to do with the software.
As I read those licenses, you can include MPL or GPL code /in combination/ with Apache software without restriction or infection. Of course, if you create a derivative work /of the MPL or GPL code/ you must distribute /that derivative work/ under the MPL or GPL. Other than the distribution condition on derivative works, what do you find more restrictive in those licenses? And why would you even call that "restrictive" since it doesn't seem to restrict ASF from doing what it is likely to do with that MPL software, namely combine it without changing it at all?
Nor does it impose any restrictions on our customers /except/ if they choose to distribute a derivative work of our Apache software. In that event, they must be careful to avoid changing the MPL/GPL components, unless they are willing to disclose those changes. But that's not a unique problem; distributors must /always/ exercise care and diligence with the software they distribute. That's commercially /necessary/. They must read our NOTICE file.
> My understanding is that the Apache License, Version 2 is widely considered to be "compatible" with both licenses, in the sense that Apache code may be incorporated into products that are released under the Mozilla and GPL licenses.
And my understanding is that the reverse is also true, as long as you don't try to distribute a derivative work of Mozilla or GPL software under the Apache License. In all other respects, MPL and GPL code is FOSS just like Apache software, with absolutely no restrictions that would violate the OSD. No other restrictions are allowed or could matter to Apache given what we will do with that code.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/> www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
Linkedin profile: <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Friday, December 06, 2013 6:48 AM
To: Legal Discuss
Subject: Re: New versions of CC licenses
On Fri, Dec 6, 2013 at 6:33 AM, Jim Jagielski <ji...@jagunet.com> wrote:
On Dec 5, 2013, at 4:30 PM, Richard Fontana <rf...@redhat.com> wrote:
>
> You keep asserting this but I do not think you are correct. The
> general rule in the US, though it is a state law issue, is that you
> need explicit permission to pass on a proper subset of rights received
> as to the original material. CC BY clearly denies this permission. I
> think the Apache License 2.0 is best read as denying this right, and
> that view is consistent with what I've heard some ASF people say on
> this list (for example, in one of the AOO vs. LibreOffice threads that
> came up a year or so ago).
+1
Perhaps I'm misunderstanding. Perhaps recasting this question into another context will help me understand.
My understanding is that the MPL version 4 and the GPL version 3 are more restrictive than the Apache License, Version 2.
My understanding is that the Apache License, Version 2 is widely considered to be "compatible" with both licenses, in the sense that Apache code may be incorporated into products that are released under the Mozilla and GPL licenses.
Is my understanding wrong?
- Sam Ruby
Re: New versions of CC licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Dec 6, 2013 at 6:33 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Dec 5, 2013, at 4:30 PM, Richard Fontana <rf...@redhat.com> wrote:
> >
> > You keep asserting this but I do not think you are correct. The
> > general rule in the US, though it is a state law issue, is that you
> > need explicit permission to pass on a proper subset of rights received
> > as to the original material. CC BY clearly denies this permission. I
> > think the Apache License 2.0 is best read as denying this right, and
> > that view is consistent with what I've heard some ASF people say on
> > this list (for example, in one of the AOO vs. LibreOffice threads that
> > came up a year or so ago).
>
> +1
>
Perhaps I'm misunderstanding. Perhaps recasting this question into another
context will help me understand.
My understanding is that the MPL version 4 and the GPL version 3 are more
restrictive than the Apache License, Version 2.
My understanding is that the Apache License, Version 2 is widely considered
to be "compatible" with both licenses, in the sense that Apache code may be
incorporated into products that are released under the Mozilla and GPL
licenses.
Is my understanding wrong?
- Sam Ruby
Re: New versions of CC licenses
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 5, 2013, at 4:30 PM, Richard Fontana <rf...@redhat.com> wrote:
>
> You keep asserting this but I do not think you are correct. The
> general rule in the US, though it is a state law issue, is that you
> need explicit permission to pass on a proper subset of rights received
> as to the original material. CC BY clearly denies this permission. I
> think the Apache License 2.0 is best read as denying this right, and
> that view is consistent with what I've heard some ASF people say on
> this list (for example, in one of the AOO vs. LibreOffice threads that
> came up a year or so ago).
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 10:15:25AM -0500, Jeffrey Thompson wrote:
> 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).
[...]
> 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).
You keep asserting this but I do not think you are correct. The
general rule in the US, though it is a state law issue, is that you
need explicit permission to pass on a proper subset of rights received
as to the original material. CC BY clearly denies this permission. I
think the Apache License 2.0 is best read as denying this right, and
that view is consistent with what I've heard some ASF people say on
this list (for example, in one of the AOO vs. LibreOffice threads that
came up a year or so ago).
- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/05/2013 03:41:26 PM:
> > The component is still AVAILABLE under the
> > AL2.0 license and C and take advantage of those rights if it
> chooses to do so,
> > but as between B and C, the license agreement to the derivative
> work does not
> > need to include the language of AL2.0.
>
> I agree with this. What I don't see is how CC BY is different.
>
...
> It does not say:
>
> You may provide additional or different license terms and conditions
> for use, reproduction, or distribution of the Work, provided Your
> use, reproduction, and distribution of the Work otherwise complies
> with the conditions stated in this License.
>
> I believe that is significant.
But, its not really significant. There is no rule in copyright licenses
that says that you can't pass on fewer rights than you received. If you
think that there is, then you need to provide a cite. A statute. A case.
A section reference to Nimmer on Copyrights. Anything. Please. But,
until you have something, we're just spinning our wheels here.
> It restricts the terms of the license grant for the CC BY
> material. The Apache License 2.0 restricts the terms of the license
> grant for the Apache License 2.0 material.
The Apache license does not (except for the general requirement that you
can't pass on more rights than you received). See my plea above.
>
> But he/she/it cant restrict the original license as to the originally
> licensed component, unless the original license allows this.
B can't change the terms under which B received the code and can't negate
the existence of the public offer from A that C can take advantage of
(assuming it was indeed a public offer), but B can certainly limit what
rights it grants to C (at least as between B and C). I'm willing to
discuss actual legal principles if you have cites to them. But just
repeating a belief about a legal topic isn't going to help.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 02:00:12PM -0500, Jeffrey Thompson wrote:
> If A publishes the component with an AL2.0 license, B can accept that license,
> incorporate the component into its product and license the derivative work to C
> under its proprietary license. The component is still AVAILABLE under the
> AL2.0 license and C and take advantage of those rights if it chooses to do so,
> but as between B and C, the license agreement to the derivative work does not
> need to include the language of AL2.0.
I agree with this. What I don't see is how CC BY is different.
Again, note this clause in the Apache License 2.0:
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions for
use, reproduction, or distribution of Your modifications, or for any
such Derivative Works as a whole, provided Your use, reproduction,
and distribution of the Work otherwise complies with the conditions
stated in this License.
It does not say:
You may provide additional or different license terms and conditions
for use, reproduction, or distribution of the Work, provided Your
use, reproduction, and distribution of the Work otherwise complies
with the conditions stated in this License.
I believe that is significant.
> In any event, that's not my point either. Commercial licenses, even the really
> restrictive ones, don't generally prevent customers from separately going and
> getting OSS code when they want broader rights. My point is about the impact
> of the section in CC-BY that explicitly restricts the terms of the license
> grant between B and C. That's what makes it commercially non-friendly.
It restricts the terms of the license grant for the CC BY
material. The Apache License 2.0 restricts the terms of the license
grant for the Apache License 2.0 material.
> I'm thinking that part of the confusion is the mental model that a particular
> license text follows the code as a matter of copyright law. It doesn't. A
> license makes certain grants of rights that the licensee is then permitted to
> exercise. The license can include certain limitations on those rights (e.g.,
> in order to distribute under your own terms, you need to meet conditions
> 4.1-4.4). The license can include contractual promises back and forth between
> the parties (e.g., you agree to indemnify the Contributors if your acceptance
> of warranty obligations somehow comes back and causes damage to the original
> authors). But, all of that documents ONLY the transaction between the licensor
> and the licensee.
>
> If licensee then exercises some of those rights (e.g., the right to distribute
> derivative works), as long as he is in compliance with the limitations on the
> original grants and his contractual commitments, he's free to use whatever
> license language he and his customer agree to.
But he/she/it cant restrict the original license as to the originally
licensed component, unless the original license allows this.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/05/2013 11:49:56 AM:
> 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
FOSSlicenses?
So, I can summarize your position to be that you don't care if Apache's
licensing policies make it difficult for commercial licensors to use Apache
code. That's fine and its clear. But, don't pretend that you're not
trying to change Apache's policies in that regard.
AL2.0 licensed code, by itself, is easy for a commercial user to consume.
AL2.0 licensed code, with embedded CC-BY code, is not.
As an aside, your promotion of this "wrapping" concept doesn't do OSS
projects any favors either. OSS license proliferation is a real problem.
Setting up a structure where all code is permanently licensed under the
original terms means, that over time, the number of different versions of
different licenses texts that are actively used when distributing project
output will continue to grow. Without the ability to consolidate
compatible licenses into a common base (e.g., assuming that all of the
different licenses provide at least AL2.0 rights, provide the entire
project under the AL2.0 license), you'll sooner or later end up with more
license text than code. (ok, maybe that's an exaggeration, but only a
small one.)
Jeff
Counsel, IBM Software Group
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
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
<http://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 <st...@gmail.com> wrote on 12/05/2013
09:52:32 AM:
> On 5 December 2013 14:43, Jeffrey Thompson <jt...@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
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Stephen Connolly <st...@gmail.com> wrote on 12/05/2013
10:30:54 AM:
>
> The pre-existing license applies to the collective work, as it is
> the collective work that is being distributed.
Yes, if that's the agreement the commercial entity has with their customer
(not uncommon).
> The collective work can have a different set of license terms than
> individual components.
I think I'm seeing where there is a disconnect.
Maybe a programming analogy -- a license doesn't bind itself to code like
the independent variables in a closure. Its more like a local copy of a
passed parameter. Code, passed from one party to another can be subject to
different license grant language as long as no licensor tries to grant more
rights than it received (unless, of course, the original grant says you
must pass on all rights using the original language, which most OSS
licenses don't say).
So, postulate the existence of 3 companies, A, B, and C. A writes the
component, licenses it to B for inclusion in a product. B licenses the
resulting product to C.
When you say the collective work can have a different set of license terms
than individual components. That's exactly right. But the individual
components can be subject to different license grants during its journey,
as well.
If A publishes the component with an AL2.0 license, B can accept that
license, incorporate the component into its product and license the
derivative work to C under its proprietary license. The component is still
AVAILABLE under the AL2.0 license and C and take advantage of those rights
if it chooses to do so, but as between B and C, the license agreement to
the derivative work does not need to include the language of AL2.0.
Because of the general principal that you can't grant more right than you
received, the main constraint on the license agreement between B and C is
that B grant no more rights than that provided by AL2.0.
So, in that case, the component is subject to the AL2.0 license for the
transaction between A and B. The result is that B has certain rights now
that it can pass on if it chooses to do so. Next, the component (as part
of the derivative work), is provided to C under a different, but
non-contradictory, license. This doesn't mean that B is somehow changing
the license rights that A is making available. The AL2.0 rights are still
available to anyone that wants them.
Note, that A is not involved in the transaction between B and C, therefore
A cannot be required to comply with any of its terms. So, if someone comes
to A and demands some action that is required under the license from B to
C, A is perfectly free to point to the AL2.0 as its sole grant and
statement of obligations related to that code. Nothing that B does in its
transaction with C will affect A in any practical way.
> The collective work can grant a subset of the rights from the
> individual components *provided that* the full rights of granted by
> the original author(s) on the individual components to all end users
> can still be fulfilled.
I'm not sure I followed that. There's nothing in copyright law that says
license offers need to be made available to all potential licensees. In
the hypo above, if A is making its offer of the component under AL2.0
broadly to the public, nothing in the transaction between B and C rescinds
that.
That said, AL2.0 doesn't include language that addresses license privity
(e.g., the text in CC-BY that says that all of these rights are made
available to all end users directly from the copyright owners). But,
that's not the CC-BY language that we're discussing. That type of license
privity language doesn't require modification of the license between B and
C either, so wouldn't necessarily cause a conflict with a commercial
licensing scheme. Its the section following that addresses license terms
that's the problem.
>
> So what that says is that the rights on the collective work can be
> less than or equal to the rights of every individual component
> *provided* that the end recipient can access the individual
> components outside of the collective work where such access is
> required to exercise their full set of rights.
Your "*provided*" clause isn't required by copyright law, in general, so
would need to be expressly stated in the OSS license. It could be an OSS
licensing goal, but its not in the AL2.0 license at this point.
In any event, that's not my point either. Commercial licenses, even the
really restrictive ones, don't generally prevent customers from separately
going and getting OSS code when they want broader rights. My point is
about the impact of the section in CC-BY that explicitly restricts the
terms of the license grant between B and C. That's what makes it
commercially non-friendly.
>
> Lets suppose there is a psychometric test that is licensed CC-BY.
>
> I might produce a testing manual with instructions on how to score,
> administer and interpret the test. The manual may have a restricted
> license forbidding photocopying, I might even have technical
> measures (such as using a special ink that doesn't photocopy or a
> low contrast printing mechanism) to prevent photocopying. For
> practical reasons it may not be possible to exclude those technical
> measures from the copy of the test that I include in my book... oh
> and the included parts all have the header and footer which is my
> content, so they are modified... I would be in breach of the CC-BY
> license *unless* I also included, say a CD-ROM with the test in PDF
> form, or an URL to download the PDF of the test, etc... my point is
> once I do that I am no longer in breach... or at least to my reading
> of CC-BY I am not.
Maybe you're in compliance with the CC-BY at that point if your overall
license for the manual explicitly provides the CC-BY terms for the
appropriate content. As I said in one of my earlier notes, its not too
hard to create a modified commercial license which takes into account the
requirements of CC-BY and apply that to the product you're developing.
The problem is what happens to you when the testing manual you've just
created is provided to a customer pursuant to an agreement negotiated last
year (before you knew that you were going to use the CC-BY content in the
manual) and the license that you negotiated with your customer prohibits
them from redistributing any part of your testing manuals. By the terms of
your license, the customer is prohibited from distributing the CC-BY
content, which violates your obligations under Section 2.a.5.B of CC-BY.
The fact that you also give them the CC-BY content on a separate CD-ROM
under the CC-BY license doesn't eliminate the breach, though it might
sufficiently mollify the original author that they won't make a stink about
it.
But, that brings back one of the points I made earlier, one would think
that providing a commercial customer a broader license wouldn't cause any
concern at all. But, it does. If its completely optional, that is you let
them know that the add'l rights are available (e.g., via the Notices file),
then they're OK. But, once you unilaterally change the terms of the
license, even for the better, expect a problem.
>
> Please educate me if I am wrong as I am interested to understand the
nuances
I'm thinking that part of the confusion is the mental model that a
particular license text follows the code as a matter of copyright law. It
doesn't. A license makes certain grants of rights that the licensee is
then permitted to exercise. The license can include certain limitations on
those rights (e.g., in order to distribute under your own terms, you need
to meet conditions 4.1-4.4). The license can include contractual promises
back and forth between the parties (e.g., you agree to indemnify the
Contributors if your acceptance of warranty obligations somehow comes back
and causes damage to the original authors). But, all of that documents
ONLY the transaction between the licensor and the licensee.
If licensee then exercises some of those rights (e.g., the right to
distribute derivative works), as long as he is in compliance with the
limitations on the original grants and his contractual commitments, he's
free to use whatever license language he and his customer agree to.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 5 December 2013 15:15, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> Stephen Connolly <st...@gmail.com> wrote on 12/05/2013
> 09:52:32 AM:
>
> > On 5 December 2013 14:43, Jeffrey Thompson <jt...@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).
>
>
The pre-existing license applies to the collective work, as it is the
collective work that is being distributed.
The collective work can have a different set of license terms than
individual components.
The collective work cannot grant rights to the individual components that
were not granted to the person creating the collective work by the original
author(s)
The collective work can grant a subset of the rights from the individual
components *provided that* the full rights of granted by the original
author(s) on the individual components to all end users can still be
fulfilled.
So what that says is that the rights on the collective work can be less
than or equal to the rights of every individual component *provided* that
the end recipient can access the individual components outside of the
collective work where such access is required to exercise their full set of
rights.
Lets suppose there is a psychometric test that is licensed CC-BY.
I might produce a testing manual with instructions on how to score,
administer and interpret the test. The manual may have a restricted license
forbidding photocopying, I might even have technical measures (such as
using a special ink that doesn't photocopy or a low contrast printing
mechanism) to prevent photocopying. For practical reasons it may not be
possible to exclude those technical measures from the copy of the test that
I include in my book... oh and the included parts all have the header and
footer which is my content, so they are modified... I would be in breach of
the CC-BY license *unless* I also included, say a CD-ROM with the test in
PDF form, or an URL to download the PDF of the test, etc... my point is
once I do that I am no longer in breach... or at least to my reading of
CC-BY I am not.
Please educate me if I am wrong as I am interested to understand the
nuances
-Stephen
>
> Jeff
> Counsel, IBM Software Group
>
>
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Stephen Connolly <st...@gmail.com> wrote on 12/05/2013
09:52:32 AM:
> On 5 December 2013 14:43, Jeffrey Thompson <jt...@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
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 5 December 2013 14:43, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> Stephen Connolly <st...@gmail.com> wrote on 12/05/2013
> 09:33:09 AM:
>
> > On 5 December 2013 13:55, Jeffrey Thompson <jt...@us.ibm.com> wrote:
>
> > "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 07:52:07 PM:
> > > Again, I don't know why you and Luis are complaining about CC-BY.
> > > The GPLv3's DRM conditions are far more strict than those of CC-BY.
> > > Nothing in CC-BY requires the disclosure of "complete corresponding
> > > source code" nor even the "source code" at all.
> >
>
> > I haven't addressed the DRM conditions.
> >
> > Isn't the mistake you are making in assuming that only one copy of
> > the CC-BY licensed stuff is included?
> >
> > If I were shipping a binary with DRM to prevent modification of my
> > code, I would presume (in my IANAL capacity) that the easy way out
> > is to bundle a non-DRM copy of the CC-BY licensed stuff in addition
> > to the DRM protected stuff.
> >
>
> 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.
> Jeff
> Counsel, IBM Software Group
>
>
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Stephen Connolly <st...@gmail.com> wrote on 12/05/2013
09:33:09 AM:
> On 5 December 2013 13:55, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 07:52:07 PM:
> > Again, I don't know why you and Luis are complaining about CC-BY.
> > The GPLv3's DRM conditions are far more strict than those of CC-BY.
> > Nothing in CC-BY requires the disclosure of "complete corresponding
> > source code" nor even the "source code" at all.
>
> I haven't addressed the DRM conditions.
>
> Isn't the mistake you are making in assuming that only one copy of
> the CC-BY licensed stuff is included?
>
> If I were shipping a binary with DRM to prevent modification of my
> code, I would presume (in my IANAL capacity) that the easy way out
> is to bundle a non-DRM copy of the CC-BY licensed stuff in addition
> to the DRM protected stuff.
>
Stephen,
I haven't addressed the DRM restriction. I'm talking about the license
terms under which the customer receives the combined work.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Stephen Connolly <st...@gmail.com>.
On 5 December 2013 13:55, Jeffrey Thompson <jt...@us.ibm.com> wrote:
> "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 07:52:07 PM:
> > Jeffrey Thompson wrote:
>
> > > We've had this discussion before. The Apache license does not say
> > > that it must become a part of the license under which the Apache
> > > user licenses the resulting product to its customer. It merely
> > states that
> > > a copy of the Apache license needs to be provided. This was part of
> the
> > > design.
>
> > Which design are you referring to? I'm reading the OSD....
> >
> > The Apache License applies to all works distributed by ASF. A
> > contributor's license applies to her contributions included in that
> > Apache work. There is nothing that a downstream licensor can do to
> > change that short of requesting new licenses from the licensors.
>
> Right. If you don't want to receive the code under the Apache license,
> you need to talk to the copyright owners and get a separate license. I'm
> not sure what that has to do with our conversation, though.
>
>
> >
> > > There is no general copyright principle that says that a licensee has
> > > to pass on all rights that it received from its licensor. If you
> > can provide
> > > a cite to one, please do.
> >
> > How does IBM avoid passing on those rights?
>
> I didn't say that one could distribute the code without passing on ANY
> rights. I said one is allowed to distribute the code without passing on
> ALL OF the rights.
>
>
> > The second sentence of
> > 17 USC 103(b) says: "The copyright in [compilations and derivative
> > works] is independent of, and does not affect or enlarge the scope,
> > duration, ownership, or subsistence of, any copyright protection in
> > the preexisting material [e.g., contributions]."
>
> I'm saying that, broadly speaking, there are 2 types of OSS licenses --
> ones which don't necessarily require you to change your pre-existing
> licenses and ones that do. Apache, MIT, BSD, EPL (for executables, not
> source), etc. are in the former camp. GPL, CC-BY, etc. are in the latter.
>
> Is your point that because the copyright in the derivative work is
> separate, you are free to ignore those provisions of the GPL and CC-BY and
> distribute your derivative work under your own license terms (e.g., without
> stating that certain components are licensed to you under the GPL)?
>
> If that's not your point, I can't understand why you're quoting this
> statute.
>
>
> >
> > There is also an Apache License provision that says almost the same
> > thing. Richard Fontana quoted section 4d:
> >
> > You ... may provide additional or different license terms and
> > conditions for use, reproduction, or distribution of Your
> > modifications, or for any such Derivative Works as a whole, provided
> > Your use, reproduction, and distribution of the Work otherwise
> > complies with the conditions stated in this License.
>
> You may provide your derivative works (to your customers) under your own
> terms. Great, that's what I'm saying.
>
> ... provided you comply with the conditions in the license. Fine. What's
> the condition that the distribution would not be complying with by using
> its own terms?
>
> There are no conditions in section 1.
> There are no conditions in section 2.
> Last sentence of section 3 could be interpreted as a condition, but its
> really just a limitation on the patent grant n the prior sentence. In any
> event, it would not be a condition that turns on the user's outbound
> license.
>
> Section 4 -- has conditions.
> 4.1. Give a copy of the Apache license -- check. No obligation to change
> the pre-existing license agreement.
> 4.2. Mark modifications -- check
> 4.3. Retain notices in the source -- check
> 4.4 Retain Notices file -- check
>
> Section 5, contributions -- not relevant here
> Section 6, trademarks -- not relevant here
> Section 7, warranty -- not relevant here
> Section 8, liability -- not relevant here
> Section 9, adding warranty terms -- not a condition, but an explicit
> permission -- and doesn't relate to the outbound licensing terms.
>
> I'm out of license. I don't see any condition that requires a distributor
> to modify its outbound license.
>
> > This is not a big burden for Apache licensees, because the
> > conditions we impose are minimal. See section 4 of the license.
> > Almost anyone can satisfy those conditions trivially. The same easy
> > implementation can be said for the BSD and CC-BY licenses.
>
> CC-BY says "You may not offer or impose ... different terms ... to the
> Licensed Material if doing so restricts exercise of the Licensed Rights."
>
> That sentence explicitly places a requirement on the outbound license
> which will likely not be satisfied by most commercial licenses since most
> commercial licenses prohibit modification and redistribution. There is NO
> equivalent provision in BSD or Apache.
>
>
> > The conditions you impose on your customers are your own
> > business, and you are free to wrap our Apache software, along with
> > your own software, under any license you choose.
>
> If "wrapping" means applying terms to the original parts of the combined
> work, while passing thru the Apache license for the Apache works, it is
> certainly possible to craft a license that does that. In effect, it would
> say "Here, Mr. Customer, is a license that covers 90% of the work and this
> Apache license covers this part over here." But, that's not commercially
> reasonable for long term software agreements that cover multiple products
> and multiple versions of products. You don't know that Apache/BSD/CC-BY
> components are going to be in the products yet since some of them may not
> have been developed.
>
> Customers react poorly to the concept that the supplier can change its
> software license after the agreement is signed merely because the supplier
> decided to include an OSS component. So, while logically it works that the
> supplier could have a license that says that certain terms apply "unless I
> say otherwise", its not going to be generally acceptable to customers.
>
>
> > Again, I don't know why you and Luis are complaining about CC-BY.
> > The GPLv3's DRM conditions are far more strict than those of CC-BY.
> > Nothing in CC-BY requires the disclosure of "complete corresponding
> > source code" nor even the "source code" at all.
>
> I haven't addressed the DRM conditions.
>
Isn't the mistake you are making in assuming that only one copy of the
CC-BY licensed stuff is included?
If I were shipping a binary with DRM to prevent modification of my code, I
would presume (in my IANAL capacity) that the easy way out is to bundle a
non-DRM copy of the CC-BY licensed stuff in addition to the DRM protected
stuff.
Thus the receiving user receives the material and all original rights, and
my custom code can have whatever license it needs.
The end user is free to modify a copy of the icons or whatever that they
have received, but not free to modify the compiled binary that bundles them.
What kind of DRM could I put on a binary that I am producing...
At its simplest I could just be distributing a .jar file (which is just a
fancy .zip file after all)
The JAR spec allows for signing of its contents... So I could sign the
contents with my own certificate... at this point you cannot modify the JAR
file's contents without either turning off signature verification or
signing everything with your own certificate.
I could have the primary entry point of my code check what certificate was
used to sign the code base and bomb out if it is not my signature.
None of the above prevents the end recipient from extracting the CC-BY
licensed content and exercising their rights *on the CC-BY licensed
content*. You do not have rights to modify the collective work unless I
grant them to you. So your rights on the collective work can be less than
your rights on the individual components provided that I provided I provide
a means for you to exercise your rights on those individual components *as*
individual components.
Where I see a difference is that you seem to be implying that the CC-BY
rights *on the CC-BY licensed content* mean that you are allowed to modify
the CC-BY content *within the collective work*.
Let's take the icons example...
I see some lovely icons and they are CC-BY licensed.
I need to modify one of the icons to fit my look and feel.
I bundle the whole into an windows.exe with DRM up the wazoo.
My installer (which is what I distribute) will put on your system the .exe
and a .zip with the icons (both the ones I use unmodified and the ones I
modified) and the CC-BY attribution, etc. Also the .exe's About window
gives an URL to the attribution requirements.
Tell me now how your rights under CC-BY are restricted by my DRM on my
collective work?
-Stephen
>
>
> Jeff
> Counsel, IBM Software Group
>
>
>
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 07:52:07 PM:
> Jeffrey Thompson wrote:
> > We've had this discussion before. The Apache license does not say
> > that it must become a part of the license under which the Apache
> > user licenses the resulting product to its customer. It merely
> states that
> > a copy of the Apache license needs to be provided. This was part of
the
> > design.
> Which design are you referring to? I'm reading the OSD....
>
> The Apache License applies to all works distributed by ASF. A
> contributor's license applies to her contributions included in that
> Apache work. There is nothing that a downstream licensor can do to
> change that short of requesting new licenses from the licensors.
Right. If you don't want to receive the code under the Apache license, you
need to talk to the copyright owners and get a separate license. I'm not
sure what that has to do with our conversation, though.
>
> > There is no general copyright principle that says that a licensee has
> > to pass on all rights that it received from its licensor. If you
> can provide
> > a cite to one, please do.
>
> How does IBM avoid passing on those rights?
I didn't say that one could distribute the code without passing on ANY
rights. I said one is allowed to distribute the code without passing on
ALL OF the rights.
> The second sentence of
> 17 USC 103(b) says: "The copyright in [compilations and derivative
> works] is independent of, and does not affect or enlarge the scope,
> duration, ownership, or subsistence of, any copyright protection in
> the preexisting material [e.g., contributions]."
I'm saying that, broadly speaking, there are 2 types of OSS licenses --
ones which don't necessarily require you to change your pre-existing
licenses and ones that do. Apache, MIT, BSD, EPL (for executables, not
source), etc. are in the former camp. GPL, CC-BY, etc. are in the latter.
Is your point that because the copyright in the derivative work is
separate, you are free to ignore those provisions of the GPL and CC-BY and
distribute your derivative work under your own license terms (e.g., without
stating that certain components are licensed to you under the GPL)?
If that's not your point, I can't understand why you're quoting this
statute.
>
> There is also an Apache License provision that says almost the same
> thing. Richard Fontana quoted section 4d:
>
> You ... may provide additional or different license terms and
> conditions for use, reproduction, or distribution of Your
> modifications, or for any such Derivative Works as a whole, provided
> Your use, reproduction, and distribution of the Work otherwise
> complies with the conditions stated in this License.
You may provide your derivative works (to your customers) under your own
terms. Great, that's what I'm saying.
... provided you comply with the conditions in the license. Fine. What's
the condition that the distribution would not be complying with by using
its own terms?
There are no conditions in section 1.
There are no conditions in section 2.
Last sentence of section 3 could be interpreted as a condition, but its
really just a limitation on the patent grant n the prior sentence. In any
event, it would not be a condition that turns on the user's outbound
license.
Section 4 -- has conditions.
4.1. Give a copy of the Apache license -- check. No obligation to change
the pre-existing license agreement.
4.2. Mark modifications -- check
4.3. Retain notices in the source -- check
4.4 Retain Notices file -- check
Section 5, contributions -- not relevant here
Section 6, trademarks -- not relevant here
Section 7, warranty -- not relevant here
Section 8, liability -- not relevant here
Section 9, adding warranty terms -- not a condition, but an explicit
permission -- and doesn't relate to the outbound licensing terms.
I'm out of license. I don't see any condition that requires a distributor
to modify its outbound license.
> This is not a big burden for Apache licensees, because the
> conditions we impose are minimal. See section 4 of the license.
> Almost anyone can satisfy those conditions trivially. The same easy
> implementation can be said for the BSD and CC-BY licenses.
CC-BY says "You may not offer or impose ... different terms ... to the
Licensed Material if doing so restricts exercise of the Licensed Rights."
That sentence explicitly places a requirement on the outbound license which
will likely not be satisfied by most commercial licenses since most
commercial licenses prohibit modification and redistribution. There is NO
equivalent provision in BSD or Apache.
> The conditions you impose on your customers are your own
> business, and you are free to wrap our Apache software, along with
> your own software, under any license you choose.
If "wrapping" means applying terms to the original parts of the combined
work, while passing thru the Apache license for the Apache works, it is
certainly possible to craft a license that does that. In effect, it would
say "Here, Mr. Customer, is a license that covers 90% of the work and this
Apache license covers this part over here." But, that's not commercially
reasonable for long term software agreements that cover multiple products
and multiple versions of products. You don't know that Apache/BSD/CC-BY
components are going to be in the products yet since some of them may not
have been developed.
Customers react poorly to the concept that the supplier can change its
software license after the agreement is signed merely because the supplier
decided to include an OSS component. So, while logically it works that the
supplier could have a license that says that certain terms apply "unless I
say otherwise", its not going to be generally acceptable to customers.
> Again, I don't know why you and Luis are complaining about CC-BY.
> The GPLv3's DRM conditions are far more strict than those of CC-BY.
> Nothing in CC-BY requires the disclosure of "complete corresponding
> source code" nor even the "source code" at all.
I haven't addressed the DRM conditions.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Thu, Dec 05, 2013 at 07:18:48AM -0500, Jeffrey Thompson wrote:
> The Apache license does not say that you can pass on fewer rights. It doesn't
> have to. That's the normal case. You only have to address that issue when you
> want to require the licensee to include all of the rights.
Cite please!
> And there's the explicit permission to use your own terms for your derivative
> work as long as you are in compliance with the conditions of the Apache license
> -- a reference to the notice requirement, not removing copyright and other
> notifications, etc. This is about as clear as you can get that a commercial
> user doesn't need to change their outbound license.
But as I noted in another response, it is curious that that clause in
the Apache License 2.0 refers only to 'Derivative Works', and not to
'the Work'.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 10:19:00 PM:
> From: Richard Fontana <rf...@redhat.com>
> To: legal-discuss@apache.org, lrosen@rosenlaw.com,
> Date: 12/04/2013 10:19 PM
> Subject: Re: New versions of CC licenses
>
> On Wed, Dec 04, 2013 at 04:52:07PM -0800, Lawrence Rosen wrote:
> > Jeffrey Thompson wrote:
> >
> > > There is no general copyright principle that says that a licensee has
> > > to pass on all rights that it received from its licensor. If
> you can provide
> > > a cite to one, please do.
> >
> > How does IBM avoid passing on those rights?
>
> ... the issue
> depends on the specific license, does it not?
Yes, it does. That's my point. The CC-BY license (and the GPL) says that
you have to pass on all rights, The Apache license does not.
> It is not clear to me
> where in the Apache License 2.0 permission is granted to a licensee to
> pass on fewer than all the rights it received from its licensor as to
> the work which the licensor licensed.
The Apache license does not say that you can pass on fewer rights. It
doesn't have to. That's the normal case. You only have to address that
issue when you want to require the licensee to include all of the rights.
> (Or maybe I should say the
> better interpretation of the Apache License 2.0 seems to be that it
> does not.)
I would agree with you if there was a sentence that said something close to
that in the Apache license. There is the requirement that you provide a
copy of the Apache license, which is a "notice" requirement, not a
licensing one.
And there's the explicit permission to use your own terms for your
derivative work as long as you are in compliance with the conditions of the
Apache license -- a reference to the notice requirement, not removing
copyright and other notifications, etc. This is about as clear as you can
get that a commercial user doesn't need to change their outbound license.
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Wed, Dec 04, 2013 at 04:52:07PM -0800, Lawrence Rosen wrote:
> Jeffrey Thompson wrote:
>
> > There is no general copyright principle that says that a licensee has
> > to pass on all rights that it received from its licensor. If you can provide
> > a cite to one, please do.
>
> How does IBM avoid passing on those rights?
I believe Jeffrey is correct about general principle, but the issue
depends on the specific license, does it not? It is not clear to me
where in the Apache License 2.0 permission is granted to a licensee to
pass on fewer than all the rights it received from its licensor as to
the work which the licensor licensed. (Or maybe I should say the
better interpretation of the Apache License 2.0 seems to be that it
does not.)
- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeffrey Thompson wrote:
> We've had this discussion before. The Apache license does not say
> that it must become a part of the license under which the Apache
> user licenses the resulting product to its customer. It merely states
that
> a copy of the Apache license needs to be provided. This was part of the
> design.
Which design are you referring to? I'm reading the OSD....
The Apache License applies to all works distributed by ASF. A contributor's
license applies to her contributions included in that Apache work. There is
nothing that a downstream licensor can do to change that short of requesting
new licenses from the licensors.
> There is no general copyright principle that says that a licensee has
> to pass on all rights that it received from its licensor. If you can
provide
> a cite to one, please do.
How does IBM avoid passing on those rights? The second sentence of 17 USC
103(b) says: "The copyright in [compilations and derivative works] is
independent of, and does not affect or enlarge the scope, duration,
ownership, or subsistence of, any copyright protection in the preexisting
material [e.g., contributions]."
There is also an Apache License provision that says almost the same thing.
Richard Fontana quoted section 4d:
You ... may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or for any
such Derivative Works as a whole, provided Your use, reproduction, and
distribution of the Work otherwise complies with the conditions stated in
this License.
This is not a big burden for Apache licensees, because the conditions we
impose are minimal. See section 4 of the license. Almost anyone can satisfy
those conditions trivially. The same easy implementation can be said for the
BSD and CC-BY licenses.
> Let me ask you this, IBM creates and licenses development tools to
> its customers under the IPLA (a proprietary license which is named
> the International Program License Agreement)....
I've never compared the Apache License to IBM's proprietary International
Program License Agreement (IPLA) and I'm confused that you did. The
conditions you impose on your customers are your own business, and you are
free to wrap our Apache software, along with your own software, under any
license you choose. I've advised many clients to do similar things,
including wrapping combinations of Apache and GPL software under other
proprietary or FOSS licenses! All I'd insist is that your customers must be
informed about the presence of ASF software in your products, and those ASF
components must be distributed in accordance with section 4 of the Apache
License. Just as the BSD components you use must be distributed in
accordance with the conditions of the BSD license. Or CC-BY components and
GPL components, each in accordance with its own license.
> BTW, this is the entire basis of the FSF's concept of GPL-compatibility.
> A license is compatible with the GPL if it provides at least
GPL-equivalent
> rights and therefore someone can take code under that license and
> license it outbound under the GPL. Whether we think that making
> things GPL-compatible is a good idea, the existence of the concept
> of GPL-compatible licenses proves that Larry is incorrect.
I should refrain from repeating what I've said for years: The concept of
GPL-compatible licenses is a lot of nonsense relating to creating derivative
works through linking. In all other respects, the GPL licenses are
wonderfully compatible with all other FOSS licenses. Such works can be
included in FOSS or proprietary collective works without concern, as long as
the notice and source code requirements of the GPL components (and their
derivative works!) are honored.
The fundamental concept of FOSS licenses is that you can copy, modify and
distribute such works merely by satisfying a simple set of conditions,
mostly requiring that you provide notice, along with (in some cases) source
code for THOSE WORKS (and derivative works?). DRM can be used to protect
your own proprietary code, but not to shield free FOSS works from your
customers who are entitled to see them.
Again, I don't know why you and Luis are complaining about CC-BY. The
GPLv3's DRM conditions are far more strict than those of CC-BY. Nothing in
CC-BY requires the disclosure of "complete corresponding source code" nor
even the "source code" at all. All it requires is a notice - and an
agreement to remove that notice if requested. How would that affect your
proprietary licenses in any way? How would it affect your use of DRM to
protect your own proprietary software from disclosure?
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Wednesday, December 04, 2013 2:31 PM
To: legal-discuss@apache.org
Cc: Lawrence Rosen
Subject: RE: New versions of CC licenses
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 01:49:02 PM:
> No. The Apache License 2.0 license is /also/ carried forward
> verbatim in the commercial licensor's license to its customer. As
> are the licenses of /each of the components/ in that Apache work.
Larry,
We've had this discussion before. The Apache license does not say that
it must become a part of the license under which the Apache user licenses
the resulting product to its customer. It merely states that a copy of the
Apache license needs to be provided. This was part of the design.
>
> You can't undo a copyright owner's license by slapping your own
> proprietary license on top of it.
There is no general copyright principle that says that a licensee has to
pass on all rights that it received from its licensor. If you can provide a
cite to one, please do.
Let me ask you this, IBM creates and licenses development tools to its
customers under the IPLA (a proprietary license which is named the
International Program License Agreement). For the tools that embed runtimes
in the developed applications, the terms of the license permit
redistribution of those runtimes in your application. Is it really your
position that IBM customers must incorporate the IPLA into their outbound
licenses? If they also use Microsoft and Oracle development tools, do they
need to include the licenses from those vendors, as well? This would be
news to the entire software industry.
Jeff
>
> /Larry
>
RE: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 12/04/2013 01:49:02 PM:
> No. The Apache License 2.0 license is /also/ carried forward
> verbatim in the commercial licensor's license to its customer. As
> are the licenses of /each of the components/ in that Apache work.
Larry,
We've had this discussion before. The Apache license does not say
that it must become a part of the license under which the Apache user
licenses the resulting product to its customer. It merely states that a
copy of the Apache license needs to be provided. This was part of the
design.
>
> You can't undo a copyright owner's license by slapping your own
> proprietary license on top of it.
There is no general copyright principle that says that a licensee has to
pass on all rights that it received from its licensor. If you can provide
a cite to one, please do.
Let me ask you this, IBM creates and licenses development tools to its
customers under the IPLA (a proprietary license which is named the
International Program License Agreement). For the tools that embed
runtimes in the developed applications, the terms of the license permit
redistribution of those runtimes in your application. Is it really your
position that IBM customers must incorporate the IPLA into their outbound
licenses? If they also use Microsoft and Oracle development tools, do they
need to include the licenses from those vendors, as well? This would be
news to the entire software industry.
Jeff
>
> /Larry
>
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff Thompson wrote:
> At least from a potential commercial user's perspective,
> Section 2.a.5.B effectively requires carrying forward
> the CC license terms verbatim in the user's license to
> its customer.
> Isn't that a problem from an Apache licensing policy
> perspective?
No. The Apache License 2.0 license is /also/ carried forward verbatim in the
commercial licensor's license to its customer. As are the licenses of /each
of the components/ in that Apache work.
You can't undo a copyright owner's license by slapping your own proprietary
license on top of it.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Wednesday, December 04, 2013 7:03 AM
To: legal-discuss@apache.org
Cc: Lawrence Rosen; luis.villa@gmail.com
Subject: Re: New versions of CC licenses
Luis,
luis.villa@gmail.com wrote on 12/04/2013 01:56:04 AM:
> As I believe I've noted here before, CC (4.0 and earlier) has an
> anti-DRM provision that makes it a poor fit for the embedded/mobile
> space
. . .
> there is nothing else in 4.0 that would be
> problematic.
>
> Luis
>
I'm not sure I agree with that summary. The anti-DRM provision is more than
just a "no-technological measures" requirement. At least from a potential
commercial user's perspective, Section 2.a.5.B effectively requires carrying
forward the CC license terms verbatim in the user's license to its customer.
Isn't that a problem from an Apache licensing policy perspective?
The gist of Apache's policy has been that as long as you're passing on the
notices and otherwise complying with the license, its not a problem if the
user's commercial terms with their customers are different from the Apache
license (for example, most commercial licenses prohibit modification, or at
least void warranties and support, etc if the code is modified). Wouldn't
anything that changes that basic understanding be problematic (e.g., you
MUST grant all of the rights that you received)?
Jeff
Counsel, IBM Corporation
RE: New versions of CC licenses
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Jeff and Luis,
I don't understand why you object to the anti-DRM (e.g., "TPM" or "Effective
Technical Measures" in CC terminology) provisions in the CC licenses.
The specific provision in CC-BY says this: "You may not impose any effective
technological measures on the Work that restrict the ability of a recipient
of the Work from You to exercise the rights granted to that recipient under
the terms of the License."
See http://wiki.creativecommons.org/4.0/Technical_protection_measures.
I like that provision insofar as it applies to CC-BY components in any work.
THOSE COMPONENTS are under the CC-BY license, and no proprietary vendor
should lock THOSE COMPONENTS away under a DRM shield. This can be handled
conveniently by the proprietary vendor posting attribution notices of the
CC-BY works on its website. [1] Nothing else needs to be disclosed!
It would be helpful if you could specifically address the points raised on
the above-referenced CC wiki rather than simply say "I don't like provisions
that prevent DRM...."
/Larry
[1] "The licenses explicitly permit licensees to satisfy the attribution
requirement with a link to a separate page for attribution information." See
http://creativecommons.org/Version4.
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
<http://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: Wednesday, December 04, 2013 7:03 AM
To: legal-discuss@apache.org
Cc: Lawrence Rosen; luis.villa@gmail.com
Subject: Re: New versions of CC licenses
Luis,
luis.villa@gmail.com wrote on 12/04/2013 01:56:04 AM:
> As I believe I've noted here before, CC (4.0 and earlier) has an
> anti-DRM provision that makes it a poor fit for the embedded/mobile
> space
. . .
> there is nothing else in 4.0 that would be
> problematic.
>
> Luis
>
I'm not sure I agree with that summary. The anti-DRM provision is more than
just a "no-technological measures" requirement. At least from a potential
commercial user's perspective, Section 2.a.5.B effectively requires carrying
forward the CC license terms verbatim in the user's license to its customer.
Isn't that a problem from an Apache licensing policy perspective?
The gist of Apache's policy has been that as long as you're passing on the
notices and otherwise complying with the license, its not a problem if the
user's commercial terms with their customers are different from the Apache
license (for example, most commercial licenses prohibit modification, or at
least void warranties and support, etc if the code is modified). Wouldn't
anything that changes that basic understanding be problematic (e.g., you
MUST grant all of the rights that you received)?
Jeff
Counsel, IBM Corporation
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Richard Fontana <rf...@redhat.com> wrote on 12/04/2013 11:29:42 AM:
> On Wed, Dec 04, 2013 at 10:03:17AM -0500, Jeffrey Thompson wrote:
> > I'm not sure I agree with that summary. The anti-DRM provision ismore
than
> > just a "no-technological measures" requirement. At least from a
potential
> > commercial user's perspective, Section 2.a.5.B effectively requires
carrying
> > forward the CC license terms verbatim in the user's license to
itscustomer.
> > Isn't that a problem from an Apache licensing policy perspective?
>
> That's arguably true of the BSD licenses too, and the Apache License
> 2.0 itself.
>
How is that arguably true for either of those licenses? I don't see
anything in the Apache or the BSD license that requires a commercial user
to change their licensing terms with their customer. The requirement that
the copy of the original license be included with the software doesn't do
that. Depending on how the exact language of the license is interpreted in
accordance with local copyright law, it could mean (a) that its a mere
notice of the terms under which the commercial user received the code or
(b) documentation of the rights that flow from the original author directly
to the customer. But, how could it mean that the separately negotiated
license between the commercial user and their customer is somehow invalid?
Jeff
Counsel, IBM Software Group
Re: New versions of CC licenses
Posted by Richard Fontana <rf...@redhat.com>.
On Wed, Dec 04, 2013 at 10:03:17AM -0500, Jeffrey Thompson wrote:
> Luis,
>
> luis.villa@gmail.com wrote on 12/04/2013 01:56:04 AM:
>
> > As I believe I've noted here before, CC (4.0 and earlier) has an
> > anti-DRM provision that makes it a poor fit for the embedded/mobile
> > space
> . . .
> > there is nothing else in 4.0 that would be
> > problematic.
> >
> > Luis
> >
> I'm not sure I agree with that summary. The anti-DRM provision is more than
> just a "no-technological measures" requirement. At least from a potential
> commercial user's perspective, Section 2.a.5.B effectively requires carrying
> forward the CC license terms verbatim in the user's license to its customer.
> Isn't that a problem from an Apache licensing policy perspective?
That's arguably true of the BSD licenses too, and the Apache License 2.0 itself.
- RF
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: New versions of CC licenses
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
Luis,
luis.villa@gmail.com wrote on 12/04/2013 01:56:04 AM:
> As I believe I've noted here before, CC (4.0 and earlier) has an
> anti-DRM provision that makes it a poor fit for the embedded/mobile
> space
. . .
> there is nothing else in 4.0 that would be
> problematic.
>
> Luis
>
I'm not sure I agree with that summary. The anti-DRM provision is more
than just a "no-technological measures" requirement. At least from a
potential commercial user's perspective, Section 2.a.5.B effectively
requires carrying forward the CC license terms verbatim in the user's
license to its customer. Isn't that a problem from an Apache licensing
policy perspective?
The gist of Apache's policy has been that as long as you're passing on the
notices and otherwise complying with the license, its not a problem if the
user's commercial terms with their customers are different from the Apache
license (for example, most commercial licenses prohibit modification, or at
least void warranties and support, etc if the code is modified). Wouldn't
anything that changes that basic understanding be problematic (e.g., you
MUST grant all of the rights that you received)?
Jeff
Counsel, IBM Corporation
Re: New versions of CC licenses
Posted by Luis Villa <lu...@lu.is>.
On Fri, Nov 29, 2013 at 9:38 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> I wish we listed CC-BY as an acceptable license for inclusion in Apache
> works.
As I believe I've noted here before, CC (4.0 and earlier) has an
anti-DRM provision that makes it a poor fit for the embedded/mobile
space - a common use case for Apache projects these days. So I'm not
sure it belongs in "category A". That said, if the decision has
already been made to overlook that clause (which apparently it has
been for 2.5 and 3.0) there is nothing else in 4.0 that would be
problematic.
Luis
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org