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.
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.
> 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:
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.
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.