On 1/5/15, 10:48 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>My eyes kind of glazed over at the beginning of the discussion, so I’m >kind of with Erik on this… Well, at least you are trying to follow. Hopefully, reviewing is easier than figuring out what changes to make. While it would be great to have other PMC members scour everything carefully, it will be helpful if you at least take a quick look. Here’s my ‘short’ summary: -Fundamentally, the LICENSE needs to mention any non-ASF or non-Apache Licensed 2.0 source code or other materials in any zip or tar.gz you review when voting. -All licenses, including ASF-based Apache 2.0 licensed dependencies may mention certain things they want the user to be notified of. Those go in NOTICE. -Since the binary zip or tar.gz contains things we download that aren’t in the source zip or tar.gz, we need to have different LICENSE and NOTICE files in the binary vs source packages. -Apache also wants every jar we create to have a LICENSE and NOTICE in META-INF that is tuned to the contents of that jar and not the collection of licenses for the release. So, the review should be something like: 1) get a source package, expand it. 2) look at LICENSE. See list of Subcomponents. 2a) Are any listed that aren’t actually in the package? 2b) Do you know of anything that is missing? Note that source code that belongs to another Apache project that is licensed under Apache 2.0 doesn’t need to be listed here. It does if it is under an older Apache license like 1.1, or is under Apache 2.0 but not an Apache project, like if we borrowed some code from GoogleCode or something like that. 3) look at NOITCE. It will have some copyright info about Adobe. That’s ok. 3a) Is the year right? 3b) Where did the rest of the text come from? It should come from the licenses and/or notices for other source code and fonts and images we have included in the source package. 3c) Did we miss anything? This whole thing started because I noticed we mentioned MPL in LICENSE even though we only download OSMF (and Saxon). The OSMF source doesn’t get included in our source package. Then on further digging, Justin found more issues, especially with the binary package. The binary package review works just like the source package review, except that the stuff in NOTICE will also come from any jars we’ve downloaded and included in the package. Sometimes the jar’s LICENSE and NOTICES are located in a folder near the jar, other times the jar has the LICENSE and NOTICE packaged in the jar. To extract files from a jar, run jar -xf <jar>. It will put the files in the current folder so maybe do that in a temporary folder. Most jars put LICENSE and NOTICE in a META-INF folder, but some put it elsewhere and some don’t include it at all. So yeah, that’s painful, but basically, the process is to look for jars, look for legal files near the jars, dump jars, look for things in the dump that look like legal stuff that implies that we have to notify the customer about something and make sure we’ve mentioned it in NOTICE. Sometimes notices are in README files as well. Saxon is tricky in that it has some legal files for code that isn’t in the actual jar we use so it doesn’t matter. Another part of the binary package review is to dump each Flex jar and make sure it has a LICENSE and NOTICE and the contents of those files makes sense for the contents of the jar. And, BTW, it might be easier for folks to wait for Justin to fix up the Saxon stuff and build script before reviewing all of this. Right now the LICENSE points to places that don’t exist. But I really think we need folks to actually look or maybe divide up the review. Given that Justin and I voted +1 on many releases with these or similar problems in the past, you can’t trust us to find everything every time. Also, I am hopeful that this could be the last time we have to go digging this hard. In theory, if we try to keep track of major new developments in between releases, then we have an idea if any serious review of LICENSE and NOTICE might even be required for the next release, so it shouldn’t always take this kind of time before you vote in future releases. Our mail archives seem to show that the binary package never got any sort of review from the mentors which is why it had this many issues. The mentors probably didn’t bother because binary packages aren’t official Apache products so it may have just gotten lost in the noise. HTH, -Alex
