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 2015/05/10 20:32:01 UTC

Proposal: Apache Third Party License Policy

DRAFT: Apache Third Party License Policy (May 10, 2015)

 

Apache projects have long been universal donors to many other software
projects around the world. We are proud of that. We intend to continue that
tradition by requiring that all software aggregations distributed by Apache
Software Foundation will be licensed to the public under the Apache License
2.0. This means that all of our licensees around the world are free to:

 

*         Use Apache software for any purpose.

*         Make and distribute copies.

*         Create and distribute derivative works.

*         Access and use the source code.

*         Combine Apache and other software.

 

In order to foster our Foundation community ethic to ensure the widest free
participation in the open source software community, Apache has now decided
to become also a universal acceptor of other open source software licensed
to us from around the world. 

 

When technically appropriate for that software in the judgment of the PMC,
Apache projects may accept contributions under ANY OSI-approved open source
license. Such software may now be included in Apache aggregations that, as
described above, will be licensed to the public under Apache License 2.0.

 

Because Apache projects may now incorporate third party open source software
into our software aggregations, we have added the following procedures for
Apache software releases:

 

*         Because all Apache project contributions will be licensed to
Apache under an OSI-approved open source license, the above list of five
fundamental software freedoms continues to apply to all Apache software.
Downstream users and re-distributors of Apache software can continue to
incorporate all of our open source software into their own products
unmodified without incurring any special derivative work reciprocity
obligations.

 

*         All releases containing any non-Apache open source licensed
contributions will be explicitly identified in a NOTICE file that our
projects will create. The PMC is responsible to ensure that the text in the
NOTICE file expressly satisfies the notice and disclosure requirements of
all relevant contribution licenses.

 

*         Modifiers and re-distributors of Apache software will now need to
read the NOTICE files to determine whether they have any derivative work
reciprocity requirements for specific contributions. 

 

You may influence the inclusion or exclusion of specific third party
contributions under OSI-approved licenses by joining the Apache project. All
such decisions are made by Apache projects in public.


Re: [SPAM?] Proposal: Apache Third Party License Policy

Posted by Chris Mattmann <ma...@apache.org>.
+1 I was going to say the same thing. Legal-discuss is public,
whereas legal-internal isn’t I think we should discuss on legal-discuss@
and/or JIRA.

Cheers,
Chris



-----Original Message-----
From: Sam Ruby <ru...@intertwingly.net>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Sunday, May 10, 2015 at 12:02 PM
To: Legal Discuss <le...@apache.org>
Subject: Re: [SPAM?] Proposal: Apache Third Party License Policy

>On Sun, May 10, 2015 at 2:43 PM, Shane Curcuru <as...@shanecurcuru.org>
>wrote:
>> (members@ -> bcc)
>>
>> A note to readers: the proper place to bring a suggested change to the
>> ASF's long-held licensing policy is to the Legal Affairs list, not to
>> legal-discuss@.
>
>Actually, this is a fine list to discuss proposals.  I'd also suggest
>the use of JIRA: https://issues.apache.org/jira/browse/legal
>
>- Sam Ruby
>
>---------------------------------------------------------------------
>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: [SPAM?] Proposal: Apache Third Party License Policy

Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, May 10, 2015 at 2:43 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> (members@ -> bcc)
>
> A note to readers: the proper place to bring a suggested change to the
> ASF's long-held licensing policy is to the Legal Affairs list, not to
> legal-discuss@.

Actually, this is a fine list to discuss proposals.  I'd also suggest
the use of JIRA: https://issues.apache.org/jira/browse/legal

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [SPAM?] Proposal: Apache Third Party License Policy

Posted by Shane Curcuru <as...@shanecurcuru.org>.
(members@ -> bcc)

A note to readers: the proper place to bring a suggested change to the
ASF's long-held licensing policy is to the Legal Affairs list, not to
legal-discuss@.

Separately, the below email is merely a proposal by a *single* Apache
community member, and in no way represents official policy at the ASF.
In particular, Apache projects are reminded to follow the official third
party licensing policy, which remains unmodified:

  http://www.apache.org/legal/resolved.html#category-a

- Shane


On 5/10/15 2:32 PM, Lawrence Rosen wrote:
> DRAFT: Apache Third Party License Policy (May 10, 2015)
> 
>  
> 
> Apache projects have long been */universal donors/*//to many other
> software projects around the world. We are proud of that. We intend to
> continue that tradition by requiring that all software aggregations
> distributed by Apache Software Foundation will be licensed to the public
> under the *Apache License 2.0*. This means that all of our licensees
> around the world are free to:
> 
>  
> 
> ·         Use Apache software for any purpose.
> 
> ·         Make and distribute copies.
> 
> ·         Create and distribute derivative works.
> 
> ·         Access and use the source code.
> 
> ·         Combine Apache and other software.
> 
>  
> 
> In order to foster our Foundation community ethic to ensure the widest
> free participation in the open source software community, Apache has now
> decided to become also a */universal acceptor/* of other open source
> software licensed to us from around the world.
> 
>  
> 
> When technically appropriate for that software in the judgment of the
> PMC, Apache projects may accept contributions under ANY OSI-approved
> open source license. Such software may now be included in Apache
> aggregations that, as described above, will be licensed to the public
> under *Apache License 2.0*.
> 
>  
> 
> Because Apache projects may now incorporate third party open source
> software into our software aggregations, we have added the following
> procedures for Apache software releases:
> 
>  
> 
> ·         Because all Apache project contributions will be licensed to
> Apache under an OSI-approved open source license, the above list of five
> fundamental software freedoms continues to apply to all Apache software.
> Downstream users and re-distributors of Apache software can continue to
> incorporate all of our open source software into their own products
> *_unmodified_* without incurring any special derivative work reciprocity
> obligations.
> 
>  
> 
> ·         All releases containing any non-Apache open source licensed
> contributions will be explicitly identified in a NOTICE file that our
> projects will create. The PMC is responsible to ensure that the text in
> the NOTICE file expressly satisfies the notice and disclosure
> requirements of all relevant contribution licenses.
> 
>  
> 
> ·         *_Modifiers_*and re-distributors of Apache software will now
> need to read the NOTICE files to determine whether they have any
> derivative work reciprocity requirements for specific contributions.
> 
>  
> 
> You may influence the inclusion or exclusion of specific third party
> contributions under OSI-approved licenses by joining the Apache project.
> All such decisions are made by Apache projects in public.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: Proposal: Apache Third Party License Policy

Posted by Henri Yandell <ba...@apache.org>.
On Sun, May 10, 2015 at 11:32 AM, Lawrence Rosen <lr...@rosenlaw.com>
wrote:

> DRAFT: Apache Third Party License Policy (May 10, 2015)
>
>
>
> Apache projects have long been *universal donors* to many other software
> projects around the world. We are proud of that. We intend to continue that
> tradition by requiring that all software aggregations distributed by Apache
> Software Foundation will be licensed to the public under the *Apache
> License 2.0*. This means that all of our licensees around the world are
> free to:
>
>
>
> ·         Use Apache software for any purpose.
>
> ·         Make and distribute copies.
>
> ·         Create and distribute derivative works.
>
> ·         Access and use the source code.
>
> ·         Combine Apache and other software.
>
>
>
> In order to foster our Foundation community ethic to ensure the widest
> free participation in the open source software community, Apache has now
> decided to become also a *universal acceptor* of other open source
> software licensed to us from around the world.
>
>
>
> When technically appropriate for that software in the judgment of the PMC,
> Apache projects may accept contributions under ANY OSI-approved open source
> license.
>

In practice this should be more generic than 'ANY OSI-approved'; i.e. there
should be a list of acceptable licenses which starts with "Any
OSI-approved' as the first item in the list. I wonder what wouldn't be on a
"you can incorporate" list.



> Such software may now be included in Apache aggregations that, as
> described above, will be licensed to the public under *Apache License 2.0*
> .
>

Does 'included' include 'requires'? Example being maven/rubygem/pypi builds
that install 3rd party software behind the scenes, and from a 3rd party,
due to instructions from an Apache product?


>
>
> Because Apache projects may now incorporate third party open source
> software into our software aggregations, we have added the following
> procedures for Apache software releases:
>
·         Because all Apache project contributions will be licensed to
> Apache under an OSI-approved open source license, the above list of five
> fundamental software freedoms continues to apply to all Apache software.
> Downstream users and re-distributors of Apache software can continue to
> incorporate all of our open source software into their own products
> *unmodified* without incurring any special derivative work reciprocity
> obligations.
>
>
I think you should emphasize the last 8 words. For Apache, those are more
important than the unmodified. We open source everything, so having to open
source a small amount under a different license isn't a huge deal. Finding
that the primary Apache licensed source is under a different license is a
much bigger deal.


>
>
> ·         All releases containing any non-Apache open source licensed
> contributions will be explicitly identified in a NOTICE file that our
> projects will create. The PMC is responsible to ensure that the text in the
> NOTICE file expressly satisfies the notice and disclosure requirements of
> all relevant contribution licenses.
>
>
>

Presumably they will also provide the 3rd party source when required to?
Will that be within the Apache source or should infra and/or legal pmc
manage a separate download location for required 3rd party source?


> ·         *Modifiers* and re-distributors of Apache software will now
> need to read the NOTICE files to determine whether they have any derivative
> work reciprocity requirements for specific contributions.
>
>
I recommend having Infra and/or Legal PMC automate a requirement that every
download must have a NOTICE file. Including jar files or other binaries
sent to 3rd party download locations.


>
>
> You may influence the inclusion or exclusion of specific third party
> contributions under OSI-approved licenses by joining the Apache project.
> All such decisions are made by Apache projects in public.
>

'contributions' seems odd here. I'd read that as a change to an Apache
owned piece of code, not aggregation of some other license.

If this is specific to Apache Open Office and MPL 2.0, why not start by
putting something in place specific for that project and license
combination.

Hen

RE: Proposal: Apache Third Party License Policy

Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
One reason why Apache communities are strong is because we have consistency in our policies across all projects. The licensing policy tells me that, as an adopter of ASF code, I can make any modifications I need to, whether in ASF code or in a dependency, and I will not trigger a reciprocity clause.

The critical thing here is "whether in ASF code or a dependency".

Under this proposal this important community benefit goes away. At the ASF we are for community over code. When considering adjustments to our existing policies we should not forget this.

Furthermore, under this proposal, where individual PMCs decide on local policy, we end up with some ASF projects not being able to use some other ASF code. Since our foundation is a "community if communities" we should be wary of such a policy change which creates barriers between our communities.

I find the proposal in its current form unacceptable for these reasons. That said,  if a specific project has a specific issue it wants to address then we should discuss that issue rather than a broad sweeping policy that undermines the very foundations of our foundation.

Ross



Sent from my Windows Phone
________________________________
From: Lawrence Rosen<ma...@rosenlaw.com>
Sent: ‎5/‎10/‎2015 7:35 PM
To: legal-discuss@apache.org<ma...@apache.org>
Cc: Lawrence Rosen<ma...@rosenlaw.com>
Subject: RE: Proposal: Apache Third Party License Policy

Don't be scared, Brane. I'm not trying to get you or Apache involved in some lawsuit. If YOU are afraid of the GPL, then don't incorporate such components in your projects. But don't dictate a GPL policy for MY project. Point of evidence: AOO already includes GPL dictionaries in its distributed Apache software. I bet nobody gives a damn.

/Larry


From: Branko ?ibej [mailto:brane@apache.org]
Sent: Sunday, May 10, 2015 7:11 PM
To: legal-discuss@apache.org
Subject: Re: Proposal: Apache Third Party License Policy

On 11.05.2015 00:58, Lawrence Rosen wrote:
Branko ?ibej wrote:
> GPLv3 is an OSI-approved license.

Yes it is. I was wondering when someone here would notice that and blare at me with red eyes!  :-)

1. It is not up to me but to the PMC itself to determine that a GPLv3 component would be useful in an Apache project. My personal standard is: Technical value to the project, not which open source license was applied by that third party contributor/licensor. All these licenses, including GPLv3, are FREE, so users won't care (nor most even notice).

I'm not interested in the technical aspects; that's not what we're discussing here.


2. Most copyright attorneys recognize that the mere incorporation of a copy of a GPLv3 component into an aggregation does not affect the aggregation's license regardless of some GPL folklore.

Now I'm scared. Waving away as "folklore" what has been the published intent and and policy of the FSF since its inception seems like a rather cavalier attitude.

Did I misunderstand what I've been told for decades, that, effectively, what most copyright attorneys recognize is irrelevant until proved in court? And do you think the ASF wants to be involved in a turf war over licensing in the open source world?



Fear should not dominate our general policy. Last week I passed along a note describing a project by Jim Wright (Oracle), Richard Fontana (HP), and other lawyers to eliminate much GPL fear by a simple declaration by reasonable licensors to the effect that "incorporation into any open source project is fine with them." Stand by for intelligent suggestions from people who are going to tame the GPL for Apache.

Any licensor has always had the option to use whatever license they please, including modifying or adding exceptions to the GPL. If Oracle or HP (or Mozilla or Eclipse or younameit) want to make their open source stuff more Apache-friendly, more power to them; and they can just use ALv2. But there are thousands of open-source projects out there and a significant proportion of them use copyleft-like licenses. Do you really think it's in our interest to tell all those people that we don't care what they've been told their license means? Surely the ASF doesn't want to become the bull in the FLOSS china shop.

-- Brane

RE: Proposal: Apache Third Party License Policy

Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Please don't insult, Brane. I'm not a troll. I am an elected member of Apache Software Foundation and an experienced open source attorney. I'm not speaking for Apache, but I am speaking about Apache. Nobody is required to agree with me.  But neither can YOU dictate a Third Party License Policy that is unsuitable for MY Apache projects (whatever those may be). Somehow we need to discuss Apache policy without personal attacks and learn to compromise based on logic.

 

If you don't like the GPL for some reason, then take that argument to YOUR Apache projects and reach your own consensus. (Those who know me well realize that I'm not a GPL fan!) But don't rely on the DRAFT Apache Third Party License Policy to prevent the rest of us from doing what we find technically useful when our PMCs agree to it and we document it in our NOTICE file.

 

Isn't that in accord with The Apache Way?

 

/Larry

 

 

From: Branko Čibej [mailto:brane@apache.org] 
Sent: Sunday, May 10, 2015 7:54 PM
To: legal-discuss@apache.org
Subject: Re: Proposal: Apache Third Party License Policy

 

On 11.05.2015 04:35, Lawrence Rosen wrote:

Don't be scared, Brane. I'm not trying to get you or Apache involved in some lawsuit. If YOU are afraid of the GPL, then don't incorporate such components in your projects. But don't dictate a GPL policy for MY project.


That's so funny. So basically you're saying that your 3rd-party license policy was just a troll. Thanks for sharing.

-- Brane


Re: Proposal: Apache Third Party License Policy

Posted by Brian Fox <br...@infinity.nu>.
On Mon, May 11, 2015 at 6:19 AM, Ted Dunning <te...@gmail.com> wrote:
> Frankly, in working with commercial adopters of Apache software, one of the
> strongest arguments for the use of Apache licensed software is the current
> policy of not including or requiring GPL and similarly licensed
> dependencies.  Degrading this to a project by project decision would make it
> much harder for developers to get approval for incorporating Apache software
> into products.  The dialog would change from "Apache handles things for us"
> to "we have to examine everything from Apache in minute detail just like any
> project on github".
>
> In my strongly held opinion, this substantially impairs the ability of
> Apache to do what it set out to do.
>
> No matter which way the subtle legal points ought to be interpreted, the
> merest fact of debate about these points will simply cause business decision
> makers to push off.  Doubt about matters like this is highly corrosive.
>
> The key point is that, practically speaking, this corrosion makes the
> adoption of Apache software much harder and that makes Apache software far
> less valuable.

This.

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: Proposal: Apache Third Party License Policy

Posted by Ted Dunning <te...@gmail.com>.
Frankly, in working with commercial adopters of Apache software, one of the
strongest arguments for the use of Apache licensed software is the current
policy of not including or requiring GPL and similarly licensed
dependencies.  Degrading this to a project by project decision would make
it much harder for developers to get approval for incorporating Apache
software into products.  The dialog would change from "Apache handles
things for us" to "we have to examine everything from Apache in minute
detail just like any project on github".

In my strongly held opinion, this substantially impairs the ability of
Apache to do what it set out to do.

No matter which way the subtle legal points ought to be interpreted, the
merest fact of debate about these points will simply cause business
decision makers to push off.  Doubt about matters like this is highly
corrosive.

The key point is that, practically speaking, this corrosion makes the
adoption of Apache software much harder and that makes Apache software far
less valuable.




On Mon, May 11, 2015 at 11:06 AM, Branko Čibej <br...@apache.org> wrote:

>  Hi Larry,
>
> You posted a draft license policy for the ASF that would, in my opinion
> (and probably in the opinion of those who wrote it and those who use it),
> encourage ASF projects to violate one of the most widespread licenses used
> in the open source world. When I pointed that out, you basically said not
> to worry ("be afraid") because you're already looking for loopholes in the
> license.
>
> This is not about fear of the GPL but about respect for others' wishes and
> intent. Regardless of whether there is or is not such a loophole, the
> intent of the GPL, as described on innumerable occasions by the FSF, has
> always been crystal clear, and far as I'm concerned, so has the wording. It
> is IMO against the ASF's published goals to define policy by actively
> looking for ways to circumvent the provisions of this or that license;
> that's totally against the spirit of FLOSS and our proclaimed "public good"
> mandate.
>
> FWIW, I've not been trying to "dictate" anything to you. I'm just pointing
> out what I think is a fatal flaw in your proposal. If you actually have an
> interest in discussing things, you could start by not sidestepping my
> questions and telling me how copyright attorneys already have undermining
> the GPL well in hand. All this kind of response does is support the
> stereotype that lawyers have no respect for anything but their own high
> opinion of themselves.
>
> One more thing I have to respond to before I leave this conversation:
>
>  But don't rely on the DRAFT Apache Third Party License Policy to prevent the rest of us from doing what we find technically useful when our PMCs agree to it and we document it in our NOTICE file.
>
>
> 1. As far as I'm aware, there is no "DRAFT" Apache Third Party License
> Policy. There is an existing ASF policy, and there's your draft proposal
> for a different policy (which, being a proposal, is indeed irrelevant to
> PMC decisions).
>
> 2. I do expect that all PMCs follow published ASF policy. ASF projects
> should follow ASF rules; if they find them too limiting, they're always
> free to set up somewhere else.
>
> -- Brane
>

Re: Proposal: Apache Third Party License Policy

Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, May 11, 2015 at 8:59 AM, Richard Eckart de Castilho
<re...@apache.org> wrote:
> Thanks Rob :)
>
> I took a little time to dig into the other (private) lists mentioned before to get a better impression about what this is all about anyway.
>
> As far as I can tell, the scenario here appears to be different from the two that I had known and mentioned before and which Rob has kindly pointed out represent no severe problem.
>
> Actually, I now fail to see why this has been moved here in the first place. The context (apart from mentioning AOO and some MPL project) is largely lost to the reader of this list who is likely to not have been actively involved in the previous private discussions (and may like does not even have access to those). So unless somebody who feels qualified and authorized to at least outline the situation that led to the recent mails would do so, this appears to me to be quite pointless.

Let's be clear: the AOO PMC has made no such request.  If/when an
actual project makes a specific request, such a request will be
evaluated on its merits.  Until that time, it is highly unlikely that
the 3rd party license policy will be substantially changed.

That being said, "highly unlikely" is just my opinion.  Those that
have different opinions are free to make proposals.

> Just my thoughts...
>
> -- Richard

- Sam Ruby

> On 11.05.2015, at 13:36, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
>> What you describe is already in our policy:
>>
>> http://www.apache.org/legal/resolved.html#optional
>>
>> The basic point is that provided the core Apache software is actually
>> usable without the optional dependencies and not all users will need the
>> optional dependency then this is fine.
>>
>> There are many projects here at the ASF currently that do just that, the
>> core distribution does not include any licenses that go against the ASF
>> 3rd party licensing policy but they have some optional dependencies that
>> users can explicitly opt-in to use which adds functionality that relies on
>> dependencies whose licensing would otherwise affect the core distribution.
>>
>> My understanding is that however projects distribute such optional
>> components (whether via manual instructions, UI, whatever) they must make
>> sure to inform the end user of the licensing of these components.
>>
>> Rob
>
>
> ---------------------------------------------------------------------
> 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: Proposal: Apache Third Party License Policy

Posted by Richard Eckart de Castilho <re...@apache.org>.
Thanks Rob :)

I took a little time to dig into the other (private) lists mentioned before to get a better impression about what this is all about anyway.

As far as I can tell, the scenario here appears to be different from the two that I had known and mentioned before and which Rob has kindly pointed out represent no severe problem.

Actually, I now fail to see why this has been moved here in the first place. The context (apart from mentioning AOO and some MPL project) is largely lost to the reader of this list who is likely to not have been actively involved in the previous private discussions (and may like does not even have access to those). So unless somebody who feels qualified and authorized to at least outline the situation that led to the recent mails would do so, this appears to me to be quite pointless. 

Just my thoughts...

-- Richard

On 11.05.2015, at 13:36, Rob Vesse <rv...@dotnetrdf.org> wrote:

> What you describe is already in our policy:
> 
> http://www.apache.org/legal/resolved.html#optional
> 
> The basic point is that provided the core Apache software is actually
> usable without the optional dependencies and not all users will need the
> optional dependency then this is fine.
> 
> There are many projects here at the ASF currently that do just that, the
> core distribution does not include any licenses that go against the ASF
> 3rd party licensing policy but they have some optional dependencies that
> users can explicitly opt-in to use which adds functionality that relies on
> dependencies whose licensing would otherwise affect the core distribution.
> 
> My understanding is that however projects distribute such optional
> components (whether via manual instructions, UI, whatever) they must make
> sure to inform the end user of the licensing of these components.
> 
> Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: Proposal: Apache Third Party License Policy

Posted by Rob Vesse <rv...@dotnetrdf.org>.
What you describe is already in our policy:

http://www.apache.org/legal/resolved.html#optional

The basic point is that provided the core Apache software is actually
usable without the optional dependencies and not all users will need the
optional dependency then this is fine.

There are many projects here at the ASF currently that do just that, the
core distribution does not include any licenses that go against the ASF
3rd party licensing policy but they have some optional dependencies that
users can explicitly opt-in to use which adds functionality that relies on
dependencies whose licensing would otherwise affect the core distribution.

My understanding is that however projects distribute such optional
components (whether via manual instructions, UI, whatever) they must make
sure to inform the end user of the licensing of these components.

Rob

On 11/05/2015 11:51, "Richard Eckart de Castilho" <re...@apache.org> wrote:

>Hi,
>
>On 11.05.2015, at 12:06, Branko Čibej <br...@apache.org> wrote:
>
>> This is not about fear of the GPL but about respect for others' wishes
>>and intent. Regardless of whether there is or is not such a loophole,
>>the intent of the GPL, as described on innumerable occasions by the FSF,
>>has always been crystal clear, and far as I'm concerned, so has the
>>wording. It is IMO against the ASF's published goals to define policy by
>>actively looking for ways to circumvent the provisions of this or that
>>license; that's totally against the spirit of FLOSS and our proclaimed
>>"public good" mandate.
>
>My impression is, that there may be ways of dealing with GPLed code that
>does not go against the intent of the GPL and still could be considered a
>"loophole" by some.
>
>One scenario is what I mentioned before as interacting with GPLed code
>through a plugin mechanism. Consider an application is licensed under the
>ASL and it offers a plugin API. Somebody then writes a GPLed plugin based
>on that API. As far as my limited understanding goes, such a scenario is
>valid for both, the application developer and the plugin developer (might
>depend whether GPL 2 or 3 is being used). I'm not 100% sure about the end
>user though who may be violating the GPL when actually installing the
>plugin into the application so that it calls non-GPLed code at runtime,
>but my unqualified feeling is, that it should be ok (is it?).
>
>Another scenario is, that such a plugin doesn't contain any code at all,
>just a data file - and that furthermore that data file is not directly
>referred to by the ASLed application, but discovered at runtime. Again,
>with my limited understanding, I think this should be covered by the
>section on "aggregations" in the GPL.
>
>This leads me over to the comment from Ted:
>
>On 11.05.2015, at 12:19, Ted Dunning <te...@gmail.com> wrote:
>
>> Frankly, in working with commercial adopters of Apache software, one of
>>the strongest arguments for the use of Apache licensed software is the
>>current policy of not including or requiring GPL and similarly licensed
>>dependencies.  Degrading this to a project by project decision would
>>make it much harder for developers to get approval for incorporating
>>Apache software into products.  The dialog would change from "Apache
>>handles things for us" to "we have to examine everything from Apache in
>>minute detail just like any project on github".
>
>Ted mentions here the ability of third-party developers to include Apache
>software in their commercial products. But what about end users? For an
>end users, it may be perfectly ok to use an aggregation like a AOO
>distribution which would include -- say -- GPLed dictionaries (this is a
>hypothesis, I didn't go back to read the discussion on the AOO list).
>
>So we have at least some tension here between the developer and the
>end-user scenario. I personally think there should be some way to relieve
>this tension by enabling Apache to distribute clearly marked yet
>Apache-branded aggregations to end-users that may include portions that
>would otherwise be considered against policy.
>
>As Larry pointed out, I still have to read some books on the matter -
>primarily Larry's book ;) But following this kind of tension for quite a
>while now, I think that a comment from a lay person's perspective may at
>least help in generating feedback to also help lay persons better
>understand the situation. And after all, I guess that was one of the
>reasons why the discussion was moved to a public list.
>
>Cheers,
>
>-- 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: Proposal: Apache Third Party License Policy

Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi,

On 11.05.2015, at 12:06, Branko Čibej <br...@apache.org> wrote:

> This is not about fear of the GPL but about respect for others' wishes and intent. Regardless of whether there is or is not such a loophole, the intent of the GPL, as described on innumerable occasions by the FSF, has always been crystal clear, and far as I'm concerned, so has the wording. It is IMO against the ASF's published goals to define policy by actively looking for ways to circumvent the provisions of this or that license; that's totally against the spirit of FLOSS and our proclaimed "public good" mandate.

My impression is, that there may be ways of dealing with GPLed code that does not go against the intent of the GPL and still could be considered a "loophole" by some. 

One scenario is what I mentioned before as interacting with GPLed code through a plugin mechanism. Consider an application is licensed under the ASL and it offers a plugin API. Somebody then writes a GPLed plugin based on that API. As far as my limited understanding goes, such a scenario is valid for both, the application developer and the plugin developer (might depend whether GPL 2 or 3 is being used). I'm not 100% sure about the end user though who may be violating the GPL when actually installing the plugin into the application so that it calls non-GPLed code at runtime, but my unqualified feeling is, that it should be ok (is it?).

Another scenario is, that such a plugin doesn't contain any code at all, just a data file - and that furthermore that data file is not directly referred to by the ASLed application, but discovered at runtime. Again, with my limited understanding, I think this should be covered by the section on "aggregations" in the GPL.

This leads me over to the comment from Ted:

On 11.05.2015, at 12:19, Ted Dunning <te...@gmail.com> wrote:

> Frankly, in working with commercial adopters of Apache software, one of the strongest arguments for the use of Apache licensed software is the current policy of not including or requiring GPL and similarly licensed dependencies.  Degrading this to a project by project decision would make it much harder for developers to get approval for incorporating Apache software into products.  The dialog would change from "Apache handles things for us" to "we have to examine everything from Apache in minute detail just like any project on github".  

Ted mentions here the ability of third-party developers to include Apache software in their commercial products. But what about end users? For an end users, it may be perfectly ok to use an aggregation like a AOO distribution which would include -- say -- GPLed dictionaries (this is a hypothesis, I didn't go back to read the discussion on the AOO list).

So we have at least some tension here between the developer and the end-user scenario. I personally think there should be some way to relieve this tension by enabling Apache to distribute clearly marked yet Apache-branded aggregations to end-users that may include portions that would otherwise be considered against policy.

As Larry pointed out, I still have to read some books on the matter - primarily Larry's book ;) But following this kind of tension for quite a while now, I think that a comment from a lay person's perspective may at least help in generating feedback to also help lay persons better understand the situation. And after all, I guess that was one of the reasons why the discussion was moved to a public list.

Cheers,

-- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: Proposal: Apache Third Party License Policy

Posted by Branko Čibej <br...@apache.org>.
Hi Larry,

You posted a draft license policy for the ASF that would, in my opinion
(and probably in the opinion of those who wrote it and those who use
it), encourage ASF projects to violate one of the most widespread
licenses used in the open source world. When I pointed that out, you
basically said not to worry ("be afraid") because you're already looking
for loopholes in the license.

This is not about fear of the GPL but about respect for others' wishes
and intent. Regardless of whether there is or is not such a loophole,
the intent of the GPL, as described on innumerable occasions by the FSF,
has always been crystal clear, and far as I'm concerned, so has the
wording. It is IMO against the ASF's published goals to define policy by
actively looking for ways to circumvent the provisions of this or that
license; that's totally against the spirit of FLOSS and our proclaimed
"public good" mandate.

FWIW, I've not been trying to "dictate" anything to you. I'm just
pointing out what I think is a fatal flaw in your proposal. If you
actually have an interest in discussing things, you could start by not
sidestepping my questions and telling me how copyright attorneys already
have undermining the GPL well in hand. All this kind of response does is
support the stereotype that lawyers have no respect for anything but
their own high opinion of themselves.

One more thing I have to respond to before I leave this conversation:

> But don't rely on the DRAFT Apache Third Party License Policy to prevent the rest of us from doing what we find technically useful when our PMCs agree to it and we document it in our NOTICE file.

1. As far as I'm aware, there is no "DRAFT" Apache Third Party License
Policy. There is an existing ASF policy, and there's your draft proposal
for a different policy (which, being a proposal, is indeed irrelevant to
PMC decisions).

2. I do expect that all PMCs follow published ASF policy. ASF projects
should follow ASF rules; if they find them too limiting, they're always
free to set up somewhere else.

-- Brane

Re: Proposal: Apache Third Party License Policy

Posted by Branko Čibej <br...@apache.org>.
On 11.05.2015 04:35, Lawrence Rosen wrote:
>
> Don't be scared, Brane. I'm not trying to get you or Apache involved
> in some lawsuit. If YOU are afraid of the GPL, then don't incorporate
> such components in your projects. But don't dictate a GPL policy for
> MY project.
>

That's so funny. So basically you're saying that your 3rd-party license
policy was just a troll. Thanks for sharing.

-- Brane

Re: Proposal: Apache Third Party License Policy

Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, May 11, 2015 at 11:39 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I must point out that those GPL’d dictionaries are included in AOO installer
> binaries only, are optional components, and do not appear in the source-code
> releases themselves.  Users can also obtain more such components, as
> plug-ins, and add them to an AOO binary configuration themselves.

Further background on the (explicitly narrow!) approval of that
specific request from the AOO PMC:

https://issues.apache.org/jira/browse/LEGAL-117

If you follow the links you will find:

https://bz.apache.org/ooo/show_bug.cgi?id=65039#c16

I'll note that this is not an example of an inflexible and frozen
policy, nor is it an example of a PMC actively looking for ways to
circumvent the provisions of the license choice under which the
authors of the work was made available.

In fact, this is a prime example of how I think things should work.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


RE: Proposal: Apache Third Party License Policy

Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Dennis Hamilton wrote:

> I would also like to know who the “our” are with respect to the proposed “our Proposed Apache Third Party Licensing Policy.”

 

This is a "Proposal" on OUR legal-discuss@ community list.

 

I am pleased to hear all comments about it.

 

/Larry

 

 

From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Monday, May 11, 2015 8:40 AM
To: legal-discuss@apache.org
Subject: RE: Proposal: Apache Third Party License Policy

 

I must point out that those GPL’d dictionaries are included in AOO installer binaries only, are optional components, and do not appear in the source-code releases themselves.  Users can also obtain more such components, as plug-ins, and add them to an AOO binary configuration themselves.

 

Please stop using examples that avoid the key issue, which is comingling in the source code release and, most importantly, comingling in individual files of such releases.  That is what the ASF policy addresses.  It is irrelevant how source-code licenses are transitive into the binaries.  The policy is about the source code as those capable of using it would encounter it.

 

These deflections are not helpful.

 

I would also like to know who the “our” are with respect to the proposed “our Proposed Apache Third Party Licensing Policy.”

 

 

-- Dennis E. Hamilton

    orcmid@apache.org <ma...@apache.org> 

    dennis.hamilton@acm.org <ma...@acm.org>     +1-206-779-9430
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail

 

 

 

 

 

From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] 
Sent: Sunday, May 10, 2015 19:35
To: legal-discuss@apache.org <ma...@apache.org> 
Cc: Lawrence Rosen
Subject: RE: Proposal: Apache Third Party License Policy

 

Don't be scared, Brane. I'm not trying to get you or Apache involved in some lawsuit. If YOU are afraid of the GPL, then don't incorporate such components in your projects. But don't dictate a GPL policy for MY project. Point of evidence: AOO already includes GPL dictionaries in its distributed Apache software. I bet nobody gives a damn.

 

/Larry

 

 

From: Branko Čibej [mailto:brane@apache.org] 
Sent: Sunday, May 10, 2015 7:11 PM
To: legal-discuss@apache.org <ma...@apache.org> 
Subject: Re: Proposal: Apache Third Party License Policy

 

On 11.05.2015 00:58, Lawrence Rosen wrote:

Branko Čibej wrote:

> GPLv3 is an OSI-approved license.

 

Yes it is. I was wondering when someone here would notice that and blare at me with red eyes!  :-)

 

1. It is not up to me but to the PMC itself to determine that a GPLv3 component would be useful in an Apache project. My personal standard is: Technical value to the project, not which open source license was applied by that third party contributor/licensor. All these licenses, including GPLv3, are FREE, so users won't care (nor most even notice). 


I'm not interested in the technical aspects; that's not what we're discussing here.



2. Most copyright attorneys recognize that the mere incorporation of a copy of a GPLv3 component into an aggregation does not affect the aggregation's license regardless of some GPL folklore.


Now I'm scared. Waving away as "folklore" what has been the published intent and and policy of the FSF since its inception seems like a rather cavalier attitude.

Did I misunderstand what I've been told for decades, that, effectively, what most copyright attorneys recognize is irrelevant until proved in court? And do you think the ASF wants to be involved in a turf war over licensing in the open source world?




Fear should not dominate our general policy. Last week I passed along a note describing a project by Jim Wright (Oracle), Richard Fontana (HP), and other lawyers to eliminate much GPL fear by a simple declaration by reasonable licensors to the effect that "incorporation into any open source project is fine with them." Stand by for intelligent suggestions from people who are going to tame the GPL for Apache.


Any licensor has always had the option to use whatever license they please, including modifying or adding exceptions to the GPL. If Oracle or HP (or Mozilla or Eclipse or younameit) want to make their open source stuff more Apache-friendly, more power to them; and they can just use ALv2. But there are thousands of open-source projects out there and a significant proportion of them use copyleft-like licenses. Do you really think it's in our interest to tell all those people that we don't care what they've been told their license means? Surely the ASF doesn't want to become the bull in the FLOSS china shop.

-- Brane


RE: Proposal: Apache Third Party License Policy

Posted by "Dennis E. Hamilton" <de...@acm.org>.
I must point out that those GPL’d dictionaries are included in AOO installer binaries only, are optional components, and do not appear in the source-code releases themselves.  Users can also obtain more such components, as plug-ins, and add them to an AOO binary configuration themselves.
 
Please stop using examples that avoid the key issue, which is comingling in the source code release and, most importantly, comingling in individual files of such releases.  That is what the ASF policy addresses.  It is irrelevant how source-code licenses are transitive into the binaries.  The policy is about the source code as those capable of using it would encounter it.
 
These deflections are not helpful.
 
I would also like to know who the “our” are with respect to the proposed “our Proposed Apache Third Party Licensing Policy.”
 
 
-- Dennis E. Hamilton
    orcmid@apache.org
     <ma...@acm.org> dennis.hamilton@acm.org    +1-206-779-9430
     <https://keybase.io/orcmid> https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail
 
 
 
 
 
From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] 
Sent: Sunday, May 10, 2015 19:35
To: legal-discuss@apache.org
Cc: Lawrence Rosen
Subject: RE: Proposal: Apache Third Party License Policy
 
Don't be scared, Brane. I'm not trying to get you or Apache involved in some lawsuit. If YOU are afraid of the GPL, then don't incorporate such components in your projects. But don't dictate a GPL policy for MY project. Point of evidence: AOO already includes GPL dictionaries in its distributed Apache software. I bet nobody gives a damn.
 
/Larry
 
 
From: Branko Čibej [mailto:brane@apache.org] 
Sent: Sunday, May 10, 2015 7:11 PM
To: legal-discuss@apache.org <ma...@apache.org> 
Subject: Re: Proposal: Apache Third Party License Policy
 
On 11.05.2015 00:58, Lawrence Rosen wrote:
Branko Čibej wrote:
> GPLv3 is an OSI-approved license.
 
Yes it is. I was wondering when someone here would notice that and blare at me with red eyes!  :-)
 
1. It is not up to me but to the PMC itself to determine that a GPLv3 component would be useful in an Apache project. My personal standard is: Technical value to the project, not which open source license was applied by that third party contributor/licensor. All these licenses, including GPLv3, are FREE, so users won't care (nor most even notice). 

I'm not interested in the technical aspects; that's not what we're discussing here.


2. Most copyright attorneys recognize that the mere incorporation of a copy of a GPLv3 component into an aggregation does not affect the aggregation's license regardless of some GPL folklore.

Now I'm scared. Waving away as "folklore" what has been the published intent and and policy of the FSF since its inception seems like a rather cavalier attitude.

Did I misunderstand what I've been told for decades, that, effectively, what most copyright attorneys recognize is irrelevant until proved in court? And do you think the ASF wants to be involved in a turf war over licensing in the open source world?



Fear should not dominate our general policy. Last week I passed along a note describing a project by Jim Wright (Oracle), Richard Fontana (HP), and other lawyers to eliminate much GPL fear by a simple declaration by reasonable licensors to the effect that "incorporation into any open source project is fine with them." Stand by for intelligent suggestions from people who are going to tame the GPL for Apache.

Any licensor has always had the option to use whatever license they please, including modifying or adding exceptions to the GPL. If Oracle or HP (or Mozilla or Eclipse or younameit) want to make their open source stuff more Apache-friendly, more power to them; and they can just use ALv2. But there are thousands of open-source projects out there and a significant proportion of them use copyleft-like licenses. Do you really think it's in our interest to tell all those people that we don't care what they've been told their license means? Surely the ASF doesn't want to become the bull in the FLOSS china shop.

-- Brane

RE: Proposal: Apache Third Party License Policy

Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Don't be scared, Brane. I'm not trying to get you or Apache involved in some lawsuit. If YOU are afraid of the GPL, then don't incorporate such components in your projects. But don't dictate a GPL policy for MY project. Point of evidence: AOO already includes GPL dictionaries in its distributed Apache software. I bet nobody gives a damn.

 

/Larry

 

 

From: Branko Čibej [mailto:brane@apache.org] 
Sent: Sunday, May 10, 2015 7:11 PM
To: legal-discuss@apache.org
Subject: Re: Proposal: Apache Third Party License Policy

 

On 11.05.2015 00:58, Lawrence Rosen wrote:

Branko Čibej wrote:

> GPLv3 is an OSI-approved license.

 

Yes it is. I was wondering when someone here would notice that and blare at me with red eyes!  :-)

 

1. It is not up to me but to the PMC itself to determine that a GPLv3 component would be useful in an Apache project. My personal standard is: Technical value to the project, not which open source license was applied by that third party contributor/licensor. All these licenses, including GPLv3, are FREE, so users won't care (nor most even notice). 


I'm not interested in the technical aspects; that's not what we're discussing here.




2. Most copyright attorneys recognize that the mere incorporation of a copy of a GPLv3 component into an aggregation does not affect the aggregation's license regardless of some GPL folklore.


Now I'm scared. Waving away as "folklore" what has been the published intent and and policy of the FSF since its inception seems like a rather cavalier attitude.

Did I misunderstand what I've been told for decades, that, effectively, what most copyright attorneys recognize is irrelevant until proved in court? And do you think the ASF wants to be involved in a turf war over licensing in the open source world?





Fear should not dominate our general policy. Last week I passed along a note describing a project by Jim Wright (Oracle), Richard Fontana (HP), and other lawyers to eliminate much GPL fear by a simple declaration by reasonable licensors to the effect that "incorporation into any open source project is fine with them." Stand by for intelligent suggestions from people who are going to tame the GPL for Apache.


Any licensor has always had the option to use whatever license they please, including modifying or adding exceptions to the GPL. If Oracle or HP (or Mozilla or Eclipse or younameit) want to make their open source stuff more Apache-friendly, more power to them; and they can just use ALv2. But there are thousands of open-source projects out there and a significant proportion of them use copyleft-like licenses. Do you really think it's in our interest to tell all those people that we don't care what they've been told their license means? Surely the ASF doesn't want to become the bull in the FLOSS china shop.

-- Brane


Re: Proposal: Apache Third Party License Policy

Posted by Branko Čibej <br...@apache.org>.
On 11.05.2015 00:58, Lawrence Rosen wrote:
>
> Branko Čibej wrote:
>
> > GPLv3 is an OSI-approved license.
>
>  
>
> Yes it is. I was wondering when someone here would notice that and
> blare at me with red eyes!  :-)
>
>  
>
> 1. It is not up to me but to the PMC itself to determine that a GPLv3
> component would be useful in an Apache project. My personal standard
> is: Technical value to the project, not which open source license was
> applied by that third party contributor/licensor. All these licenses,
> including GPLv3, are FREE, so users won't care (nor most even notice).
>

I'm not interested in the technical aspects; that's not what we're
discussing here.

> 2. Most copyright attorneys recognize that the mere incorporation of a
> copy of a GPLv3 component into an aggregation does not affect the
> aggregation's license regardless of some GPL folklore.
>

Now I'm scared. Waving away as "folklore" what has been the published
intent and and policy of the FSF since its inception seems like a rather
cavalier attitude.

Did I misunderstand what I've been told for decades, that, effectively,
what most copyright attorneys recognize is irrelevant until proved in
court? And do you think the ASF wants to be involved in a turf war over
licensing in the open source world?


> Fear should not dominate our general policy. Last week I passed along
> a note describing a project by Jim Wright (Oracle), Richard Fontana
> (HP), and other lawyers to eliminate much GPL fear by a simple
> declaration by reasonable licensors to the effect that "incorporation
> into any open source project is fine with them." Stand by for
> intelligent suggestions from people who are going to tame the GPL for
> Apache.
>

Any licensor has always had the option to use whatever license they
please, including modifying or adding exceptions to the GPL. If Oracle
or HP (or Mozilla or Eclipse or younameit) want to make their open
source stuff more Apache-friendly, more power to them; and they can just
use ALv2. But there are thousands of open-source projects out there and
a significant proportion of them use copyleft-like licenses. Do you
really think it's in our interest to tell all those people that we don't
care what they've been told their license means? Surely the ASF doesn't
want to become the bull in the FLOSS china shop.

-- Brane

RE: Proposal: Apache Third Party License Policy

Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Branko Čibej wrote:

> GPLv3 is an OSI-approved license.

 

Yes it is. I was wondering when someone here would notice that and blare at me with red eyes!  :-)

 

1. It is not up to me but to the PMC itself to determine that a GPLv3 component would be useful in an Apache project. My personal standard is: Technical value to the project, not which open source license was applied by that third party contributor/licensor. All these licenses, including GPLv3, are FREE, so users won't care (nor most even notice). 

 

2. Most copyright attorneys recognize that the mere incorporation of a copy of a GPLv3 component into an aggregation does not affect the aggregation's license regardless of some GPL folklore. Fear should not dominate our general policy. Last week I passed along a note describing a project by Jim Wright (Oracle), Richard Fontana (HP), and other lawyers to eliminate much GPL fear by a simple declaration by reasonable licensors to the effect that "incorporation into any open source project is fine with them." Stand by for intelligent suggestions from people who are going to tame the GPL for Apache.

 

I will remind folks that this discussion at Apache started at our AOO project. It is currently trying to determine how to work cooperatively with an MPL project. GPL may not matter to AOO today. It is also not timely to consider adding some of Richard Stallman's GPL code into Hadoop. But I'd give the same answer, based on our DRAFT policy, assuming a PMC had a technical reason to do that!

 

/Larry

 

 

From: Branko Čibej [mailto:brane@apache.org] 
Sent: Sunday, May 10, 2015 3:15 PM
To: legal-discuss@apache.org
Subject: Re: Proposal: Apache Third Party License Policy

 

On 10.05.2015 23:26, Lawrence Rosen wrote:

Richard Eckart de Castilho asked several very good questions.
 
I used the term "aggregation" purposely to eliminate another confusion. The
U.S. copyright law term-of-art for this is actually "compilation"; if I said
that you'd all be definitely confused. In my book I used a similar
copyright-defined phrase, "collective work," which leaves programmers in the
dark too. Whichever the formal word, by "aggregation" I now mean things that
include copies of original open source works but ARE NOT DERIVATIVE WORKS.



I'm confused.

GPLv3 is an OSI-approved license. Section 10 of the GPLv3 says that if you "convey" (see GPLv3 section 0) such and "aggregate" (per your definition), you quote: " may not impose any further restrictions on the exercise of the rights granted or affirmed under this License".

IIUC, distributing GPLv3-licensed components under your proposed 3rd party licensing policy would be a direct violation of GPLv3.

-- Brane


Re: Proposal: Apache Third Party License Policy

Posted by Branko Čibej <br...@apache.org>.
On 10.05.2015 23:26, Lawrence Rosen wrote:
> Richard Eckart de Castilho asked several very good questions.
>
> I used the term "aggregation" purposely to eliminate another confusion. The
> U.S. copyright law term-of-art for this is actually "compilation"; if I said
> that you'd all be definitely confused. In my book I used a similar
> copyright-defined phrase, "collective work," which leaves programmers in the
> dark too. Whichever the formal word, by "aggregation" I now mean things that
> include copies of original open source works but ARE NOT DERIVATIVE WORKS.


I'm confused.

GPLv3 is an OSI-approved license. Section 10 of the GPLv3 says that if
you "convey" (see GPLv3 section 0) such and "aggregate" (per your
definition), you quote: " may not impose any further restrictions on the
exercise of the rights granted or affirmed under this License".

IIUC, distributing GPLv3-licensed components under your proposed 3rd
party licensing policy would be a direct violation of GPLv3.

-- Brane

RE: Proposal: Apache Third Party License Policy

Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Richard Eckart de Castilho asked several very good questions.

I used the term "aggregation" purposely to eliminate another confusion. The
U.S. copyright law term-of-art for this is actually "compilation"; if I said
that you'd all be definitely confused. In my book I used a similar
copyright-defined phrase, "collective work," which leaves programmers in the
dark too. Whichever the formal word, by "aggregation" I now mean things that
include copies of original open source works but ARE NOT DERIVATIVE WORKS.

For that legal determination, for "derivative work" think simply
"modification." If you are a /modifying/ redistributor of Apache code with
your own deep pockets at stake, ask your lawyer to read our NOTICE file. If
you are afraid to rely on my shorthand definition for "derivative work,"
take your specific questions to your lawyer. If you are not *modifying and
redistributing* Apache works, then you are probably not subject to any
reciprocity obligation, but the Apache License 2.0 is AS-IS without
warranty. We need to encourage our PMCs and downstream /redistributors/ to
/modify/ third party contributions wisely and read the NOTICE file.

The reason I first applied the term "reciprocity" to this licensing notion
back in 2004 was to be much more specific than the confusing term
"copyleft." Avoiding the fuller description in my book, a "reciprocal"
license requires that "derivative works" be distributed under the same
license as the original work. Merely that.

When licenses impose other conditions, such as attribution and trademark
notices, or when there are patent limitations, our NOTICE file should inform
people about that. But those aren't "reciprocity" conditions. The reason is
that these kinds of things do not directly affect the five fundamental
copyright freedoms given by ALL open source licenses:

.	Use Apache software for any purpose.
.	Make and distribute copies.
.	Create and distribute derivative works.
.	Access and use the source code.
.	Combine Apache and other software.

I'm sorry that I can't eliminate the difficult definition of "derivative
work" entirely. If our PMCs review third party contributions in public and
our NOTICE files are complete, I'm sure that intelligent copyright attorneys
will rise to the challenge without stymying open source development. 

When you used words like "a non-essential component and there is no direct
definitive dependency to it, e.g. via a inversion-of-control or plugin API,"
you were speaking Greek to a Latin-speaking attorney. None of that is a
relevant derivative work consideration as stated by you in a vacuum without
facts. If you're confused, read books and consult an attorney. Or if you
want to get general opinions on this from lawyers around the world, join one
of several legal discussion lists and shoot them hypotheticals.

I can assure you, however, that MOST OSI-approved open source licenses have
no such absurd interpretive challenges.

/Larry


-----Original Message-----
From: Richard Eckart de Castilho [mailto:rec@apache.org] 
Sent: Sunday, May 10, 2015 12:53 PM
To: members@apache.org; Lawrence Rosen
Cc: legal-discuss@apache.org
Subject: Re: Proposal: Apache Third Party License Policy

Hi Larry,

I'm quite interested in this topic, but unfortunately, I don't seem
understand your suggestion.
I'll just strip out the sections that appear quite clear and leave in those
that are not:

On 10.05.2015, at 20:32, Lawrence Rosen <lr...@rosenlaw.com> wrote:

> When technically appropriate for that software in the judgment of the PMC,
Apache projects may accept contributions under ANY OSI-approved open source
license. Such software may now be included in Apache aggregations that, as
described above, will be licensed to the public under Apache License 2.0.

I believe that "aggregation" is the word not to miss here - unfortunately,
the word is not defined. To me "aggregation" means something like that the
contribution is a non-essential component and there is no direct definitive
dependency to it, e.g. via a inversion-of-control or plugin API.

> .         Downstream users and re-distributors of Apache software can
continue to incorporate all of our open source software into their own
products unmodified without incurring any special derivative work
reciprocity obligations.
>  
> .         Modifiers and re-distributors of Apache software will now need
to read the NOTICE files to determine whether they have any derivative work
reciprocity requirements for specific contributions.

Hm, in one sentence you say that there are no reciprocity obligations and in
the next you say that we need to read the NOTICE file to watch out for
reciprocity obligations. What am I missing here?

Cheers,

-- 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: Proposal: Apache Third Party License Policy

Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi Larry,

I'm quite interested in this topic, but unfortunately, I don't seem understand your suggestion.
I'll just strip out the sections that appear quite clear and leave in those that are not:

On 10.05.2015, at 20:32, Lawrence Rosen <lr...@rosenlaw.com> wrote:

> When technically appropriate for that software in the judgment of the PMC, Apache projects may accept contributions under ANY OSI-approved open source license. Such software may now be included in Apache aggregations that, as described above, will be licensed to the public under Apache License 2.0.

I believe that "aggregation" is the word not to miss here - unfortunately, the word is not defined. To me "aggregation" means something like that the contribution is a non-essential component and there is no direct definitive dependency to it, e.g. via a inversion-of-control or plugin API.

> ·         Downstream users and re-distributors of Apache software can continue to incorporate all of our open source software into their own products unmodified without incurring any special derivative work reciprocity obligations.
>  
> ·         Modifiers and re-distributors of Apache software will now need to read the NOTICE files to determine whether they have any derivative work reciprocity requirements for specific contributions.

Hm, in one sentence you say that there are no reciprocity obligations and in the next you say that we need to read the NOTICE file to watch out for reciprocity obligations. What am I missing here?

Cheers,

-- Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org