Since the entities and caching are being generalized to allow others to use git-bug as a library for storing data in git, is the GPL3 license too restrictive? Will needing to release derivative products under the same GPL3 license dissuade people from adopting git-bug as a library? Can we build a bigger eco-system with a less restrictive license?

Possibly ... I don't have strong opinion on the license. However, as far as I understand, changing the license for some packages would require approval of all authors, as well as making sure that only compatible licenses are used for the dependency. This is no small task ... Just listing dependencies and authors is a pain apparently.

To change the license of git-bug, we would indeed need to track down the authors of code in git-bug's packages but at least we wouldn't have to track down the authors of the dependencies!

Perhaps the sane thing to do is to close this issue and wait for someone to complain (although we'll never know if someone is considering git-bug as a library and rejects it due to the license). It's not an issue for git-bug as an application because there are no dependencies with licenses that are MORE restrictive.

Another problem with MIT for the core and keep GPL for the outer layers (entities, CLI, bridges ..) is that code routinely move from one to another (ex: prototyping in entities then generalizing in the core). Things get blurry fast, even if I'm the author of the vast majority of the core.

Agreed - if you look at the file headers for each source file in the Linux repository, you'll see that there are one to many copyright holders listed - that seems like too much of an administrative burden (e.g. https://github.com/torvalds/linux/blob/master/fs/binfmt_flat.c.)

We could do something similar as what Protocol Labs did: https://github.com/ipfs/kubo/issues/6302

• collect past contributor's approval
• switch and hope for the best (?)

Since the ability to use git-bug as "a database" is new with the recent refactorings, it's hard to identify a community of those that would benefit from a different license (or perceive the existing license as being too restrictive). I guess polling the current committers for their opinions would be a place to start? But ...

switch and hope for the best (?)

As you noted above, this represents quite a bit of work and since there are currently no CLAs in place, what's allowed is somewhat undefined (beyond continuing the project without changes.) How do we get feedback on this? And if nobody cares about the derivative works clauses, the original point is moot!

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 11 months ago

github-actions (github-actions) removed label lifecycle/stale 11 months ago

sudoforge removed label lifecycle/dormant 7 months ago