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

[Lawrence Rosen]

Richard Eckart de Castilho wrote:

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

 

Thanks for trying, but why did you bother to write me about something that
the ASF board has already decided for you?

 

You didn't accurately describe my proposal. I suggested that the decisions
on contribution licenses should be made by each PMC based on software needs
rather than an ASF-wide policy that accomplishes nothing valuable and is
legally nonsense. 

 

There is no FOSS limit on "refactoring." Do it freely. Who asked for a
separate source repository?

 

Furthermore, who suggested that anyone "maintain per-line license"
information? Are you going to blame my proposal for every unreasonable
suggestion by those who don't understand copyright law and FOSS license
requirements?

 

Accepting "patches" (if by that you mean small changes to fix bugs) is not a
copyright problem. A bigger change would require that someone intelligent on
the PMC evaluate it as a contribution and make a comment about it in the
NOTICE file.

 

/Larry

 

Lawrence Rosen

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

 

-----Original Message-----
From: Richard Eckart de Castilho [mailto:richard.eckart at gmail.com] 
Sent: Thursday, August 20, 2015 12:14 AM
To: Lawrence Rosen <lrosen at rosenlaw.com>; license-discuss at opensource.org
Subject: Re: [License-discuss] Category "B" licenses at Apache

 

Hi Larry,

 

On 17.08.2015, at 21:20, Lawrence Rosen < <mailto:lrosen at rosenlaw.com>
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

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