Add OSI-approved license to OMJulia top level folder

[AnHeuermann]

Currently JuliaRegistries/General#58444 fails, because of the missing license file, so we can't update our OMJulia version in the Julia general regestry.

OMJulia source files are using the OSMC-PL license, see e.g. https://github.com/OpenModelica/OMJulia.jl/blob/master/src/OMJulia.jl#L1-L27.

Our OSMC-PL license is problematic for adding OMJulia to the general registry since it is not part of the OSI-approved license.

Is there any reason to not just use a license that is OSI-aproved and allowes other to change OMJulia.jl? E.g. MIT license.
This package is only a API for OpenModelica and OpenModelica is not shipped with it.
So all generated code by omc is still under OSMC-PL license.

Or we use GPL-3.0, but then nobody is allowed to change OMJulia.

[AnHeuermann]

@casella Maybe we should discuss this is the next developer meeting, or does the OSMC board need to decide this?

[casella]

Or we use GPL-3.0, but then nobody is allowed to change OMJulia.

To the contrary, anybody can do that, provided they make the changed code publicly available if they release it. I don't see any problem with that. @AnHeuermann please remind me this issue during the next webmeeting.

[AnHeuermann]

Adding @adrpo to the loop. We should use the same license here as for the other OpenModelica Julia packages.

[bilderbuchi]

So all generated code by omc is still under OSMC-PL license.

Isn't code generated by omc under the OSMC-PL runtime license (so, OSMC-PL or GPL-3 or BSD-3), isn't that what that license is for?

We should use the same license here as for the other OpenModelica Julia packages.

At least MetaModelica.jl and DoubleEnded.jl (and the OMJulia file linked above) seem to use an old version of the RT license, with a missing mention of BSD-3.
BSD New/BSD-3 might be a more natural OSI-compatible fit than MIT (as this is also an option in the RT license)?

[casella]

The OSMC-PL license is meant for the source code of the tool, not for the generated source code of user's models. That is to prevent non OSMC-members to change the code of OpenModelica for their purposes, make it closed-source and sell without any benefit for the OSMC.

There is no reason to use the OSMC-PL license for the generated code of user's models. User's models are the property of the user and we should have no business with that, no string attached. Commercial tools do it, forcing third parties that want to run your compiled model to also have a license. That has never been our intention. So, we use the OSMC-PL runtime license, that also includes BSD-3, which basically allows you do do anything you want with the code, except claiming you wrote it.

[bilderbuchi]

The OSMC-PL license is meant for the source code of the tool, not for the generated source code of user's models. That is to prevent non OSMC-members to change the code of OpenModelica for their purposes, make it closed-source and sell without any benefit for the OSMC.

There is no reason to use the OSMC-PL license for the generated code of user's models. User's models are the property of the user and we should have no business with that, no string attached. Commercial tools do it, forcing third parties that want to run your compiled model to also have a license. That has never been our intention. So, we use the OSMC-PL runtime license, that also includes BSD-3, which basically allows you do do anything you want with the code, except claiming you wrote it.

Thank you for the clarification, this matches my understanding, as well.

[bilderbuchi]

That is to prevent non OSMC-members to change the code of OpenModelica for their purposes, make it closed-source and sell without any benefit for the OSMC.

The case of changing OM code is very clear, but what about preventing using OM unchanged in such a way? Possibly that is what is surfaced in discussions in components wrapping/driving OM, like here or in OpenModelica/OMPython#153.

For example, let us consider that OMJulia or OMPython (or other ancillary/driver packages) are used unchanged/imported by some entity in some software S that e.g. automates model execution/runs tests/does machine learning on models/whatever currently hip topic.
I found https://github.com/THM-MoTE/ModelicaScriptingTools.jl which seems to fit that example.

The end user would install OM separately (under OSMC-PL | GPL3) to obtain omc and run it.

The first question to resolve is if the use of omc when communicating via sockets/pipes (like OMJulia/OMPython do) consists of aggregation. It seems to me (IANAL) this should be an aggregate, and as such the whole is not a "combined program", and as such omc's GPL option should not apply to the software S.

Assuming that is correct, then the license of OMJulia or OMPython itself becomes relevant.
As one typically uses/imports those in whatever other software S, I think it's a given that S will form a combined work with the wrapper package.

Option A) If OMJulia/OMPython are licensed under OSMC-PL/GPL-3, this means software S will also need to be under OSMC-PL/GPL-3.
Non-OSMC members (e.g. random folks from the Julia community) will have to distribute their package using OMJulia under OSMC-PL or GPL-3.

Option B) If OMJulia/OMPython are licensed under OSMC-PL-RT/GPL-3/BSD-3, this is more permissive and would allow licensing S under OSMC-PL/GPL-3/BSD-3.
Then, non-OSMC members would AFAICT be allowed to distribute a software S under OSMC-PL-RT/GPL-3, but also BSD/closed, and use OM/omc unmodified (if the end user installs it separately).

The question is if the OSMC intends to enable use according to option A) or option B).
I think the answer then decides if the license for wrapper/driver/ancillary/aggregated software in the OM ecosystem shall be OSMC-PL or OSMC-PL-RT, and those can be harmonised/updated accordingly.

[casella]

The first question to resolve is if the use of omc when communicating via sockets/pipes (like OMJulia/OMPython do) consists of aggregation. It seems to me (IANAL) this should be an aggregate, and as such the whole is not a "combined program", and as such omc's GPL option should not apply to the software S.

IANAL either, but the text of GPL v3 seems very clear to me

This License explicitly affirms your unlimited permission to run the unmodified Program.

Whether the input/output to/from the program comes through a file, or a socket, or a floo network port, should be irrelevant. For example, GNU is released under GPL. If you run grep "somestring" input.txt | myprogram that doesn't require you to release myprogram as GPL if you want to convey it to others.

Assuming that is correct, then the license of OMJulia or OMPython itself becomes relevant. As one typically uses/imports those in whatever other software S, I think it's a given that S will form a combined work with the wrapper package.

Makes sense.

Option A) If OMJulia/OMPython are licensed under OSMC-PL/GPL-3, this means software S will also need to be under OSMC-PL/GPL-3. Non-OSMC members (e.g. random folks from the Julia community) will have to distribute their package using OMJulia under GPL-3.

Option B) If OMJulia/OMPython are licensed under OSMC-PL-RT/GPL-3/BSD-3, this is more permissive and would allow licensing S under OSMC-PL/GPL-3/BSD-3. Then, non-OSMC members would be allowed to distribute a BSD-licensed or proprietary software S that uses OM/omc unmodified (if the end user installs it separately).

That's clear.

The question is if the OSMC intends to enable use according to option A) or option B). I think the answer then decides if the license for wrapper/driver/ancillary/aggregated software in the OM ecosystem shall be OSMC-PL or OSMC-PL-RT, and those can be harmonised/updated accordingly.

I think we should discuss this with the Board. As far as I am concerned, OMJulia and OMPython are just thin wrappers around omc, to ease the communication with it, so I would use the OSMC-PL runtime license for them. Unless we consider using OMJulia and OMPython as a "premium option" that requires OSMC membership to use them with non-GPL v3 software. That doesn't make much sense to me, personally, but it's not up to me to decide.

[bilderbuchi]

The first question to resolve is if the use of omc when communicating via sockets/pipes (like OMJulia/OMPython do) consists of aggregation. It seems to me (IANAL) this should be an aggregate, and as such the whole is not a "combined program", and as such omc's GPL option should not apply to the software S.

IANAL either, but the text of GPL v3 seems very clear to me

This License explicitly affirms your unlimited permission to run the unmodified Program.

IIUC, the question of aggregation-or-not is primarily relevant for terms of distributing combined works , not use/running the program.

It's not without reason that in the FAQs for the GPL, there are several items concerning the question if a dependency's GPL applies to the main work.

The question is if the OSMC intends to enable use according to option A) or option B). I think the answer then decides if the license for wrapper/driver/ancillary/aggregated software in the OM ecosystem shall be OSMC-PL or OSMC-PL-RT, and those can be harmonised/updated accordingly.

I think we should discuss this with the Board. As far as I am concerned, OMJulia and OMPython are just thin wrappers around omc, to ease the communication with it, so I would use the OSMC-PL runtime license for them. Unless we consider using OMJulia and OMPython as a "premium option" that requires OSMC membership to use them with non-GPL v3 software. That doesn't make much sense to me, personally, but it's not up to me to decide.

Sounds reasonable! There's probably a number of packages/tool in the org that should be reviewed concerning this question.

[bilderbuchi]

On the topic of registering the package, it seems that dual-licensing packages is not a problem.
As the OSMC license (RT or not) is effectively a dual license, it seems to me that it can be clarified in the PR that an OSI-approved license (GPL-3 or GPL-3/BSD-3) is available to users who need that?

An issue might be that they seem to expect that you change the LICENSE file to the OSI-approved license and include a note concerning the dual licensing, but that can maybe be clarified in a discussion with humans (not the automated machinery), or a request to enable the process to deal with multiple-license situations gracefully.

[bilderbuchi]

The question is if the OSMC intends to enable use according to option A) or option B). I think the answer then decides if the license for wrapper/driver/ancillary/aggregated software in the OM ecosystem shall be OSMC-PL or OSMC-PL-RT, and those can be harmonised/updated accordingly.

I think we should discuss this with the Board. As far as I am concerned, OMJulia and OMPython are just thin wrappers around omc, to ease the communication with it, so I would use the OSMC-PL runtime license for them. Unless we consider using OMJulia and OMPython as a "premium option" that requires OSMC membership to use them with non-GPL v3 software. That doesn't make much sense to me, personally, but it's not up to me to decide.

@casella, as you have closed this, can you report on the outcome of this discussion with the board (if you had it)?
In this issue, you said that you (personally) would use the OSMC-PL runtime license.

In #70, you merged a license file that states in the first line that it uses the OSMC-PL version 1.2, immediately followed by something that looks like the OSMC-PL-RT header (notice the presence of the BSD license), not quite identical to either https://openmodelica.org/osmc-pl/osmc-pl-1.2-runtime.txt or https://openmodelica.org/osmc-pl/osmc-pl-1.2-header.txt. This is then followed by what I presume is the rest of the OSMC-PL.

I'm confused -- has your intent changed to license this (and I guess similar tools surrounding the OM ecosystem) from OSMC-PL-RT to OSMC-PL? If so, can you say what caused the change of mind from your previous assessment (quoted above, that I agree with!), and why is the BSD mentioned in the license file from https://github.com/OpenModelica/OMJulia.jl/pull/70/files? Should that be cleaned up/made consistent?

Combining Julia and OM sounds exciting! :-) I'm not trying to be annoying here, it just would be good for the terms of use to be clear/not apparently contradictory. 😃

[casella]

Gosh, I wish somebody else could take care of these issues 😅

[casella]

@bilderbuchi thanks for pointing this out. I missed the fact that the PR included OSMC-PL, not OSMC-PL-RT. I'll have to undo that.

[casella]

In fact, OMJulia.jl already includes that information. I'll just report it to the LICENSE.md file

[casella]

OK, this was in fact easier than I thought.

• The source code files already have the correct runtime license info (i.e. one can pick between BSD 3-clause, GPL v3, and OSMC-PL)
• I reported this information in the README.md file
• I also added a LICENSE.md file, reporting the most permissive of the three licenses (i.e. BSD 3-clause) so it is automatically recognized by license-aware bots.

@DilumAluthge, I hope this is fine for you.

[casella]

And, thanks to @bilderbuchi for watching over my shoulders 😅

[bilderbuchi]

Sure, no problem!

Gosh, I wish somebody else could take care of these issues 😅

I seem to be attracting the attention of license-related issues (OpenModelica/OpenModelica#7612) 😅

If you want, I can try to collect information on the license status (at least the readme/license files, checking all sources will be quite the effort) for the most relevant/active repos in the OM org in one place, e.g. an issue in the OM tracker.
I'd need clear guidance (or at least subsequent feedback) on what the respective licenses should be. 😀 For example, I think I can take away from this discussion that "scripting"/wrapper packages should generally be under OSMC-PL-RT 1.2, all others under OSMC-PL 1.2.

[casella]

If you want, I can try to collect information on the license status (at least the readme/license files, checking all sources will be quite the effort) for the most relevant/active repos in the OM org in one place, e.g. an issue in the OM tracker.

That would be very useful indeed.

I'd need clear guidance (or at least subsequent feedback) on what the respective licenses should be.

Sure. This also requires some time and effort, but it's much less once the relevant information has been properly processed.

😀 For example, I think I can take away from this discussion that "scripting"/wrapper packages should generally be under OSMC-PL-RT 1.2, all others under OSMC-PL 1.2.

Absolutely. BTW, I guess we haven't formally defined "OSMC-PL_RT", which basically means OSMC-PL or BSD 3-clause or GPL v3. Or is this stated in some official online document?

BTW, we are now changing GPL v3 to GPL Affero (to cover software-as-a-service usage of OMC), so I guess that will need a further round of license info harmonization.

[bilderbuchi]

Absolutely. BTW, I guess we haven't formally defined "OSMC-PL_RT", which basically means OSMC-PL or BSD 3-clause or GPL v3. Or is this stated in some official online document?

I agree, I couldn't find this identifier defined, either. It might be good to introduce this at some point, including versioning (in lockstep with OSMC-PL versions, probably). In the style of SPDX identifiers, I'd avoid the underscore and use OSMC-PL-RT, though.
Possibly include the version in the identifier, so OSMC-PL-1.2 and OSMC-PL-RT-1.2. I'll use that format informally, for now, for conciseness/clarity/precision.

[bilderbuchi]

Also, you might have a case to get the OSMC-PL added to the SPDX license list, which would enable using and SPDX ID like OSMC-PL-1.2 in project metadata, get picked up by Github license display (and other package managers like probably Julia's), etc.
There's a list of criteria, and based on the source-available nature, the GPL option/mode, and already established use it seems it could go in.

The RT version can (and probably should) be codified/composed with a "license expression" like OSMC-PL-1.2 OR GPL-3.0-only OR BSD-3-Clause (or added as a separate one, not sure).

[bilderbuchi]

BTW, we are now changing GPL v3 to GPL Affero (to cover software-as-a-service usage of OMC), so I guess that will need a further round of license info harmonization.

Ah, interesting. You probably realize that that will make adoption (in companies) more difficult? For example, in this template company policy for OSS use, OM would drop from the "Caution (internal use ok without legal approval)" category to the "Stop (legal approval needed for any use)" category. I assume that is intentional?
Did you already have problems with companies selling OM through a web interface?

[bilderbuchi]

If you want, I can try to collect information on the license status (at least the readme/license files, checking all sources will be quite the effort) for the most relevant/active repos in the OM org in one place, e.g. an issue in the OM tracker.

That would be very useful indeed.

@casella, see OpenModelica/OpenModelica#10129