— snip -- >> >> First, what Apache releases is source code. So what we’d like to see is a >> release artifact that is purely source code. A big part of the Apache brand >> is the assurance that what we release is provably subject to the Apache >> License, which allows others to use the software liberally. We generally >> assume that we can’t certify anything that has binaries in it. So, we’d >> want to have a “source” release artifact that doesn’t have any compiled >> classes or jar files. We can also distribute “convenience binaries” but the >> actual release artifact should be purely source code. >> > > Hi Greg, > > Is this not what we're doing? The "guacamole-client" and > "guacamole-server" artifacts are 100% of the Guacamole source and > contain no binaries. The convenience binaries provided are build > artifacts from "guacamole-client". The source artifacts and > convenience binaries are carefully separated from each other in the > release notes: > > http://guacamole.incubator.apache.org/releases/0.9.10-incubating/ >
You’re right - I managed to find a binary distribution the first time. My bad! >> You may or may not have come across “Apache RAT”, or the Release Auditing >> Tool. This is part of the Apache Creadur project, and is a very useful tool >> to check licensing status of files. When I run RAT agains guacamole-client, >> we can see that the archive is full of compiled classes and a few jar files. >> That’s going to be a problem for releasing the artifact. >> > > The RAT plugin is actually already part of the guacamole-client build, > which will fail unless it passes RAT. > > When you say you are running RAT against guacamole-client, are you > running it against guacamole-client after having already run "mvn > package" (or similar), and thus RAT is choking on build artifacts and > their dependencies? There are no compiled classes nor .jar files > within the guacamole-client artifact itself. > When I run ‘mvn clean install’ or ‘mvn clean package’, I get a rat failure: 1 Unknown Licenses ***************************************************** Files with unapproved licenses: /Users/trasukg/devel/guacamole/guacamole-client-0.9.10-incubating/guacamole/src/main/webapp/generated/templates-main/templates.js I agree that appears to be a false positive (as it’s a generated file) - maybe we’re missing an exclusion? >> Second - JavaScript libraries. I’m not sure what other projects do, but >> personally I’m not comfortable with distributing libraries in the source >> distribution. In fact, I’m not a fan of having them in source control. >> Would it be possible to assemble them into the binary at build time? I’m >> pretty sure there are artifacts in Maven Central for Angular and JQuery - >> certainly something like Bower should be an option if not? >> > > I'm not a fan of including them in the source distribution either. If > they are included in Maven Central, then I see no reason why we can't > migrate to doing that. I expect migrating to an entirely different > build system like Bower would be infeasible, unless there is a means > of integrating it cleanly with Maven (I have not looked into this). I don’t think that’s a blocker, (although other IPMC members might). So, it would be great to look into this for the next release. However, if we leave the components in, we’ll need to update the LICENSE file. I stand to be corrected, but I don’t think the MIT license requires anything in the NOTICE file, nor does the font license, at least from my quick read of it. > >> Third - licensing - The LICENSE file should include all the licenses that >> apply, not just the Apache license. The idea is to give a downstream user a >> clear overview of what obligations they’re taking on. I believe I’ve seen a >> “Guide to constructing LICENSE and NOTICE”, but I don’t have it handy right >> now. >> > > Are you referring to > http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice > ? > That’s the one! > My understanding is that the LICENSE file needs to contain the > licenses of bundled dependencies. If we remove the bundled JavaScript > libraries, relying instead on Maven, I believe that would mostly > resolve this, correct? Outside of those libraries, I believe the only > bundled dependency is a font under SIL Open Font License (the > "Carlito" font). > License file still needs to be accurate in the “convenience binary”, so yes, you’ll need to update. That leads to the odd situation of having different LICENSE and NOTICE files in the source and binary distributions, but unfortunately, it is what it is. It’s probably the most common reason for ‘-1’ votes on incubator releases. >> Good start! >> > > Thanks! ... but then ... -1? +1? Excluding the issues you mention > regarding RAT, which I believe are false positives, are you saying > that we need another RC to address the above? > > - Mike -1 (sorry). But so so close - from what we discussed above, I think just the license files need updating for now. Getting the javascript libraries out can wait for later. Another thing you’ll want to deal with - is the next release candidate called 0.9.10 or 0.9.11? I think the Maven ecosystem is happiest if you move on to 0.9.11 (and put in the release notes that 0.9.10 was skipped), but there are a variety of opinions on that (to put it mildly). It’s up to the PMC to decide on a policy. Regards, Greg Trasuk
