[TASK] Review WISE Dependency Licenses

[RobBryce]

Follow-up on #50, which lists some of the 3rd party dependencies, from a variety of sources.

Follow-up on #52, which suggests AGPL.

Various projects have different licensing. I doubt that generic language library implementations (such as std::time in C++) need reviewed, but along with #50, all 3rd party licensing needs itemized for compatibility with AGPL, or choice of license. Some licenses are truely incompatible (e.g. w/r to clauses on patents).

[RobBryce]

java_licenses.xlsx

Attached is an XLSX file for dependencies to Java components: REDApp (then REDAppLib), Builder, Manager.

The list is too large to capture in a diagram. Additional, I'm finding items that need to be reviewed:

• Various dependencies (direct and indirect) have reported vulnerabilities. I have not investigated these vulnerabilities in interests of getting this list online. I suspect that many are benign, and/or can be dealt with when dependencies are migrated to the latest versions.
• There are inconsistencies in versions of dependencies (direct and indirect).
• Some items are dual licensed. One item (that I found) has a custom license.

I explored indirect vulnerabilities when it was clear that the Maven repository website wasn't always listing vulnerabilities from dependencies. This also showed how many different licenses are used in dependencies of dependencies.

I've included URL's to each project as I could find them, so we can follow up as appropriate.

I need to start a similar XLSX for C++ components. Possibly for other components (in other languages), too. I'd like to discuss the path of this work before proceeding (and possibly wasting my time on details that may not be important here).

Note that there is a potential for the C++ work to become "messier" since some code dates back prior to general acceptance of some license terms, such as code posted on sites like CodeProject and CodeGuru, where each other could have stated use of the project in addition to a generic direction from the site. However, a lot of that code is captured in MFC_Extensions which has a very reduced role in PSaaS (in comparison to Prometheus).

[spydmobile]

I have been reading on the complications of licences like MIT, APACHE ETC under AGPL. Here is what I have found.

• Apache
• MIT
• BSD 3-clause
• LGPL
• EDL 1.0
• GPL 1.1
• EPL 2.0

None of these (but one - see below) are a problem to include in an AGPL application, but they do have custom licence requirements, you need to fulfill.

...With the single exception of: javax.media:jai_core:jar:1.1.3 licenced under a sketchy JDL (Not the official JDL-1.1.X) licence, the lib seems outdated and maybe even unmaintained. When a project website does not support SSL its a good indicator its no longer maintained. On February 2018, Google announced the intention for chrome officially start rejecting HTTP sites in Favor of HTTPS on July 2018 and all other browsers followed suit not long after. I find that any site that does not conform to this new standard demonstrates an inability of a project to keep up (notice our very own firegrowthmodel.ca still does not support SSL - indicates poor maintenance of the website.).

I would consider replacing the javax.media:jai_core:jar:1.1.3 library with something that is better maintained.

[RobBryce]

Are you comfortable with the presentation and content of the XLSX sheet? Please let me know if there are any revisions to this that you may want, then I'll proceed to document other dependencies of the project.

[spydmobile]

No, it was good thanks, please proceed. :)

[RobBryce]

psaas2.xlsx

Attached is an XLSX file covering PSaaS and related binaries. There's a lot in here where licenses still have to be defined. Currently, PSaaS.exe references a DLL structure showing the same kind of division of functionality as the old COM DLL's. However, that could be modified if/as appropriate.

This set was generated using https://github.com/lucasg/Dependencies and appears to be accurate. After generating the output, I filtered out all system and Windows DLL's.

I've also included FBPTester, and one line for usage of the PROTO file format standard.

FBPTester includes a C implementation of the FBP standard provided by CFS. Its license is as follows:

Subroutine of FBP.C version 4.4 Aug,2007

 Canadian Forest Fire Behaviour Prediction System

This code is copyright of the Canadian Forest Service, Natural Resources Canada (1992-2005) It is provide free of charge to anyone who wishes to incorporate it within their forest fire management applications, however users should note in their application that the FBP calucaltions come from the Canadianf Forest Services Fire Behaviour Prediction System. The Canadian Forest Service has gone through considerable testing to ensure that these computer functions duplicate the system as laid out in ST-X-3 (The Development and Structure of the Canadian Forest Fire Behaviour Prediction System (1992)) and the subsequent corrections and additions to the system (the draft "FBP Note"), however no guarentte is given as to the absolute accuracy of the code.

There is also some code to validate FWI calculations. The original source of this implementation is actually unknown but believed to come from CFS. There's no comments or documentation for its source or license.

Finally, there is some legacy code that was source from StackOverflow, CodeGuru and CodeProject websites, sourced over the past 2 decades. A lot of that is only associated with the Prometheus UI, but I haven't reviewed to confirm whether these forum projects and code have contributed to PSaaS, or not.

[spydmobile]

From Exec: @RobBryce see this through to completion and identify if dependancies are compliant or not please.

[RobBryce]

@spydmobile - do you need a quotation for this?

[spydmobile]

@RobBryce Start with an estimate first and we will go from there.