New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FMUs must contain all relevant license information #417

Open
modelica-trac-importer opened this Issue Oct 17, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@modelica-trac-importer

modelica-trac-importer commented Oct 17, 2018

Reported by cbertsch on 16 May 2017 05:06 UTC
In many modeling and simulation tools, open source software (OSS) components are used and included in exported FMUs. When distributing OSS or a derived work, the correct licenses text must be passed.

Exchanging FMUs between companies or organizations is clearly a distribution.

The FMU may contain source code, where the distribution of OSS is obvious, and/or binaries, which are derived work (and where for some OSS licenses like BSD-2/3-clause special, “softer” license conditions apply. But even there

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

see https://opensource.org/licenses/BSD-3-Clause)

Any open source software used within an FMU (e.g. Sundials solvers for CS FMUs, Code generated from the Modelica Standard Library/C-Sources, any binary FMU using header files from the MAP FMI) needs to be added there as well.
Currently, it would up to the user, to provide license texts when passing FMUs. We suppose that this is currently not done in most cases, as it creates huge additional work as this information is sometimes hidden deeply in the exporting tool documentation. Sometimes it is impossible, as the end user does not know, which open source software is really included in a binary FMU.

Beyond OSS licenses, it is also necessary to include the (foften commercial) license of the tool vendor: what is allowed to do with an FMU and the source code it contains?

It seems, that many tool vendors are not aware of that issue!

However it is crucial for industrial users, when providing those FMUs to customers. Since normally they do not have source code of the FMUs, they depend on the tool vendors to provide files that comply with legal requirements.

Thus we propose to make it mandatory in FMI 2.0.1 for FMUs, to contain complete licenses and copyright information (especially but not only for OSS SW) in the documentation folder of the FMU – either in the index.html file or in an opensourcelicenses.txt file.

For tool vendors, this should be quite easy to automate, while for end users it creates a large overhead.

An FMU without correct and complete OSS license information shall be considered invalid. The FMU compliance checker should give an error for MUs without the words “license” in the index.html file or without a file opensourcelicenses.txt.


Migrated-From: https://trac.fmi-standard.org/ticket/417

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by beutlich on 23 May 2017 06:53 UTC
We were discussing this topic at the 94th Modelica Design Meeting in Praha. Since a single file opensourcelicenses.txt would require tool vendors to figure out which portions of the OSS are actually utilized within the generated FMU, I rather propose to include a single lincense file per OSS project used. E.g., we might have Copyright_SUNDIALS.txt, Copyright_CLAPACK.txt and originating from the (optional) MSL C-Sources: Copyright_ModelicaExternalC.txt, Copyright_ModelicaStandardTables.txt, Copyright_matio.txt, Copyright_zlib.txt, Copyright_uthash.txt, Copyright_DIRLIB.txt, Copyright_xorshift.txt, Copyright_KISSFFT.txt, Copyright_HDF5.txt.
Those MSL-related files will likely be provided by the next MSL (once the license change is performed), which turns this issue also to a library issue. How can Modelica tools decide, given a Modelica library, which license files need to be included in the FMU? This actually requires something like a new annotation for the Modelica external function interface.

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by cbertsch on 24 May 2017 15:40 UTC
I would prefer "license_SUNDIALS.txt" to "Copyright_SUNDIALS.txt".

Should we have a "licenses" subfolde of the documentation folder?

For reference here is the link to the related ticket for Open Source licenses within the MSL: modelica/ModelicaStandardLibrary#2253

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by apillekeit on 8 Jun 2017 11:18 UTC
I agree that this is an important topic to be discussed.

Without having spent too much time on this ticket yet, I would still like to add some points to the discussion:

  1. Is it already clear and checked by a legal expert that it would be OK (from a legal point of view) to put (hide) the license/copyright information within the FMU? Since most users will never manually open an FMU and many tools do not provide means to display the folder contents of an FMU. The FMU could therefore be seen as "the binary object" that is distributed and the copyright information may (have to!?) be sent as a separate file next to the FMU.

  2. Not only Modelica based tools also other modelling tools provide the possibility to include external C-code or libraries in models (most prominent are probably s-functions) that can be exported as FMUs. To my knowledge most tools do not provide an automatic information mechanism for including/connecting license/copyright information for such external libraries. Sometimes also libraries in compiler distributions may require additional handling depending on used API functions in models (e.g. winpthreads support in mingw). Different compiler variants have therefore potentially additional different license/copyright requirements. All in all: In my view it seems to be also hard for exporting tools to collect a complete set of required information automatically for each FMU. A standard for automatically detecting license/copyright information in used 3rd-party components might be helpful to create a "complete" legally correct license/copyright information, when exporting FMUs. Is something like this available?

  3. In this case it is probably forward compatible to 2.0 but is it also backward compatible to require a new mandatory file in the FMU for 2.0.1?

  4. The ProSTEP SSE Recommendation for Smart Systems Engineering (see Annex A2 of PSI 11 at http://www.prostep.org/en/medialibrary/publications/) already provides a workflow recommendation for exchanging license/copyright information, when exchanging models. It requires a separate document with this information included. This could be a short term solution or first approach to this topic. Of course I understand that the “real” open point is how to derive/collect the required information. This task seems to be a complex one that may require extended discussions.

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Modified by apillekeit on 8 Jun 2017 11:36 UTC

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by andreas.hofmann7 on 7 Jul 2017 09:08 UTC
About the first point of apillekeit I got some information from Bosch Rexroth open source and legal department:

They told me that in general it should be not enough to put the open source license information into the FMU itself.
As you said before, not to many users of FMUs extract the data on their own and know the content of an FMU file. Furthermore, some open source licenses may not to be compatible with the binary form of the FMU, meaning that their licenses might require to easily read the license text without further steps (although I do not have an example for that at the moment). However, this always depends on individual used open source software.

We are planning, although nothing is fixed yet, to provide the license texts as an additional file and also put it into the FMU itself.

Best regards,
Andreas

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by sjoelund.se on 7 Jul 2017 09:22 UTC
But most open source projects are released as tarballs and there are plenty of tools that automatically compile them without the user ever examining which files were contained in the tarball... The main problem you would face is not that you do not provide the license files: it is that if you only provide binary files in the FMI and not as the GPL requires: the binary accompanied by the corresponding source code or a written offer to provide it. Then you would need to actually put a file where you describe how to request the source code of some of the files...

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by cbertsch on 9 Jul 2017 18:12 UTC
Providing in the license text inside the FMU in a standardized way is a necessary prerequisite for everything else.

In the case the license requires to ship the source code or to provide a written offer how to provide it, this should also be contained in the FMU.
When an FMUs is shipped or provided for download, one could add information like "an FMU is a zip-File and License text are conatained within the documentation folder of this zip-File" or extract the license file and provide it additionally.

However, today as an end user you have in most cases no chance to know, which open source software is contained in an FMU you get and which open source licenses you have to comply with. Thus it is absolutely necessary to make it mandatory to procide complete license information within the FMU.

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by andreas.junghanns on 9 Jul 2017 20:58 UTC
I agree that we should add a standard way of packaging license information.
Two options:

  1. Packed inside the FMU as text files named according to standard rules, inside directories according to standard rules (this would be easier in case more than the license text has to be shipped).
  2. Placed inside the XML, even with URLs pointing to the license texts.

Exporters are just as responsible today to pack those conditions into what they ship - we just standardize how to package it.

For importers, they can (must?) offer a way for users to inspect the used licenses.

In my opinion, this should be sufficient to allow all involved to behave according to license conditions. We cannot force them.

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by anonymous on 7 Dec 2017 10:26 UTC
New Dymola release 2018 FD01 now packs the following license files to the documentation folder of the FMU

ModelicaLicense2.html
LICENSE_CVODE.txt
LICENSE_f2c.txt
LICENSE_FMI.txt
LICENSE_HDF5.txt
LICENSE_LAPACK.txt
LICENSE_ModelicaFFT.txt
LICENSE_ModelicaInternal.txt
LICENSE_ModelicaIO.txt
LICENSE_ModelicaMatIO.txt
LICENSE_ModelicaRandom.txt
LICENSE_ModelicaStandardTables.txt
LICENSE_ModelicaStrings.txt
LICENSE_ModelicaUtilities.txt
LICENSE_SUNDIALS.txt
LICENSE_SuperLU_MT.txt
LICENSE_TPL.txt
LICENSE_uthash.txt
LICENSE_win32_dirent.txt
LICENSE_ZLIB.txt

This is kind of static information, as licenses for other involved Modelica libraries are missing and vice versa, not all licenses are actually required.

@modelica-trac-importer

This comment has been minimized.

modelica-trac-importer commented Oct 17, 2018

Comment by beutlich on 7 Dec 2017 11:19 UTC

This is kind of static information, as licenses for other involved Modelica libraries are missing and vice versa, not all licenses are actually required.

True. I also proposed a new annotation in comment:1 to better support the license documentation of the external code. I've just created https://trac.modelica.org/Modelica/ticket/2217 for the Modelica language (and will no longer hijack this issue). Given the library itself, that is ModelicaLicense2.html, we need to clarify how to specify it.

@beutlich beutlich changed the title from FMUs must contain all relevant licesense information to FMUs must contain all relevant license information Oct 23, 2018

@chrbertsch

This comment has been minimized.

Contributor

chrbertsch commented Oct 23, 2018

Discussion at FMI Design Meeting: we should also define, who may change this license information.
(The exporting tool might only know about part of the license information, but the user that exports the FMU might know about additional licenses (e.g. for used libraries)

@KarlWernersson

This comment has been minimized.

Collaborator

KarlWernersson commented Nov 13, 2018

I don't see how we can make this mandatory for 2.0.1 but to have recommended way to package the files would be good

@KarlWernersson KarlWernersson removed the 2.0.1 label Nov 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment