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:33:09 GMT
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?

-Stephen


>
>
> Jeff
> Counsel, IBM Software Group
>
>
>

Mime
View raw message