On Mon, Nov 28, 2016 at 9:21 AM, Greg Trasuk <[email protected]> wrote: > > Hi all: > > OK, so I’ve looked at the guacamole-client package > (guacamole-client-0.9.10-incubating.tar.gz), and I don’t think there’s any > huge long-term problems, but a few things we need to clarify. > > (I’ll just preface this by saying that there’s always some debate around > these points, so don’t necessarily take my viewpoint as definitive. I’ll try > to point to whatever policy documents we have). > > - Incubating releases are sometimes given a little slack, but generally must > adhere to http://www.apache.org/dev/release.html > - Podling releases specifically are described in > http://incubator.apache.org/guides/releasemanagement.html > > 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 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. > 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). > 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 ? 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). > 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
