Hi Larry, On 17.08.2015, at 21:20, Lawrence Rosen <lro...@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 _______________________________________________ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
