+1 to some of what Alex Harui wrote (copied below). It is very helpful to understand the opinions of many Apache members represented by his words. I don't like repeating myself either.

 

The reasons that there are so many FOSS licenses is mostly because of other things (patents, defensive termination, "corresponding source," the scale of attribution conditions, warranties, static linking, DRM prohibitions) than what Sam is asking about. At least, I think so. Sometimes Sam's questions here go wildly into complex, multi-layered hypotheticals that can be boiled down to asking about whether companies like IBM, Microsoft, Google, Adobe, etc., are free to copy and create derivative works of all Apache products even under proprietary licenses.  The answer is always YES as long as the components – including the ALv2 components – are and remain FOSS. Nobody is allowed to change that. Read our license and our attribution notices and our source code archives.

 

In all FOSS respects, ALv2, MPLv2, EPL, and the BSD licenses are all free. (Even, despite some interpretive complaints, the GPL licenses are free for Larger Works!) All FOSS licenses contain conditions. That doesn't change the answer in the previous paragraph.

 

Avoiding other FOSS software is a waste of great FOSS.

 

As for me being free to re-raise this issue here on occasion: Thanks! I fully intend to until at least one reputable attorney asks me to shut up. I believe that this policy issue is very important to ASF and to all other reputable FOSS foundations we partner with.

 

I remind everyone that this is the public email list legal-discuss@apache.org.

 

/Larry

 

 

From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, August 3, 2015 8:53 AM
To: legal-discuss@apache.org; lrosen@rosenlaw.com
Subject: Re: Third Party FOSS licenses

 

Larry wrote:  " All I've said is that you MUST COMPLY with the license conditions of any code you modify."

 

IMO, there appears to be several popular Open Source licenses.  To my simple mind, the set of things you must comply with must differ amongst these Open Source licenses in legally significant ways, otherwise there wouldn’t be more than one or two of them.

 

The ASF as chosen to divide these licenses into three sets based upon the set of things you must comply with.  The foundation has a right to do so.  It is fine to hear you propose that we change that.  So far, I don’t hear any support for change.

 

IMO, it doesn’t matter so much what lawyers think.  What matters is public perception.  If you advertise that your restaurant serves healthy food for everyone, you might not want to use GMO ingredients not because it isn’t safe or healthy, but because there is enough public fear about it.  IMO, GPL=GMO.  And maybe, MPL=non-organic.   The folks who we’ve elected to decide this sort of stuff have decided not to take not the burden of changing public perception and just making sure we don’t use certain ingredients so folks can come in and eat a meal without having to scan the ingredients list thoroughly or pay a specialist to investigate it.

 

What I’d like to see going forward on this topic is the following:

1.       Changes to http://www.apache.org/legal/resolved.html to be more specific about the ASF’s perspective on this topic which clearly has become a FAQ, even if it is just Larry frequently asking the question.  The new words should include the ASF’s position about being a universal donor, and avoiding the need for specialists/legal folks when folks want to use ASF works.  Also, maybe more detail on what it is about MPL and EPL that keep them in Category B.  

2.       Larry is welcome to re-raise this topic on occasion, but hopefully not too often, but certainly if he can bring new information to the topic such as a statement from another attorney that might affect our categorization of a particular license.  But otherwise, the goal of the changes I am suggesting above is that instead of folks trying to spend dozens of emails debating Larry, that we just point to this new section of the FAQ, and invite folks who normally do not respond on these threads to speak up if they think the new information Larry provides deserve the energy spent debating this topic.  It doesn’t make sense to me to spend this much energy trying to convince one person until you have evidence there is more than one person that needs convincing.  New members who may not be aware of the ASF’s position can just follow the link and hopefully understand why we are where we are without all of this re-hashing.

Thanks,

-Alex

 

From: Lawrence Rosen <lrosen@rosenlaw.com>
Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>, "lrosen@rosenlaw.com" <lrosen@rosenlaw.com>
Date: Monday, August 3, 2015 at 8:07 AM
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Cc: Lawrence Rosen <lrosen@rosenlaw.com>
Subject: RE: Third Party FOSS licenses

 

> It is too late at night for me to analyze compound questions.

 

No problem.  It would be helpful if you were to answer those questions before you make any further requests to change the ASF 3rd party licensing policy.

 

Sure. I repeat: " All I've said is that you MUST COMPLY with the license conditions of any code you modify."

 

/Larry

 

Lawrence Rosen

"If this were legal advice it would have been accompanied by a bill."

 

 

-----Original Message-----
From: Sam Ruby [mailto:rubys@intertwingly.net]
Sent: Sunday, August 2, 2015 8:41 PM
To: Legal Discuss <legal-discuss@apache.org>; Lawrence Rosen <lrosen@rosenlaw.com>
Subject: Re: Third Party FOSS licenses

 

On Sun, Aug 2, 2015 at 11:25 PM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:

> Sam Ruby said:

>> ... and ...

> It is too late at night for me to analyze compound questions.

 

No problem.  It would be helpful if you were to answer those questions before you make any further requests to change the ASF 3rd party licensing policy.

 

- Sam Ruby

 

---------------------------------------------------------------------

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org

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