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
<[email protected]> 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/%[email protected]%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
