www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: New versions of CC licenses
Date Thu, 05 Dec 2013 14:37:03 GMT
On 5 December 2013 14:33, Stephen Connolly
<stephen.alan.connolly@gmail.com>wrote:

>
>
>
> On 5 December 2013 13:55, Jeffrey Thompson <jthom@us.ibm.com> wrote:
>
>> "Lawrence Rosen" <lrosen@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
>>
>>
>>
>

Mime
View raw message