You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Alex Harui <ah...@adobe.com> on 2015/06/18 01:46:22 UTC
Google Closure Compiler License
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
Re: Google Closure Compiler License
Posted by Henri Yandell <ba...@apache.org>.
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 <ah...@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
>>
>>
Re: Google Closure Compiler License
Posted by Alex Harui <ah...@adobe.com>.
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 <ba...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, June 17, 2015 at 9:43 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@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 <ah...@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
Re: Google Closure Compiler License
Posted by Henri Yandell <ba...@apache.org>.
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 <ah...@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
>
>