www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Google Closure Compiler License
Date Thu, 18 Jun 2015 21:25:21 GMT
Removal would be the issue rather than addition. Additions are under MPL,
but a removal would mean NPL code hanging around (or needing to be removed
in a code update).

On Thursday, June 18, 2015, Alex Harui <aharui@adobe.com> wrote:

>  Actually, I was just proposing that they try to take all of their
> changes and re-apply them to an MPL version, but your idea seems better.
>  GCC claims there are two files that are based on Rhino.  I did a diff in
> the Rhino repo of the version GCC claims to have started with vs the
> version where Rhino changed to MPL.  There are a few differences.  I can
> post them here if you want to see them, but what kinds of things would
> block GCC from just claiming they can switch to MPL like Rhino did?
>  I saw the addition of a new entry or two to an enum in each file, a new
> enumToString method, and a recursive tree walk.
>  Thanks,
> -Alex
>   From: Henri Yandell <bayard@apache.org
> <javascript:_e(%7B%7D,'cvml','bayard@apache.org');>>
> Reply-To: "legal-discuss@apache.org
> <javascript:_e(%7B%7D,'cvml','legal-discuss@apache.org');>" <
> legal-discuss@apache.org
> <javascript:_e(%7B%7D,'cvml','legal-discuss@apache.org');>>
> Date: Wednesday, June 17, 2015 at 9:43 PM
> To: "legal-discuss@apache.org
> <javascript:_e(%7B%7D,'cvml','legal-discuss@apache.org');>" <
> legal-discuss@apache.org
> <javascript:_e(%7B%7D,'cvml','legal-discuss@apache.org');>>
> Subject: Re: Google Closure Compiler License
>  I agree with your proposal in the linked issue 273.
>  * identify the version of files originally imported from Rhino.
> * identify an MPL version - presumably at the time of relicense.
> * compare.
> * if the same, relicense at GCC. If different, review further.
> On Wednesday, June 17, 2015, Alex Harui <aharui@adobe.com
> <javascript:_e(%7B%7D,'cvml','aharui@adobe.com');>> wrote:
>> Hi,
>> This week’s question is about the license for the Google Closure Compiler
>> (abbreviated as GCC in this email) [1].  If you go to the link, you can
>> scroll down through their README.  While it says the GCC license is AL
>> 2.0, it turns out a dependency on Rhino was based on a version that was
>> under Netscape Public License.
>> Apache Flex wants to use GCC.  We don’t need to bundle it, we can download
>> it when installing the Apache FlexJS SDK.  I’ve asked on [2] if they could
>> find a way to get rid of the NPL dependency.
>> The FlexJS compiler calls into the GCC’s compiler.jar in two ways:  1)
>> During the build we ask it to parse a bunch of JS and then access the
>> parse tree via Java (we aren’t running it from the command line like you
>> would typically call compilers during a build).  2) When our customers are
>> building their apps from our SDK, we pass their JS through GCC to minify
>> it.  Again we don’t run GCC from the command-line; we call its Java APIs
>> and filter its error output before showing any remaining errors to the
>> customer.
>> When does a dependency on a compiler stop being a build tool dependency
>> and become a true dependency?  What does "component can be relied on if
>> the component's licence terms do not affect the Apache product's
>> licensing” mean in [3]?
>> Given that Rhino itself has been re-licensed as MPL, is GCC’s dependency
>> still NPL because the version they started with was NPL?
>> Thanks,
>> -Alex
>> [1] https://github.com/google/closure-compiler
>> [2] https://github.com/google/closure-compiler/issues/273
>> [3] http://www.apache.org/legal/resolved.html#prohibited

View raw message