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

[Lawrence Rosen]

 

Nigel Tzeng wrote:

And everyone makes mistakes ISO 9001 or not.  The key is to minimize avoidable 
errors through policy/procedures, training and selective use of 3rd party 
libraries and licenses.  Apache products are generally considered safe(r) and 
require less oversight in terms of copyright issues.   A policy change at 
Apache to make this less true is probably not desired by many of its users.

 

End-users need never worry about risk from legitimate FOSS software. The use of 
FOSS software -- including the right to make copies and create derivative works 
for personal use -- is always available by license. This is true for all FOSS 
and Creative Commons works. See OSD.

 

Nor is there risk from redistributing mere aggregates of legitimate FOSS 
software, although attribution and other license conditions may apply to that 
distribution. See most OSI-approved licenses and OSD #1. Let me simplify: If 
you merely redistribute Apache software without creating a derivative work, it 
should be sufficient protection to republish Apache's original NOTICE file with 
your own aggregate. That's easy.

 

Increased risk comes when distributing derivative works. And that risk comes 
from not honoring the conditions of the FOSS license(s) placed on the original 
work(s) by its author(s). Your derivative works are not documented in Apache's 
NOTICE file. You may have your own FOSS license conditions to honor for your 
own derivative works. Almost all FOSS licenses, including ALv2 itself in 
section 4, contain license conditions that apply to your own derivative works. 
Read Apache's NOTICE file for such FOSS license notices and consult your own 
attorney first. 

 

Each distributor must implement its own ISO 9001 or similar rules. Apache 
projects do not have such "manufacturing" documentation policies. While each 
Apache project is responsible for documenting all third party contributions 
that it distributes (source or binary), all Apache software is distributed on 
an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND (ALv2 section 
7). 

 

A safe policy for all distributors is never to distribute any FOSS software 
without understanding its licenses. Do not "accidentally" create a derivative 
work by pretending that a binary is safer to modify than source code, or by 
sloppily merging MPLv2 and EPL and Apache software without first reading the 
NOTICE file and the source code itself.

 

This is not difficult. Just don't expect that Apache projects do that for you. 

 

And none of this risk is reduced by Apache's current Category "B" license list. 
All FOSS licenses from reputable FOSS foundations act generally the same way 
despite the internal license preference (ALv2, MPLv2, EPL, CC-BY, even GPL, 
etc.) of the project that first distributed that valuable free software. 

 

Nigel wrote:
> Or do you believe members of this mailing list are unaware of the advantages 
> and

> disadvantages of the different types of open source licenses?

 

Everyone on this list has philosophical biases for their own copyrighted FOSS 
works. Me too. You too. So what? That doesn't affect risk at all.

 

/Larry

 

My words are CC-BY. I do not speak for Apache Software Foundation.

 

 

-Original Message-
From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu] 
Sent: Thursday, August 27, 2015 7:36 AM
To: license-discuss@opensource.org
Subject: Re: [License-discuss] Category "B" licenses at Apache

 

On 8/26/15, 3:14 AM, "License-discuss on behalf of David Woolley"

< 
<mailto:license-discuss-boun...@opensource.org%20on%20behalf%20of%20for...@david-woolley.me.uk>
 license-discuss-boun...@opensource.org on behalf of 
for...@david-woolley.me.uk> wrote:

 

 

>On 26/08/15 01:45, Tzeng, Nigel H. wrote:

>> Larry,

>> 

>> Scenario A:   I¹m looking for an example in my codebase on how to do Foo

>> (of course) and I find a code snippet to do roughly what I want.  I 

>> cut and paste it into where I need it, modify it slightly and move on.

>>   Developers do this all the time.

> 

>The purpose of open source is to allow them to do this legally.  Coders 

>who do this all the time on published code that doesn't have an open 

>source type licence are continually infringing copyright.

 

>One of the main reasons for the GPL is to ensure a large pool of code 

>that cane be re-used and re-purposed, whilst, at the same time ensuring 

>that the resulting code goes back into the pool.

 

Which is great except we are discussing Apache policy and not GPL.  The point 
is that once you do this your code is now potentially subject to the terms of 
the weak copyleft Category B license without you being aware of this.

 

I believe this is the reason that Apache explicitly does not include source 
with their Category B components.

 

&

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

[Tzeng, Nigel H.]

On 8/26/15, 3:14 AM, "License-discuss on behalf of David Woolley"
 wrote:


>On 26/08/15 01:45, Tzeng, Nigel H. wrote:
>> Larry,
>>
>> Scenario A:   I¹m looking for an example in my codebase on how to do Foo
>> (of course) and I find a code snippet to do roughly what I want.  I cut
>> and paste it into where I need it, modify it slightly and move on.
>>   Developers do this all the time.
>
>The purpose of open source is to allow them to do this legally.  Coders
>who do this all the time on published code that doesn't have an open
>source type licence are continually infringing copyright.

>One of the main reasons for the GPL is to ensure a large pool of code
>that cane be re-used and re-purposed, whilst, at the same time ensuring
>that the resulting code goes back into the pool.

Which is great except we are discussing Apache policy and not GPL.  The
point is that once you do this your code is now potentially subject to the
terms of the weak copyleft Category B license without you being aware of
this.

I believe this is the reason that Apache explicitly does not include
source with their Category B components.

>> Scenario B:  I am debugging some code and find a spot where an if test
>> should be <= bar rather than < bar.  I fix it while inside the debugger
>
>That change is going to have insufficient creative content to have any
>copyright associated with it.  So all you have demonstrated there is
>that your organisation's configuration control procedures are broken and
>their ISO 9000 status may need revoking.  In any case, typical copyleft
>licences permit the use of modified versions within an organisation.

I think most folks will understand that if the example above is
insufficient to trigger copyright the point is still clear.  At some point
a (more significant) change could result in an unintentional violation if
the source code is present.

And everyone makes mistakes ISO 9001 or not.  The key is too minimize
avoidable errors through policy/procedures, training and selective use of
3rd party libraries and licenses.  Apache products are generally
considered safe(r) and require less oversight in terms of copyright
issues.   A policy change at Apache to make this less true is probably not
desired by many of its users.

Thank you for your concern regarding our AS9100/ISO 9001:2000 status.
While I am speaking only as an individual on this list and not as a
representative of our organization, we do review our software development
practices quite often to identify weaknesses and areas to improve.
Certification is less important to us than quality development practices.
 
Perhaps it should be general policy or a best practice suggestion not to
include weak copyright source code in projects but only the compiled
binaries even if it makes development and debugging slightly more
annoying.  I may suggest this after thinking about it more or put it up
for discussion on our internal software development list.

Despite my disagreement with Larry the risks ARE relatively low so perhaps
sufficient training/awareness will be sufficient.  But our situation is
different than that of Apache.

>> without realizing that it was in the Category B module.  Since I¹m
>> modifying the Apache product quite a bit anyway was not immediately
>> obvious that when I checked my changes into the local repo for the
>> Apache product that I made a change in the Category B module.  Maybe I
>> simply never knew or had forgotten that I had to be aware there was a
>> category B module.
>
>I believe another intent of the GPL Is that people should be able to
>debug and repair the code that they possess.

And this would be great if the discussion was about GPL but not everyone
wants to use GPL, hence Apache.

Was the title or topic somehow unclear?  Or do you believe members of this
mailing list are unaware of the advantages and disadvantages of the
different types of open source licenses?

Regards,

Nigel

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[David Woolley]

On 26/08/15 01:45, Tzeng, Nigel H. wrote:

Larry,

Scenario A:   I’m looking for an example in my codebase on how to do Foo
(of course) and I find a code snippet to do roughly what I want.  I cut
and paste it into where I need it, modify it slightly and move on.
  Developers do this all the time.


The purpose of open source is to allow them to do this legally.  Coders 
who do this all the time on published code that doesn't have an open 
source type licence are continually infringing copyright.


One of the main reasons for the GPL is to ensure a large pool of code 
that cane be re-used and re-purposed, whilst, at the same time ensuring 
that the resulting code goes back into the pool.


Scenario B:  I am debugging some code and find a spot where an if test
should be <= bar rather than < bar.  I fix it while inside the debugger


That change is going to have insufficient creative content to have any 
copyright associated with it.  So all you have demonstrated there is 
that your organisation's configuration control procedures are broken and 
their ISO 9000 status may need revoking.  In any case, typical copyleft 
licences permit the use of modified versions within an organisation.



without realizing that it was in the Category B module.  Since I’m
modifying the Apache product quite a bit anyway was not immediately
obvious that when I checked my changes into the local repo for the
Apache product that I made a change in the Category B module.  Maybe I
simply never knew or had forgotten that I had to be aware there was a
category B module.


I believe another intent of the GPL Is that people should be able to 
debug and repair the code that they possess.





___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Tzeng, Nigel H.]

Larry,

Scenario A:   I'm looking for an example in my codebase on how to do Foo (of 
course) and I find a code snippet to do roughly what I want.  I cut and paste 
it into where I need it, modify it slightly and move on.  Developers do this 
all the time.

If the source code for the Category B module is not present on my system, this 
code snippet can never be from that module.  I will never accidentally cut and 
paste any reciprocally licensed code into my software because it's simply not 
there to be copied in the first place.

This is not a true statement of the Category B module source is provided as 
default in the Apache product.

Scenario B:  I am debugging some code and find a spot where an if test should 
be <= bar rather than < bar.  I fix it while inside the debugger without 
realizing that it was in the Category B module.  Since I'm modifying the Apache 
product quite a bit anyway was not immediately obvious that when I checked my 
changes into the local repo for the Apache product that I made a change in the 
Category B module.  Maybe I simply never knew or had forgotten that I had to be 
aware there was a category B module.

If the source code for the Category B module is not present I typically cannot 
do this in the debugger.  What I will discover is that the problem exists in 
some library for which source is not available.  Typically folks will then 
realize the source is missing for reason.

I disagree that folks do not accidentally create derivative works*.  These two 
scenarios are easily avoided by simply not packaging the source code inside the 
Apache product but requiring a separate download.  These two mistakes are not 
caught by legal review of licenses and Scenario A is not easily caught without 
fairly rigorous code review practices.  Scenario B you have a better shot that 
someone notices that there are undesired changes to 3rd party packages in the 
repo.

Frankly, inclusion of the Category B source would make it sufficiently annoying 
that I would likely avoid using that particular Apache product from a 
compliance perspective.  You already need to make folks aware that just because 
the JRE source code is available to look at it doesn't mean its okay to reuse 
that source in your own code.  Or source code found on Stack Overflow (default 
licensed CC-BY-SA).

You have not shown how using a separate download does not meet requirements for 
Category B licenses nor made a case where including the source as default is 
superior to the current guideline of requiring the developer explicitly 
download the source for Category B modules as a safety measure.

Regards,

Nigel

* feel free to argue fair use is viable defense for re-using code snippets 
without complying with the license terms.

From: Lawrence Rosen mailto:lro...@rosenlaw.com>>
Reply-To: Lawrence Rosen mailto:lro...@rosenlaw.com>>
Date: Saturday, August 22, 2015 at 3:11 PM
To: "Nigel H. Tzeng" mailto:nigel.tz...@jhuapl.edu>>, 
License Discuss 
mailto:license-discuss@opensource.org>>
Cc: Lawrence Rosen mailto:lro...@rosenlaw.com>>
Subject: RE: [License-discuss] Category "B" licenses at Apache

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

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Lawrence Rosen]

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.tz...@jhuapl.edu] 
Sent: Thursday, August 20, 2015 4:36 PM
To: Lawrence Rosen ; license-discuss@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 mailto:license-discuss-boun...@opensource.org> > on behalf of Lawrence
Rosen mailto:lro...@rosenlaw.com> >
Reply-To: Lawrence Rosen mailto:lro...@rosenlaw.com>
>, License Discuss mailto:license-discuss@opensource.org> >
Date: Monday, August 17, 2015 at 3:20 PM
To: License Discuss mailto:license-discuss@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 co

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

[Lawrence Rosen]

I wrote earlier and want to postscript it:

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

 

For example, a short and simple NOTICE file could say:

 

Apache SQRT is an improved square root calculator that was created by Sally
Contributor. She combined the best features of previous ALv2 and MPLv2
square root functions. This is documented in Sally's source code available
at www.apache.org <http://www.apache.org> . This derivative work, Apache
SQRT, is "Copyright (C) 2015 Sally Contributor."

 

Because this is a derivative work of an MPLv2 program, the resulting Apache
SQRT module is licensed under MPLv2. Every program that invokes this Apache
SQRT module retains its own license, FOSS or proprietary.

 

/Larry

 

 

From: Lawrence Rosen [mailto:lro...@rosenlaw.com] 
Sent: Thursday, August 20, 2015 8:25 AM
To: 'Richard Eckart de Castilho' ;
license-discuss@opensource.org
Cc: Lawrence Rosen 
Subject: RE: [License-discuss] Category "B" licenses at Apache



___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [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.eck...@gmail.com] 
Sent: Thursday, August 20, 2015 12:14 AM
To: Lawrence Rosen ; license-discuss@opensource.org
Subject: Re: [License-discuss] Category "B" licenses at Apache

 

Hi Larry,

 

On 17.08.2015, at 21:20, Lawrence Rosen < <mailto:lro...@rosenlaw.com>
lro...@rosenlaw.com> wrote:

 

> 

> 

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

> 

> 

 

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

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

[Tzeng, Nigel H.]

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 
mailto:license-discuss-boun...@opensource.org>>
 on behalf of Lawrence Rosen mailto:lro...@rosenlaw.com>>
Reply-To: Lawrence Rosen mailto:lro...@rosenlaw.com>>, 
License Discuss 
mailto:license-discuss@opensource.org>>
Date: Monday, August 17, 2015 at 3:20 PM
To: License Discuss 
mailto:license-discuss@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, 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

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

[Richard Eckart de Castilho]

Hi Larry,

On 17.08.2015, at 21:20, Lawrence Rosen  wrote:

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

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