foundry-rs
Confusing Licenses
When a user runs forge init, they get a bunch of files from this repository. Presumably, they may end up leaving a bunch of code from this repo in their repo, which means the license matters (especially for the testing code).
There are two licenses in the root, which do not seem like very compatible licenses with each other, both same copyright holder: https://github.com/foundry-rs/forge-std/blob/master/LICENSE-APACHE and https://github.com/foundry-rs/forge-std/blob/master/LICENSE-MIT
In addition to that, the testing contracts from dapp.tools are probably the most important parts for people to re-use. In fact, I guess they probably pretty much have to re-use them to be able to use many of Foundry's more advanced features. It does appear that in this repo, files do have individual licenses, for example: https://github.com/foundry-rs/forge-std/blob/master/src/Test.sol#L1
When I do run forge init, I also get some files that have UNLICENSED (do forge init in an empty directory, then git grep UNLICENSE). This gets even more confusing, because that's not one of the listed licenses in the created repo.
This may make it a bit more difficult for some people to use these testing tools on their projects, without the needed license clarity.
Previous issue (told to move it here): https://github.com/foundry-rs/foundry/issues/2311
Gm, @ehildenb,
When I do run forge init, I also get some files that have UNLICENSED
When you forge init, the templates are licensed as Unlicensed, a.k.a. "All rights reserved". I think it's the safest default choice, and the developer can add a license if they want.
[Forge Std] There are two licenses in the root, which do not seem like very compatible licenses with each other
Forge Std is dual-licensed under MIT/Apache 2.0. The developer can pick the one that works for them; we should have clarified this in the README, so you are right that it's confusing. There is no SPDX license identifier for the dual license, so MIT was specified in individual files in #116.
In addition to that, the testing contracts from dapp.tools are probably the most important parts for people to re-use.
I want to ping @gakonst about licensing once again and also propose some changes. I'm not a lawyer.
My idea was that we can relicense Forge Std as BSD+Patent. It's permissive and I think it's better then dual-licensing under MIT/Apache 2.0. A SPDX license identifier exists as well, so there will never be confusion.
About DS Test, it is GPL v3 licensed so it isn't compatible with these licenses, although that has never been a problem. I wanted to point this out anyway. Edit: Actually, I get this part.
Cc @paulrberg, as this is also related to PRBTest and #128.
Hi @ehildenb, as @ZeroEkkusu has said, using UNLICENSED is perfectly fine in Solidity, though I agree that it is confusing. UNLICENSED is not an actual SDPX identifier. This confusion has been discussed at length here and here.
My idea was that we can relicense Forge Std as BSD+Patent.
Sounds good, though I'm not a lawyer either, so I cannot comment on the advantages of using this besides being clearer for end users (just one license versus two).
In addition to that, the testing contracts from dapp.tools are probably the most important parts for people to re-use. In fact, I guess they probably pretty much have to re-use them to be able to use many of Foundry's more advanced features.
Well, not anymore. If my PR https://github.com/foundry-rs/forge-std/pull/126 gets merged in, you will not be locked in with DSTest anymore. For example, you could use Forge Std alongside my recently announced PRBTest, which is licensed under MIT.
Of course, if #128 is accepted, you wouldn't even have to install PRBTest manually - it would come out of the box with Forge Std. And that would mean no GPL-licensed software anymore.
I have a strong preference to keep MIT/Apache2 personally. BSD and gpl variants just cause pain and confusion for users. But in theory open to a convo around it. If we make a change from the current dual licensing, I would do public domain personally
Either way we should make it clear in the README
