[License-discuss] Category "B" licenses at Apache

Sat Aug 22 19:11:24 UTC 2015

Responding to Nigel Tzeng's concerns (below) about source and object code:

There is perhaps a smaller risk that someone will make a derivative work of
Apache software entirely by accident from the binary alone without looking
for the source code (and finding it) posted on the web. But just in case,
for that reason and many others, seeking legal review first for a commercial
product is a great idea before even attempting any derivative work.  

Important derivative works of software are not accidental.

Enforcing compliance with licenses and copyright law requires legal review
even for FOSS licenses that Apache lists in Category A. I know that because
I wrote one of those OSI-approved and Apache-approved and FSF-approved FOSS
licenses (AFL 3.0) that imposes important (non-reciprocal) conditions on
both copies and derivative work. So do many other FOSS licenses in all
Apache's "categories." For both binaries and source code. Caveat emptor.
Caveat derivator.

/Larry

P.S. Nigel is correct. I meant EPL not ECL. I write too fast....

From: Tzeng, Nigel H. [mailto:Nigel.Tzeng at jhuapl.edu] 
Sent: Thursday, August 20, 2015 4:36 PM
To: Lawrence Rosen <lrosen at rosenlaw.com>; license-discuss at opensource.org
Subject: Re: [License-discuss] Category "B" licenses at Apache

Larry,

Please note that ECL is an OSI approved license based on Apache and not
Eclipse.  Using ECL in the same sentence as MPL is mildly confusing even
when you (re)define the acronym in the previous paragraph when using EPL
would be more clear.

As far as differentiating between source and object code I believe that the
Apache statement for category B licenses is correct.  The "exposed surface
area" at risk IS much lower than if source was available inside the Apache
project as a default.  You are under license obligation if you cut and paste
from these EPL/MPL/etc source files and since the source files are not
present you can't accidentally do so without explicitly getting that source
from somewhere.  By making that an extra step Apache is reducing the risk of
an accidental copyright violation. 

Without the source files you also can't easily modify the MPL/etc work for
which the modified source must be provided by you instead of just pointing
upstream to some place the original source can be found. 

Whether or not the binary and source are considered the same work under
copyright is immaterial.distributing only the binary format reduces the risk
of accidental violations for code licensed under some, if not all, weak
copyleft licenses by eliminating/reducing some of the most common
opportunities for making a mistake.

It strikes me that this is a pragmatic and useful risk reduction strategy in
handling weak copyleft code within ALv2 projects that helps protect both
maintainers and users of the Apache product.

Apache should probably provide that source separately as a matter of policy
for handling category B licensed components rather than just point upstream
to a source that could disappear a few years down the road.  There's a bit
of orphaned java code out there where the original projects and their repos
have disappeared.

Maybe Apache does but it's not explicitly written in the FAQ to do anything
but include the URL to the product's homepage where presumably the source is
available.  Maybe I read that part wrong or there is a more exhaustive
checklist somewhere else of what the Apache project needs to do when using
Category B components.

Regards,

Nigel

From: License-discuss <license-discuss-bounces at opensource.org
<mailto:license-discuss-bounces at opensource.org> > on behalf of Lawrence
Rosen <lrosen at rosenlaw.com <mailto:lrosen at rosenlaw.com> >
Reply-To: Lawrence Rosen <lrosen at rosenlaw.com <mailto:lrosen at rosenlaw.com>
>, License Discuss <license-discuss at opensource.org
<mailto:license-discuss at opensource.org> >
Date: Monday, August 17, 2015 at 3:20 PM
To: License Discuss <license-discuss at opensource.org
<mailto:license-discuss at opensource.org> >
Subject: [License-discuss] Category "B" licenses at Apache

An Apache member wrote that this ASF license objective is firmly held: To
allow our customers to "redistribute with closed-source modifications."

That objective remains completely and always enforceable for ALv2 code. It
is not enforceable for Eclipse (ECL) components or MPLv2 components. 

These are two different but entirely valid ways to FOSS. Reciprocity is a
license condition for some FOSS licenses. There is nothing evil in that. It
is always an author's prerogative to choose her FOSS license. 

None of the companies in Eclipse Foundation have any objection whatsoever
(that I've heard) to the inclusion of ECL and MPLv2 components into Apache
aggregations. Indeed, they collectively and enthusiastically create such
valuable FOSS components for that very purpose. They include them in their
own products.

So is the objective "to redistribute with closed-source modifications"
intended to describe an actual Apache concern, or a religious objection to
all reciprocal licenses? Certainly not the latter!  

According to the current Apache Third Party License Policy
<http://www.apache.org/legal/resolved.html> , ASF doesn't really object to
these reciprocal FOSS licenses; they are handled as exceptions. In the
Policy "this is colloquially known as the Category B list." 

But then that Policy makes the following strange explanation for Category B
and its enforcement conditions at ASF: "By including only the object/binary
form, there is less exposed surface area of the third-party work from which
a work might be derived; this addresses the second guiding principle of this
policy."

That "object/binary form" requirement and the reference to "exposed surface
area" in the Policy are nonsense. I repeat three statements I made here
previously:

?       The binary and source forms of a work are, from a copyright
perspective, the exact same work subject to the exact same FOSS license.
Stop wasting time trying to distinguish them legally.

?       Apache is committed to FOSS. For that reason, we should always
publish source code. Binaries are a convenience for our customers published
by our projects, but never without source code.

?       Our failure, or our customer's failure, to make that source code
available (including of course any ALv2 code) and copies of all relevant
licenses, is a probable breach of license and possible copyright
infringement. All modern technology companies understand that about FOSS and
copyright law.

The "second guiding principle" referred to in the current Apache Policy is
this:

2.  The license must not place restrictions on the distribution of
independent works that simply use or contain the covered work.

This accurately and precisely refers to "independent works" and not
"derivative works."  Reciprocity has nothing to do with independent works.
Every FOSS license (except perhaps under the GPL "static linking" doctrine)
satisfies this second guiding principle. See OSD.

/Larry

P.S. I don't know if this message will survive legal-discuss@ list
moderation, so I intend to send it onto other lists. All quotations are from
public ASF lists.

Lawrence Rosen

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20150822/b01671df/attachment.html>