Comments on the JOINUP Licensing Assistant

On 19 june 2019:

Bastien Guerry – reference FLOSS expert advising the French Administration wrote (translation):

I had the opportunity to attend the presentation of M. Jean-Paul De Baets (EC) on the Joinup Licensing Assistant (JLA). The tool looks very interesting. I am going to ask him where I could obtain the source code in order to proceed to a translation in French as the case may be.

Phil Odence - General Manager, Black Duck On-Demand wrote:

I’m the Chair of the SPDX group. The work you’ve done on the JLA looks very interesting and it’s great that you adopted the SPDX names. I chair monthly SPDX General Meeting calls and like to include guest speakers. Would you like to present in one?

(Presentation for SPDX group was indeed scheduled on September 5 2019).

Choosealicense.com is one of the first site known for having listed FLOSS licences attribute in a well presented and comprehensive manner. However, the site focuses on a very limited set: a basic selection of three licences, complemented with four additional possibilities and in appendix, a static table listing a total of 34 licences (27 being added to the seven mentioned previously) with their permissions, conditions and limitations.

Choosealicense links to the Joinup Licensing Assistant as an additional ressource. See: https://choosealicense.com/about/

According to a tweet from Twipu (https://www.twipu.com/Joinup_eu/tweet/1149291497172426757) on the JLA, comparing & selecting open licences is easier than ever! @github http://bit.ly/2RWzeJt 

Hey, thanks for the great license picker!

I have a feature request: it would be great if the requirements selection was part of the URL so I could send people the URL with for instance EU law and OSI approved pre-selected.

Thanks and keep up the good work.

Great work, I do have a few questions though:

If I look at GPL-3.0-only I see that this license is not compatible with itself. Also you can neither sublicense the code nor are you not allowed to sublicense it.

I am not really sure I understand the implications of this. The first may be a general omission (beacause code in GPL is already GPL so the concept of compatibility is a bit odd) but I do not really see how something can be both not "can sublicense" and not "cannot sublicense".

@Yan Grange: of course you are right, a reciprocal license is always compatible with itself. The issue we have is due to the willingness (apparently) from the FSF to request the introduction of the SPDX identifiers "-only" and "-or-later" for all the GNU licenses. This is quite unique as there are no SPDX identifiers "Apache-2.0-only" or "MIT-only". We may assume that the FSF has requested this specificity for finally promoting the "-or-later" option: when licensors do not opt for "or-later" they will be blocked to "-only".  But the issue with this new policy is that, while "Licensing under the GPL" (old policy) was compatible with all GPL versions (like GPL-2.0-or later), because you may select any of them, the new option "Licensing under the GPL-3.0-only" is not, because limited to itself. With the EUPL, the policy is different: "Licensing under the EUPL" means automatically the last version. So far, it seems that the FSF policy is not followed by other license stewards, questioning the real benefits from this policy that are not obvious...  All contributions on this point would be welcome! 

With reference to the Joinup Licensing Assistant — White paper v1.00 PDF dated 14 November 2018.

Figure 4 on page 13 has colored spots but no indication of what those different colors actually mean: green, blue, and red.  Particularly difficult to unscramble when some columns contain more than one color.

TIA, R.

Many thanks.  That is useful.  I participate in the Open Energy Modelling Initiative (openmod) and the Free Software Foundation Europe (FSFE) Legal Network (LN) communities.  And have interests in:

• public data‑capable license interoperability and selection (CC‑BY‑4.0 generally offers the best choice in my view, together with CC0‑1.0 for any accompanying metadata)
• the legal status of the high‑level data standards covering semantics in particular (vocabularies, ontologies, schemas, reference architectures) that underpin energy system analysis — and whether proprietary standards (like the IEC CIM) can create legally encumbered derivative works when used to inform otherwise open‑source software and otherwise open‑licensed datasets

Much of current European Union policy is headed toward data commodification with little to no carve out for public interest (for instance, the proposed novel data producers right (DPR) would be a disaster for open energy systems analysis).  Statutory reporting remains legally encumbered (for instance, the ENTSO‑E Transparency Platform and the EEX website).  Much of the Commission‑sponsored science remains published under non‑open bespoke licenses (for instance, the ERA5 reanalysis and the IIASA scenarios database).  The 96/9/EC database directive is fully problematic (this IPR should move to a non‑automatic right requiring application, registration, and annual payment, as per patents and trademarks).  The definition for "re‑use" in the Open Data Directive (§2.11) is a legal travesty, indeed genuine reuse is not supported.

Once again, I appreciate the quick response. R

IEC CIM = International Electrotechnical Commission Common Information Model