3 ms·

IANAL, but it makes perfect legal sense to me just like it is perfectly legal to run an open-source app on a proprietary OS.

bee_rider 4y ago
I also ANAL, but is it really like running on a proprietary OS? It seems more like having a dependency on a non-free library. An open source program which requires, for example, DirectX is pretty severely hampered, right? Of course this one is a little bit more grey-area because it seems that it is easy to get free individual licenses for this code.
- hollerith 4y ago
  OK I admit that the analogy is not worthwhile on second thought. But if you have the legal right to run a proprietary OS the of course you can run open-source apps on it. Similarly if you acquire somehow the legal right to run Ultralight then you can legally run Muon.
  - bee_rider 4y ago
    > But if you have the legal right to run a proprietary OS the of course you can run open-source apps on it. Similarly if you acquire somehow the legal right to run Ultralight then you can legally run Muon. For sure, it is definitely legal. Sorry, I used "grey area" in my previous comment which is basically incorrect because "legal grey area" is a really common expression. I'm just thinking it is less useful. Like hypothetically in the absurd case you could release an open source project that is: #include "proprietary_library.h" int main() { run_proprietary_code(); } which is open source but who cares, right?
    - yazzku 4y ago
      I do care, and in your example, it depends on what license the project uses and how "proprietary_library" is distributed. In this specific case, if Muon distributed a copy of Ultralight (which it doesn't seem to; I'm not sure why I'm spending so much time on this), the it could not be GPL'ed, for example, because Ultralight has a proprietary (incompatible) license [2]. For a license like MIT or BSD, I think applying that license is technically valid, but again, not very practical. I doubt Muon would make it into the OpenBSD repos, for example. Its distribution is hindered by the depedency. Basically, "open source" doesn't really mean anything in this context; you need to consider specific licenses and circumstances. [1] https://github.com/ImVexed/muon/tree/master/ultralight https://github.com/ImVexed/muon/tree/master/ultralight [2] https://github.com/ultralight-ux/Ultralight/blob/master/license/LICENSE.txt https://github.com/ultralight-ux/Ultralight/blob/master/lice...
yazzku 4y ago
I don't think it's the same thing. That program may be cross-platform and not actually need the proprietary OS, for example. This, on the other hand, has a core dependency that is non-free.
jcelerier 4y ago
It's exactly like electron: the GH "electron" scripts are MIT but the dependency on Blink requires you to respect its LGPL license for apps you ship

bee_rider 4y ago

I also ANAL, but is it really like running on a proprietary OS? It seems more like having a dependency on a non-free library. An open source program which requires, for example, DirectX is pretty severely hampered, right? Of course this one is a little bit more grey-area because it seems that it is easy to get free individual licenses for this code.

hollerith 4y ago
OK I admit that the analogy is not worthwhile on second thought. But if you have the legal right to run a proprietary OS the of course you can run open-source apps on it. Similarly if you acquire somehow the legal right to run Ultralight then you can legally run Muon.
- bee_rider 4y ago
  > But if you have the legal right to run a proprietary OS the of course you can run open-source apps on it. Similarly if you acquire somehow the legal right to run Ultralight then you can legally run Muon. For sure, it is definitely legal. Sorry, I used "grey area" in my previous comment which is basically incorrect because "legal grey area" is a really common expression. I'm just thinking it is less useful. Like hypothetically in the absurd case you could release an open source project that is: #include "proprietary_library.h" int main() { run_proprietary_code(); } which is open source but who cares, right?
  - yazzku 4y ago
    I do care, and in your example, it depends on what license the project uses and how "proprietary_library" is distributed. In this specific case, if Muon distributed a copy of Ultralight (which it doesn't seem to; I'm not sure why I'm spending so much time on this), the it could not be GPL'ed, for example, because Ultralight has a proprietary (incompatible) license [2]. For a license like MIT or BSD, I think applying that license is technically valid, but again, not very practical. I doubt Muon would make it into the OpenBSD repos, for example. Its distribution is hindered by the depedency. Basically, "open source" doesn't really mean anything in this context; you need to consider specific licenses and circumstances. [1] https://github.com/ImVexed/muon/tree/master/ultralight https://github.com/ImVexed/muon/tree/master/ultralight [2] https://github.com/ultralight-ux/Ultralight/blob/master/license/LICENSE.txt https://github.com/ultralight-ux/Ultralight/blob/master/lice...

yazzku 4y ago

I don't think it's the same thing. That program may be cross-platform and not actually need the proprietary OS, for example. This, on the other hand, has a core dependency that is non-free.

jcelerier 4y ago

It's exactly like electron: the GH "electron" scripts are MIT but the dependency on Blink requires you to respect its LGPL license for apps you ship