hylo: Please consider adding a linking exception to the licence
According to the LICENSE file, Hylo uses a bare Apache 2.0 licence, without a linking exception.
This means that if the parts of Hylo somehow end up in the binaries it produces, users may have to comply with sections 4(a), 4(b) and 4(d) of the license. This means they would have to search Hylo’s source for any copyright notices and reproduce them in the documentation of their software.
That’s not ideal, which is why many compilers have a linking exception in their licences (unfortunately, not all of them).
Swift includes this in its license:
## Runtime Library Exception to the Apache 2.0 License: ##
As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result,
you may redistribute such product without providing attribution as would
otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.
LLVM uses a slightly different wording:
As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
GCC also does this, but it’s a GPL project, so its waiver isn’t applicable here.
As far as I can tell, Hylo doesn’t have a CLA, so such a change would require the consent of the contributors. If GitHub’s stats can be trusted, it seems that there are just 16 of them, so it should be doable.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 24 (16 by maintainers)
Commits related to this issue
- Add a linking exception to the license Add the linking exception discussed in #890, which is the same as the one used in Swift. — committed to hylo-lang/hylo by kyouko-taiga 10 months ago
The exception requested here was pointed out to us by Chris Lattner when we spoke with him about licensing, and we never did anything about it. I think it’s a good idea.
As for changing licenses completely, it’s a complicated calculation. The Boost license is more appropriate than Apache 2.0 without the exception, but there are other issues to consider. Unfortunately the Boost license (which I helped develop) hasn’t seen a lot of uptake in the industry, which means it will more often require a company to do a license evaluation than if we were using a more common license, so it raises the barrier to entry. For the record, I don’t have a strong position on which license(s) we should use.
For what it’s worth, I don’t have a strong position on which license(s) we should use, and I’m not at all worried about anyone claiming Hylo is their product.