Add License

[flash-me]

Add License

[dant2021]

Thank you, Josh, the resources you shared were very useful.

FYI We have licensed the code under MPL-2.

[flash-me]

@dant2021

Maybe you can gather some insights / ideas here:

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
• https://choosealicense.com/

Because right now, without license information, people are at risk even by just cloning the repository.
And if there contributions from others, you risk even yourself.
(See https://choosealicense.com/no-permission/)

cheers
flash ⚡

[dant2021]

Hi,
This is a big and important question, as it is very difficult to change license once one is chosen.
To be honest, we are unsure. We're not lawyers and want to ponder the question a little longer.
We are considering dual licenses with Apache or GLP but dislike that every user will not be able to benefit from the full value and that it opens the door to harmful free riding.
We're also looking into BSL 1.1 or FSL which allow us to charge for the software while releasing it to the public domain on a determined schedule.
Inkdrop Licensing.pdf
Happy to talk about it 1:1 as well.

[josh-padnick]

In my opinion, you choose a software license to support a specific business strategy, so it's the business strategy that needs clarification first. Of course, getting that right takes a few iterations, so it's hard to just "come up with one."

My take on the business strategy is that Inkdrop in its current form feels more like a feature (for CI tools) than a full-blown product. In many ways, it's analogous to Infracost, which offers their main tool on an Apache v2 license, and then offers a bunch of paid features that extend the original tool that users install.

As more of a feature for now, I think the goal is just to get users to adopt it. But, you need to somehow leverage the fact that they installed it to support upgrading to a paid product. Maybe for now, the goal is to just get a bunch of users to install it, and then interview those users to see what problems they're trying to solve so you can figure out what kind of backend platform you can build to support it.

Given that, my vote is you choose a permissive open source license like Apache v2 or MPLv2.

[dant2021]

I agree that we feel like a feature and that we should focus on adoption.

We're tending towards licensing the tool under MPLv2 and creating a paid solution to manage for example multiple plans/repositories. But we're not sure why the paid solution wouldn't be copied and built by anyone else.

Antoine

[josh-padnick]

But we're not sure why the paid solution wouldn't be copied and built by anyone else.

Well, you've got a few options here:

1. You can share the paid portion under a different license. See how GitLab has done this.
2. You can make the paid solution proprietary and simply not share the code.
3. You can make the paid solution completely open source, and then the only value-add you're offering is hosting and support.

My guess is that (2) is the right fit here, but...you don't have to decide until you actually create something that you want to think differently about.

FWIW, I found https://www.youtube.com/watch?v=G6ZupYzr_Zg super helpful.