On Tue, Mar 24, 2015 at 5:52 PM, Nick Wellnhofer <[email protected]> wrote:
> I'm about to release an open-source project that uses Charmonizer as build > system. Nice! > When thinking about the legal implications, a few questions popped up. It would be great if ordinary usage of Charmonizer complied with Charmonizer's licensing without requiring any extra effort on the user's part. > A project using on Charmonizer typically ships the following files > containing source code copied verbatim or derived from the Charmonizer > source: > > * charmonizer.c which contains various Charmonizer source files > * configure scripts for POSIX and Windows shells > * regen_charmonizer.pl > > Obviously I have to add a copy of the Apache License, Version 2.0. Since > Charmonizer also has a NOTICE file, any project using Charmonizer "must > include a readable copy of the attribution notices contained within such > NOTICE file" (ALv2, clause 4d). I have the choice to put the relevant > contents of the NOTICE file in a couple of places: > > * within my own NOTICE file > * within the Source form or documentation If it comes down to it, embedding the full ALv2 text and the content of Charmonizer's NOTICE in the `charmonizer.c` amalgam file is preferable to having users worry about LICENSE/NOTICE. I don't think that will be necessary though. > I think an easy and fool-proof solution would be to > > * make regen_charmonizer.pl add the contents of NOTICE to > charmonizer.c automatically. The appropriate place to do that would actually be `meld.pl`. The `regen_charmonizer.pl` script is a trivial wrapper around `meld.pl`. We'll want to rename `meld.pl` to `charmonizer-meld` or something like that and install it into e.g. /usr/local/charmonizer/bin. > * release the configure scripts and regen_charmonizer.pl into > public domain or under an extremely permissive license that > doesn't require any attribution. These files contain just a bit > of mostly trivial code. I believe that you are the sole author of the `configure` and `configure.bat` scripts under lucy.git/c. If you want to make them available under a different license, there is precedent for Apache projects shipping files under licenses other than the ALv2. I think the ALv2 might be fine, though. The charmonizer.c amalgam is a self-contained application. It does not affect the licensing of products built with it or distributed alongside it. The `regen_charmonizer.pl` script is truly trivial -- all it does is generate a `meld.pl` command line invocation. I would argue that at present it does not contain original expression and is not copyrightable. > I also think that the NOTICE files of Lucy and Clownfish should mention > Charmonizer. See > > http://www.apache.org/dev/licensing-howto.html#alv2-dep Hmm, let's see. As the primary author of that HowTo, I feel comfortable asserting that its formula does not apply in this specific case... * The licensing of the Lucy library is not affected by the licensing of the charmonizer.c amalgam, any more than Apache HTTPD is affected by the Autoconf-generated `configure` script which it ships with. * The licensing of the Lucy library is also not affected by the licensing of `charmony.h` even though that file gets included. It's basically just configuration output. See Larry Rosen's comment on <https://issues.apache.org/jira/browse/LEGAL-141> for analysis. Therefore, it is not necessary for the documentation of the Lucy library to pass along the content of Charmonizer's NOTICE. A work which includes Charmonizer as a library would need to (this is the common case addressed by the HowTo), but a work which interacts with Charmonizer as a separate application and consumes its output does not. Note that your product, if you are using Charmonizer from our git repo, may be including some code which is not yet released by Apache. That's generally frowned upon, but in this case we are not encouraging usage of Charmonizer by a user base -- you're just using it as one individual user and you understand the caveats. Over time we should move towards getting Charmonizer into a releaseable state. Once someone else can peruse the code base and make sense of it, we can check our legal analysis with either legal-discuss@apache or the Board. Marvin Humphrey
