[License-discuss] Companies that encourage license violations
I'm not sure if this is the right forum for this, if not I'd greatly appreciate a pointer to the right one. So I ran into a situation where a company isn't training their employees very well and is causing all sorts of confusion and in some cases outright license/copyright violations through what seems to be just simple ignorance. Company in question has a popular piece of software. They have a store where developers can publish extensions and addons to this software. It's a huge success with thousands of addons and sales volumes probably into the millions per month. Some of these addons are themselves open source. The majority of the time the authors of these are not including the open source license. Which I think is legally ok, I'm guessing it actually just creates a dual license, but not an attorney so not sure on this. The problem is that other addons are including these open source addons. Literally just copying them into their own distribution. And they are not including a copy of the license. Most of the time not even aware of the violation because the original author didn't include the license either. The kicker is that the company has a practice where they decline your addon if they know it has another addon, even if it's open source. So publishers are just including these other addons in a non standard way so that the company won't notice and won't decline their addon. If this seems confusing it's because it is. The end result here is conservatively thousands of these addons being distributed with open source libraries that don't have licenses attached. Just including the license in a certain way (where the employees reviewing the addon can notice it) will get it declined. I'm interested in bringing attention to this in a way that makes them change and looking for suggestions on the best way to do that. But I don't want to cause any trouble for the people that have submitted all of these addons that are in violation. Yes they should know better, but they wouldn't be in the position they are if the company didn't have such a crazy policy. ___ 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
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' richard.eck...@gmail.com; license-discuss@opensource.org Cc: Lawrence Rosen lro...@rosenlaw.com Subject: RE: [License-discuss] Category B licenses at Apache snip ___ 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
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 lro...@rosenlaw.com; 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 license-discuss-boun...@opensource.org mailto:license-discuss-boun...@opensource.org on behalf of Lawrence Rosen lro...@rosenlaw.com mailto:lro...@rosenlaw.com Reply-To: Lawrence Rosen lro...@rosenlaw.com mailto:lro...@rosenlaw.com , License Discuss license-discuss@opensource.org mailto:license-discuss@opensource.org Date: Monday, August 17, 2015 at 3:20 PM To: License Discuss license-discuss@opensource.org 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
Re: [License-discuss] Category B licenses at Apache
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 lro...@rosenlaw.com; 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: 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
Re: [License-discuss] Option to fall back from GPL to ASL
Richard Eckart de Castilho scripsit: This software is provided under the terms of the GPL *as long as mandated by the reciprocal terms of libraries used by this software*. Any code removed from this software falls back to ASL unless it continues to depend on GPL code. Likewise, all code automatically becomes ASL if it no longer depends on GPL code, e.g. through alternative license agreements with the vendors of the respective code. I see nothing wrong with it, but you really do need an appropriate lawyer to give you advice on this one. Drop some money on Larry Rosen, if you are in the U.S. (you didn't say). -- John Cowan http://www.ccil.org/~cowanco...@ccil.org MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS ___ 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
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.commailto:lro...@rosenlaw.com Reply-To: Lawrence Rosen lro...@rosenlaw.commailto:lro...@rosenlaw.com Date: Saturday, August 22, 2015 at 3:11 PM To: Nigel H. Tzeng nigel.tz...@jhuapl.edumailto:nigel.tz...@jhuapl.edu, License Discuss license-discuss@opensource.orgmailto:license-discuss@opensource.org Cc: Lawrence Rosen lro...@rosenlaw.commailto: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
[License-discuss] Option to fall back from GPL to ASL
Hi all, I am relatively new here, yet this seems to be the most appropriate venue to ask a question that has been nagging me for a while now. I'm involved in a project that consists of multiple modules, most are ASL licensed, but some are GPL licensed. The reason why we use GPL for a few modules is that these modules have make use of GPLed libraries - and our understand is that due to the reciprocal licensing, that means our code must be GPL-licensed as well. However, we actually would prefer if all our code was basically under the ASL because that makes it much easier for us to refactor stuff and move code between modules if necessary. So part of this situation is covered by a contributor license agreement which says that everything that goes into the GPLed modules is essentially covered by ASL terms and conditions. However, the CLA we get isn't handed down to the users of our modules. So they essentially only see the GPL license on some modules. So why does this bother us? Lets say we have module FOO which depends on the library BAR which is GPL - so we release FOO under GPL. The vendors of BAR also offer a commercial license for BAR. If somebody buys that license, we want them to be able to use FOO under the commercial-friendly ASL terms without having to give them any extra permission. Right now, those people would still face the GPL label on FOO even though they removed it for themselves from BAR by buying a license. I wonder if it was valid to add a statement like This software is provided under the terms of the GPL *as long as mandated by the reciprocal terms of libraries used by this software*. Any code removed from this software falls back to ASL unless it continues to depend on GPL code. Likewise, all code automatically becomes ASL if it no longer depends on GPL code, e.g. through alternative license agreements with the vendors of the respective code. Or if anybody has faced a similar situation, it would be great to hear how you have resolved it. Cheers, -- Richard ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
