Please clarify licensing situation and clarify whether gitea is actually under a free license

[hannob]

The gitea repository says "License: MIT". Your webpage also states: "It is published under the MIT license."

However I don't think that is accurate. This has been brought up in a discussion at Gentoo, see gentoo/gentoo#12597

In the vendor subdirectory there is code from a large number of different projects under different licenses. There is code with MPL-2.0 and Apache-2.0 licenses, which are both not a subset of MIT.

Most concerning however is the license in https://github.com/go-gitea/gitea/blob/master/vendor/github.com/couchbase/goutils/LICENSE.md as this is clearly not a free software or open source license.

I think it is currelty very misleading to advertise gitea as MIT-licensed software.

[lafriks]

Project itself is licensed under MIT license, we can't really check every single dependency of dependencies. So it is not really a right statement that if project is using any dependency with other license than project itself is not free.

Concerning identified problematic cases:

• github.com/couchbase/goutils/LICENSE.md - dependency of dependency
• github.com/glycerine/go-unsnap-stream/LICENSE - dependency of dependency
• github.com/gogits/chardet/LICENSE - is ICU not free license? I can't really comment on this
• gopkg.in/yaml.v2/LICENSE.libyaml - APACHE-2.0 + MIT

[theAkito]

I agree with @lafriks and if a dependency author has truly a problem with integrating their code into Gitea (which would be insane, in most cases) they can send a message requesting removal of the dependency from the Gitea project. I don't see a problem in that.

[zeripath]

I think the couchbase atrocity needs looking at. It's fortunately non-infective as far as I can see. We could probably get away with making it build tag dependent but we could consider removing it from the codebase entirely - the license doesn't really induce me to make me give my free time to support them.

We probably need to make it clear that some parts of the codebase are MIT, some BSD, some Apache perhaps as part of a license collation section.

We should also look at which bits of Gitea are under Apache 2.0 and whether we can rewrite them or get them relicensed back to MIT. However these are all compatible non infective licenses.

[theAkito]

We should also look at which bits of Gitea are under Apache 2.0 and whether we can rewrite them or get them relicensed back to MIT.

Is this crucial? I thought they are interchangeable for the most part.

[zeripath]

@Akito13 it's just a bit messy really - I think we'd probably get away with saying "the majority of the code is under MIT with a few parts under Apache and BSD - please see the code for further information." However we can't just say that the code is licensed under MIT and gloss over them - Apache 2 does impose an obligation on downstream users that MIT does not.

I think we have been slightly cavalier with adding dependencies - that's always the case with feature expansion. We may want to consider paring back some of these, however that would likely involve reinventing the wheel.

[Jookia]

Could this be split at some point to 'remove proprietary dependencies' or 'allow building with only free dependencies' once a list is made?

[theAkito]

allow building with only free dependencies

Isn't this still triggering the event:

reinventing the wheel

?

[Jookia]

No, an option to disable features that depend on nonfree dependencies is acceptable.

[Jookia]

go-unsnap-stream is MIT since last year: glycerine/go-unsnap-stream@f967730
As for 13 hours, goutils is now Apache licensed: couchbase/goutils@b496390

[theAkito]

No, an option to disable features that depend on nonfree dependencies is acceptable.

I would find that kind of pointless. That is a really bad way to design software. This would create a much bigger development effort and risk of bugs, etc. just to make a second option that actually takes away value from the project, instead of adding value to it. Maybe if there would be a way to tone down features, that would be discussable.

I think the only way to make this idea work is if there was a second version of Gitea, like "LibreGitea", "GiteaLibre" or "Gitea L" (I guess you would need to replace Libre with Free, in case of using MIT as the primary target). This would merge everything from upstream, that is F(L)OSS into this version. Secondly, it would not be maintained by the Gitea head developers, as they already are more than enough busy with the actual Gitea.

[Jookia]

https://github.com/go-gitea/gitea/blob/master/vendor/github.com/gogits/chardet/icu-license.html this looks like the MIT license with an advertising clause. So everything looks free now, at least upstream.

[lunny]

I think #7849 will check the status when new codes merged.

[Jookia]

If anyone's interested I did a quick patch that removes couchbase in v1.9.4: https://github.com/Jookia/gitea/commit/6a3129cd529341395c71a9e6cfde132e2006e3c6 In the gitea code itself (ignoring Go dependency management): 5 files changed, 1 insertion(+), 16 deletions(-)
So that could be a useful tool for packagers until the goutils package is updated.

Edit: Posted in the Gentoo packaging issue

[lunny]

As for 13 hours, goutils is now Apache licensed: couchbase/goutils@b496390

@Jookia Why not just update couchbase/goutils since it has updated license?

[Jookia]

I don't have the time to learn the skills to do that at the moment, nor the expertise to debug it and test it since I don't use couchbase.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[theAkito]

So this issue is now definitely solved a 100%?

[techknowlogick]

@theAkito the couchbase dep is now updated to use the MIT licensed version, and Gitea remains published under MIT.