You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2020/05/05 22:39:45 UTC
Choice between 2 approaches in JavaFX dependency?
Hello all
JavaFX is licensed under GPL + classpath exception, which is a category
X license [1]. It means that Apache SIS can not redistribute JavaFX. But
we can use a preinstalled (by user) JavaFX however. It is allowed if the
GPL software is required only for an optional part of the project [2] —
in our case only one module. Question is how to link that to the
project. I see two approaches:
First approach is to let users download and install JavaFX themselves
and set an environment variable. The Maven build configures itself
automatically when that environment variable is detected, or otherwise
skips the sis-javafx module. This is the current approach.
* Pros:
o Safest approach regarding licenses.
o Developer has the same environment than what users will have
(i.e. rely on preinstalled JavaFX).
o Same approach than how we handle EPSG database (i.e. define
SIS_DATA environment variable or let users add Maven dependency
themselves).
* Cons:
o Requires explicit action by developer before (s)he can work on
the sis-javafx module.
* Counter-arguments to the cons:
o This configuration needs to be done only once.
o Users will have to do this configuration anyway, so maybe we
should eat our own food.
Second approach is to declare JavaFX as a Maven dependency with
"provided" scope. This is the approach experimented in a separated
branch "javafx-on-11".
* Pros:
o Developers can work immediately on sis-javafx module without
configuring anything.
* Cons:
o Downloading automatically GPL libraries for building an Apache
project seems a gray area [3] (it is clearly forbidden in
distribution, but we are talking about building).
o We would be handling two category X licenses — EPSG and JavaFX —
in two different ways.
o Developers would not be in the same condition than users, so we
may miss difficulties that users may encounter.
* Counter-arguments to the cons:
o The 2 first cons can be mitigated by isolating JavaFX
dependencies in a Maven profile that developer must activate
explicitly.
I searched for guidance on Apache legal issues tracker. Some useful
comments that I found are:
"If you imagine that Category X source and binaries are peanuts and
some of your customers have a peanut allergy, the downloading and
building of your source and binary artifacts should not result in
peanut contamination of the user's machine or network." [4]
"If Category X dependencies are downloaded automatically during
development, users should be warned to make them aware of the
possible limitations as compared to the Apache License." [5]
So given [3], [4] and [5], it seems that at the very least the second
approach (Maven dependency), even with "provided" scope, would have to
be isolated in a profile. My question is: should we have a Maven
dependency at all, or should we just rely on the first approach
(installation by user)? My own preference is for approach #1 because of
above-listed pros and cons, but I know that other developers prefer
approach #2, which is why I ask.
Martin
[1] https://www.apache.org/legal/resolved.html
[2] https://www.apache.org/legal/resolved.html#optional
[3] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3C200801250935.54242.dkulp@apache.org%3E
[4] https://issues.apache.org/jira/browse/LEGAL-299?focusedCommentId=15978877&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15978877
[5] https://issues.apache.org/jira/browse/LEGAL-462?focusedCommentId=16861893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16861893
Re: Choice between 2 approaches in JavaFX dependency?
Posted by Johann Sorel <jo...@geomatys.com>.
I also vote for the second one.
There is also a third approach : we could move the javafx module on
github with an explicit different license.
Johann Sorel
On 06/05/2020 02:38, Adam Estrada wrote:
> I am good with either but would favor the easiest one which is #2
>
> Adam
>
> Sent from my iPhone
>
>> On May 5, 2020, at 6:39 PM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>>
>> Hello all
>>
>> JavaFX is licensed under GPL + classpath exception, which is a category X license [1]. It means that Apache SIS can not redistribute JavaFX. But we can use a preinstalled (by user) JavaFX however. It is allowed if the GPL software is required only for an optional part of the project [2] — in our case only one module. Question is how to link that to the project. I see two approaches:
>>
>> First approach is to let users download and install JavaFX themselves and set an environment variable. The Maven build configures itself automatically when that environment variable is detected, or otherwise skips the sis-javafx module. This is the current approach.
>>
>> * Pros:
>> o Safest approach regarding licenses.
>> o Developer has the same environment than what users will have
>> (i.e. rely on preinstalled JavaFX).
>> o Same approach than how we handle EPSG database (i.e. define
>> SIS_DATA environment variable or let users add Maven dependency
>> themselves).
>> * Cons:
>> o Requires explicit action by developer before (s)he can work on
>> the sis-javafx module.
>> * Counter-arguments to the cons:
>> o This configuration needs to be done only once.
>> o Users will have to do this configuration anyway, so maybe we
>> should eat our own food.
>>
>> Second approach is to declare JavaFX as a Maven dependency with "provided" scope. This is the approach experimented in a separated branch "javafx-on-11".
>>
>> * Pros:
>> o Developers can work immediately on sis-javafx module without
>> configuring anything.
>> * Cons:
>> o Downloading automatically GPL libraries for building an Apache
>> project seems a gray area [3] (it is clearly forbidden in
>> distribution, but we are talking about building).
>> o We would be handling two category X licenses — EPSG and JavaFX —
>> in two different ways.
>> o Developers would not be in the same condition than users, so we
>> may miss difficulties that users may encounter.
>> * Counter-arguments to the cons:
>> o The 2 first cons can be mitigated by isolating JavaFX
>> dependencies in a Maven profile that developer must activate
>> explicitly.
>>
>> I searched for guidance on Apache legal issues tracker. Some useful comments that I found are:
>>
>> "If you imagine that Category X source and binaries are peanuts and
>> some of your customers have a peanut allergy, the downloading and
>> building of your source and binary artifacts should not result in
>> peanut contamination of the user's machine or network." [4]
>>
>> "If Category X dependencies are downloaded automatically during
>> development, users should be warned to make them aware of the
>> possible limitations as compared to the Apache License." [5]
>>
>> So given [3], [4] and [5], it seems that at the very least the second approach (Maven dependency), even with "provided" scope, would have to be isolated in a profile. My question is: should we have a Maven dependency at all, or should we just rely on the first approach (installation by user)? My own preference is for approach #1 because of above-listed pros and cons, but I know that other developers prefer approach #2, which is why I ask.
>>
>> Martin
>>
>> [1] https://www.apache.org/legal/resolved.html
>> [2] https://www.apache.org/legal/resolved.html#optional
>> [3] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3C200801250935.54242.dkulp@apache.org%3E
>> [4] https://issues.apache.org/jira/browse/LEGAL-299?focusedCommentId=15978877&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15978877
>> [5] https://issues.apache.org/jira/browse/LEGAL-462?focusedCommentId=16861893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16861893
>>
Re: Choice between 2 approaches in JavaFX dependency?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Thanks Adam and Johann. I applied the Maven configuration done by Johann
with some modifications. The JavaFX dependencies are included only if
the "javafx" profile is activated, and they are declared with "provided"
scope. The previous approach using a pre-installed JavaFX installation
(declared by PATH_TO_FX environment variable) has not been removed since
I think we will need this approach for what may be distributed to end user.
I edited the NOTICE file. I'm not sure how we are supposed to declare
dependencies of optional module. There is my try:
https://github.com/apache/sis/blob/geoapi-4.0/NOTICE
Martin
Le 06/05/2020 à 02:38, Adam Estrada a écrit :
> I am good with either but would favor the easiest one which is #2
>
> Adam
Re: Choice between 2 approaches in JavaFX dependency?
Posted by Adam Estrada <es...@gmail.com>.
I am good with either but would favor the easiest one which is #2
Adam
Sent from my iPhone
> On May 5, 2020, at 6:39 PM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>
> Hello all
>
> JavaFX is licensed under GPL + classpath exception, which is a category X license [1]. It means that Apache SIS can not redistribute JavaFX. But we can use a preinstalled (by user) JavaFX however. It is allowed if the GPL software is required only for an optional part of the project [2] — in our case only one module. Question is how to link that to the project. I see two approaches:
>
> First approach is to let users download and install JavaFX themselves and set an environment variable. The Maven build configures itself automatically when that environment variable is detected, or otherwise skips the sis-javafx module. This is the current approach.
>
> * Pros:
> o Safest approach regarding licenses.
> o Developer has the same environment than what users will have
> (i.e. rely on preinstalled JavaFX).
> o Same approach than how we handle EPSG database (i.e. define
> SIS_DATA environment variable or let users add Maven dependency
> themselves).
> * Cons:
> o Requires explicit action by developer before (s)he can work on
> the sis-javafx module.
> * Counter-arguments to the cons:
> o This configuration needs to be done only once.
> o Users will have to do this configuration anyway, so maybe we
> should eat our own food.
>
> Second approach is to declare JavaFX as a Maven dependency with "provided" scope. This is the approach experimented in a separated branch "javafx-on-11".
>
> * Pros:
> o Developers can work immediately on sis-javafx module without
> configuring anything.
> * Cons:
> o Downloading automatically GPL libraries for building an Apache
> project seems a gray area [3] (it is clearly forbidden in
> distribution, but we are talking about building).
> o We would be handling two category X licenses — EPSG and JavaFX —
> in two different ways.
> o Developers would not be in the same condition than users, so we
> may miss difficulties that users may encounter.
> * Counter-arguments to the cons:
> o The 2 first cons can be mitigated by isolating JavaFX
> dependencies in a Maven profile that developer must activate
> explicitly.
>
> I searched for guidance on Apache legal issues tracker. Some useful comments that I found are:
>
> "If you imagine that Category X source and binaries are peanuts and
> some of your customers have a peanut allergy, the downloading and
> building of your source and binary artifacts should not result in
> peanut contamination of the user's machine or network." [4]
>
> "If Category X dependencies are downloaded automatically during
> development, users should be warned to make them aware of the
> possible limitations as compared to the Apache License." [5]
>
> So given [3], [4] and [5], it seems that at the very least the second approach (Maven dependency), even with "provided" scope, would have to be isolated in a profile. My question is: should we have a Maven dependency at all, or should we just rely on the first approach (installation by user)? My own preference is for approach #1 because of above-listed pros and cons, but I know that other developers prefer approach #2, which is why I ask.
>
> Martin
>
> [1] https://www.apache.org/legal/resolved.html
> [2] https://www.apache.org/legal/resolved.html#optional
> [3] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3C200801250935.54242.dkulp@apache.org%3E
> [4] https://issues.apache.org/jira/browse/LEGAL-299?focusedCommentId=15978877&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15978877
> [5] https://issues.apache.org/jira/browse/LEGAL-462?focusedCommentId=16861893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16861893
>