IMO, there are 3 categories of inclusion: 1) Bundling an entire release artifact. 2) Bundling an entire file from a release artifact where the top-level license applies to that file. 2a) and then modifying that file 3) Copying portions of an existing work into an ASF-owned fie.
Then there is a dimension of "compliance" where either the artifact and/or file has properly executed its license requirements by having a copy of the license in a downloadable file, and a reasonable header in each file. For #1 and #2, when the artifact is compliant, it is easy to copy the license and header as per the how-to. But when we get to #3 and the artifacts are not compliant, I think it becomes a judgement call. But if you are going to quote policy and precedent, I am going to take the time to ask about other policy and precedent that seems to be in conflict with your proposal. And then we have to decide as a PMC whether to accept your proposed changes based on policy, or just preference. These exercises should be somewhat educational in order to help make it worth the time we spend on it, so I am going to make sure the information here is accurate and that how-to guidelines for common cases are not confused with policy. None of us are lawyers and this stuff can be confusing enough that both of us have been inaccurate in our advice in the past. More responses in-line. On 9/20/16, 12:44 AM, "Justin Mclean" <jus...@classsoftware.com> wrote: >Hi, > >> Are you proposing to get the OpenFL community to accept headers on >>their source >> files by submitting a pull request on their repos and then replicating >> that header under the ASF header in Matrix.as? > >No I was going to add a header to make it clear that the code wasn’t >originally Apache licensed and originally come from somewhere else. Matrix.as [4] currently has the following added by me: // Implementation derived fromL // https://github.com/openfl/openfl/blob/develop/openfl/geom/Matrix.hx // available under MIT License. I added this after the release. This is because whatever code Harbs did borrow came from a file that did not have a header. What policy or precedent are you saying requires the synthesis of a header on behalf of OpenFL? Remember that a senior Apache member recommended filing an upstream issue in this email [5]. If you help make OpenFL more "compliant" by filing the upstream bug or pull request then they will have an approved header that we can copy. > >> And are you going to have the build download their LICENSE.md file from >>their >> repo and adjust our LICENSE to point to it? > >Yes but only downloading it once and adding a file to our repo. It can be >found here. [1] I'd only use the MIT bits as the other bits don’t apply >to what we used. Given that the source header policy [2] says not to modify third-party headers, it seems odd to be modifying a third-party license file. I've always assumed this was one scenario where it was better to copy the full text of the applicable parts of the license into our LICENSE. Have you seen a past decision that it is ok to synthesize or subset a third-party LICENSE file in order to use a pointer instead a copy? > >> Again, we are not consuming an entire artifact or file. > >The original code is copyright other people and under a different >license, as per policy [2] changes to a differently licensed file keeps >the original license. Even if it was extensively modified (and the bar is >generally very high for that) it would still be useful to note that it >was originally owned by someone else and under a different license. The >guiding principle also applies here, if it bundled and permissive then it >needs to be mentioned in license. And it’s also important that we should >abide by the terms of the MIT license and have the copyright owner and >full text somewhere. We have noted that portions of this file came from someone else under a different license. The copyright owner and full text are in LICENSE [6]. I don't see any policy violations here, so any changes here are based on preference, assuming it really is ok to modify someone's license file. If you are certain it is ok to subset a third-party license file, then go ahead and make that change. I just want to make sure folks understand this change is not driven by policy. > >> Are you proposing to submit a pull request to the Flat UI folks to >>have them put a correct >> MIT license in their repo or README.md? > >No. They do however link to MIT [3] on their page so it clear what their >intent is and what the license text would be. To me, [5] recommends having the FlatUI folks make changes so their use of the MIT license is "compliant" and thus it we handle this dependency consistently with how we handle the OpenFL dependency. Otherwise, it seems odd for you to synthesize a version of the MIT license on their behalf in our repo. You would be putting their copyright on it even though you are effectively the copyright owner of that file. Feels like signing a contract for someone. If you contribute that file to FlatUI and they accept it, then they are effectively "signing the contract". The gist of [5] to me says that we should not be fixing other folks' LICENSE documentation errors on their behalf, so it seems to contradict what you are proposing. > >> when my manager returns in about 3 weeks I will seek permission to make >>the donation so we can avoid >> debating this issue and maybe get some positive attention from the >>CreateJS community. > >Adding the header is simple and covers us until that has been sorted out. >"Worse case" I’ll be happy to remove the header if required at a later >date. IMO It’s better to have a possible documentation issue than a >possible licensing error. One you add a header to make a file third-party, can you remove the header later? IMO, it is safer to not give away things we shouldn't. It will all get sorted out by donating these files to CreateJS. There is no major risk mandating this change now. > >> If we do the steps above, what else will need a pointer? And, if you >>have >> time, what policy document requires pointers? > >It’s only in the how to (that I’m aware of), but Ross (+ others) has said >to use the short form many times. It makes the license smaller and easier >to understand for anyone looking at. Oddly I can’t find legal policy that >says the full text must be copied into LICENSE either, can you provide a >link to that please? I didn't say there was any requirement for copies. I prefer pointers as well, but I don't know if it has to be to downloadable artifacts, or if pointers to synthesized artifacts is also ok. You stated that we would be "more in line with policy" by going to pointers and I'm not clear that is an accurate statement. >So am I good to make all of the above changes? I guess I don't understand why we should be ignoring the advice in [5]. I'm also not sure about pointers to synthesized licenses. I also don't want to spend a lot of time arguing about it, so if we agree to leave the CreateJS stuff for now, I won't veto any changes for OpenFL and Flat, but I believe these changes are being made on preference not policy, and may not be what senior Apache members recommend. Thanks, -Alex > >Thanks, >Justin > >1. https://github.com/openfl/openfl/blob/develop/LICENSE.md >2. https://www.apache.org/legal/src-headers.html#3party (see points 3 + 4) >3. https://opensource.org/licenses/mit-license.html > [4] https://git-wip-us.apache.org/repos/asf/flex-sdk/repo?p=flex-asjs.git;a=blo b_plain;f=frameworks/projects/Core/src/main/flex/org/apache/flex/geom/Matri x.as;hb=refs/heads/develop [5] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201604.mbox/%3c cabd8flxg7o1p86modpc3uqzbipu47bjgrewbcxgjjglycqd...@mail.gmail.com%3e [6] https://git-wip-us.apache.org/repos/asf/flex-sdk/repo?p=flex-asjs.git;a=blo b_plain;f=LICENSE;hb=refs/heads/develop
