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

Lawrence Rosen lrosen at rosenlaw.com
Fri Aug 28 19:51:12 UTC 2015


 

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.Tzeng at jhuapl.edu] 
Sent: Thursday, August 27, 2015 7:36 AM
To: license-discuss at 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-bounces at opensource.org%20on%20behalf%20of%20forums at david-woolley.me.uk> license-discuss-bounces at opensource.org on behalf of forums at 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.

 

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

 <mailto:License-discuss at opensource.org> License-discuss at opensource.org

 <https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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


More information about the License-discuss mailing list