docs: dual-licensing the client #9
Conversation
While we are debating licensing of the rest of the project, the client should be dual-licensed like most of other IPFS projects, to ensure ease of adoption.
client/LICENSE
Outdated
| @@ -0,0 +1,4 @@ | |||
| The client module is dual licensed under MIT and Apache-2.0. | |||
There was a problem hiding this comment.
No strong feelings on how we lay this out. Should we be using this though https://github.com/ipfs/ipfs-repository-template/blob/main/LICENSE.md?
There was a problem hiding this comment.
If not should we update the template?
There was a problem hiding this comment.
Good question.
I copied this from what is widely used in JS ecosystem (example: js-libp2p/auto-tls, it is the same for every other package there). cc @achingbrain for visibility in case there is a reason for using separate files.
My understanding is that automatons prefer licenses to be specified via explicit SPDX-License-Identifier hint, or be placed in separate files following convention LICENSE-FOO.md introduced by github in 2022.
Sadly, file detection only works if text file matches license, and one in JS land does not match reference APACHE by gthub:
Don't want to sink any more time on this, I've switched to SPDX-License-Identifier way in this PR, which is more deterministic.
There was a problem hiding this comment.
I've posted some follow up here instead of doing on this closed PR.
lidel
force-pushed
the
docs/client-license
branch
from
90588e4
to
31e40bc
Compare
|
Merging as we have sign-off from all contributors. |
While we are debating licensing of the rest of the project, the client should be dual-licensed like most of other IPFS projects, to ensure ease of adoption.
Need sign-off from people who contributed to the
client/module: