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 >
