I'd like to incorporate some form of license checking when you install a package from a URL, to prevent the situation where you build a big project and then later realize you've been accidentally relying on some code you didn't have legal permission to use
Many licenses are templatized, e.g. part of the LICENSE file is supposed to state the copyright holder(s).
Ideally I'd rather not have this rely on fetching something over the network (e.g. having to go fetch https://roc-lang.org/currently-known-licenses) because I'd like to minimize the number of scenarios where the CLI stops working properly because a piece of Roc infrastructure is down.
That said, I also don't want to increase the binary size a ton. (e.g. I don't want to copy every https://spdx.org/licenses/ file into the binary)
It should also be possible for people to use licenses that aren't officially known/supported, because that's necessary in order for new (and better) licenses to get adoption
we take the currently most popular licenses (there's a pretty sharp dropoff point I'd imagine) and hardcode them into the binary—knowing how their templates work, and how they relate to each others in terms of which ones are compatible with which others
we add UPL because that's the one we use
we don't support dual licensing for now (maybe it won't take off in the Roc ecosystem if it's unsupported...and trying to find a single license with all the legal benefits of MIT and Apache2 combined is what led to discovering UPL in the first place!)
when we install a package from a URL, we check for a LICENSE file. If it isn't there, we give a warning saying you don't appear to have been given permission to use it, but maybe it specifies otherwise in a comment or something. If it is there, we check for compatibility with all the other known licenses you're using from other URLs, plus (if you have one) the LICENSE file that's in the same directory as your root module.
if we encounter a LICENSE we don't recognize, we give a prompt asking you if you'd like to review it and either accept or reject it. If you accept it, we can add it to a list of exemptions in your home directory. (Possibly we could also do things like infer that it's GPL compatible if you're using a GPL-licensed package already when you approved it, and if not, the first time you try to install a GPL package alongside this custom one that you'd exempted previously, we ask you to confirm whether it's GPL-compatible.)
when you run roc build --bundle we give a warning if there's no LICENSE file, saying people will get a warning when they install your package that they may not have the right to use it bc it doesn't specify a license. Similarly, if you specify a LICENSE we don't recognize, we tell you that. (Neither of these is blocking; they're just FYIs we print out before compressing the bundle so you can read them while waiting for brotli)
if you're using packages with popular licenses (or UPL), you shouldn't even know this feature exists (regardless of roc-lang.org uptime) unless you do accidentally try to use incompatible licenses
if you want to use proprietary packages, or ones with custom licenses, you'll get a prompt, but you can record an exemption (e.g. in a sibling directory of the root module, so you can check it into source control and other collaborators on the project don't have to see the prompt)
we give warnings when bundling something up for distribution if LICENSE is missing or unknown, to make it harder to accidentally forget
and how they relate to each others in terms of which ones are compatible with which others
I don't think we should do policing. I think we likely should just enable listing what license a project depends on and the tree of how each license is pulled in.
The reasons I say we shouldn't do any sort of policing are:
Users might have explicit permission to use something from the copyright holder, so the license doesn't apply to them
Compatibility is debated and not clear cut.
This is all legal stuff, which means that we have not way to truly know something until it is tested in court (for example, the classic question of what exactly is a derivative work). Also, the license may have more or less meaning depending on the country, so our rules may be incorrect.
How do we police that a license is presented to the end user and thus being used correctly? If you pull some licenses you have to do stuff to use it, not just license your own code in a certain way.
If we miss something and that leads to someone violating a license because we said it was ok, we probably could technically get sued (though that is probably exceptionally unlikely).
Yeah i would be for a message that pops up when you pull in a new dependency (add per project cache somewhere).
Says some like "dependency x has y license, please ensure you are following the requirements of the license, more details here <link>. Do you still want to pull in x as dependency?" Also, maybe print the path of how the dep got added.
I would also be ok with skipping this message for some of the very permissive licenses (apache, MIT, etc).
Richard Feldman (Jun 22 2023 at 20:26):