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

[Richard Eckart de Castilho]

Hi Larry,

On 17.08.2015, at 21:20, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> <snip>
> 
> 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.
> 
> <snip>

What you call nonsense makes a lot of sense from the point of view of a software developer.

The problem with reciprocal licenses in the lines of EPL and MPL is not so much in being used as:

a) a *library* or as
b) a clearly *separate piece of code* (that resides in a repository outside the ASF)

but rather in *accepting patches* for at least two reasons:

1) it is tedious to *maintain per-line license* information in a source file
2) it seriously *limits the ability to perform refactoring* of code

Of course, 1 and 2 become somewhat irrelevant if a project under license X that
accepts patches under EPL/MPL simply states that all source files are licensed 
under EPL/MPL and *contain parts licensed under X*. 

But then *X becomes irrelevant* because it is hard to impossible to tell which
parts of the project are actually licensed under X and which parts are under EPL/MPL.

Thus, if the developers of the project wish that their project remains under
license X, accepting *patches* under EPL/MPL is simple *not desirable*.

Cheers,

-- Richard