www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: New versions of CC licenses
Date Fri, 06 Dec 2013 21:14:29 GMT
On Fri, Dec 6, 2013 at 3:31 PM, Lawrence Rosen <lrosen@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

Mime
View raw message