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 <lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>> Reply-To: Lawrence Rosen <lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>> Date: Saturday, August 22, 2015 at 3:11 PM To: "Nigel H. Tzeng" <nigel.tz...@jhuapl.edu<mailto:nigel.tz...@jhuapl.edu>>, License Discuss <license-discuss@opensource.org<mailto:license-discuss@opensource.org>> Cc: Lawrence Rosen <lro...@rosenlaw.com<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
