[lucy-dev] Charmonizer licensing questions

[Nick Wellnhofer <we...@aevum.de>]

Lucifers,

I'm about to release an open-source project that uses Charmonizer as build 
system. When thinking about the legal implications, a few questions popped up.

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

I think an easy and fool-proof solution would be to

* make regen_charmonizer.pl add the contents of NOTICE to
   charmonizer.c automatically.
* 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.

This way, the only requirement would be to ship a copy of the ALv2.

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

Nick

Re: [lucy-dev] Charmonizer licensing questions

[Nick Wellnhofer <we...@aevum.de>]

On 26/03/2015 01:58, Marvin Humphrey wrote:
> 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 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.
>
>> 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.

I agree that the licensing of Charmonizer doesn't affect the licensing of the 
product built with it. Still, the meld.pl script concatenates parts of the 
Charmonizer source code without any changes. So I can't see how the ALv2 
licensing terms wouldn't apply to the generated charmonizer.c and how 
distributing the code in charmonizer.c wouldn't require to comply with section 
4 of the ALv2. This means that every project using Charmonizer

1. must distribute a copy of the ALv2.
2. must include the relevant portions of the Charmonizer NOTICE.

Nick

Re: [lucy-dev] Charmonizer licensing questions

[Marvin Humphrey <ma...@rectangular.com>]

On Tue, Mar 24, 2015 at 5:52 PM, Nick Wellnhofer <we...@aevum.de> 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