Do Gitea static builds include glibc? If so, are there any LGPL requirements that you had to follow? #6089

New Issue

GiteaMirror · 2025-11-02T06:44:51-06:00

GiteaMirror commented

2025-11-02 06:44:51 -06:00

Originally created by @atc0005 on GitHub (Oct 4, 2020).

First of all, many thanks for Gitea. It's a great application and has come in handy many times.

Regarding the static binaries that you provide, is the GNU C library compiled in? If so, do you have to comply with GNU LGPL requirements to note use of or inclusion of the GNU C library in those builds?

I've opted to begin releasing binaries for some small Go projects that I maintain. After a bunch of reading the last few days, I'm still puzzled; I'm finding some sources that indicate that you do have to include the LGPL license and prominent notices (including application output), whereas other sources seem to note that you don't. I hadn't even considered that the glibc license could be a factor (ignorance on my part).

Does the Gitea project generate static builds in some way that doesn't require LGPL considerations?

I've looked over the Makefile and attempted to answer this myself by looking at the xgo build script and Gitea Makefile, but the answer is still not clear.

Thanks in advance for your feedback.

Originally created by @atc0005 on GitHub (Oct 4, 2020). First of all, many thanks for Gitea. It's a great application and has come in handy many times. Regarding the static binaries that you provide, is the GNU C library compiled in? If so, do you have to comply with GNU LGPL requirements to note use of or inclusion of the GNU C library in those builds? I've opted to begin releasing binaries for some small Go projects that I maintain. After a bunch of reading the last few days, I'm still puzzled; I'm finding some sources that indicate that you *do* have to include the LGPL license and prominent notices (including application output), whereas other sources seem to note that you don't. I hadn't even considered that the glibc license could be a factor (ignorance on my part). Does the Gitea project generate static builds in some way that doesn't require LGPL considerations? I've looked over the Makefile and attempted to answer this myself by looking at the [xgo build script](https://github.com/techknowlogick/xgo/blob/e5dde9330cb083455cee3b6768071b2479f7f8b0/docker/base/build.sh#L185-L193) and [Gitea Makefile](https://github.com/go-gitea/gitea/blob/772b5e0f548548d5633b99fb40f59e5075f1c6db/Makefile#L572-L580), but the answer is still not clear. Thanks in advance for your feedback.

GiteaMirror added the type/question label 2025-11-02 06:44:51 -06:00

GiteaMirror closed this issue

2025-11-02 06:44:51 -06:00

GiteaMirror commented

2025-11-02 06:44:52 -06:00

@lafriks commented on GitHub (Oct 4, 2020):

As we use CGO to support sqlite Gitea does not have fully static binaries imho, libc not included in them. You can always compile in alpine to get fully static binaries and musl is licensed under MIT

@lafriks commented on GitHub (Oct 4, 2020): As we use CGO to support sqlite Gitea does not have fully static binaries imho, libc not included in them. You can always compile in alpine to get fully static binaries and musl is licensed under MIT

GiteaMirror commented

2025-11-02 06:44:52 -06:00

@atc0005 commented on GitHub (Oct 5, 2020):

@lafriks As we use CGO to support sqlite Gitea does not have fully static binaries imho, libc not included in them.

Thanks for the feedback. I checked with ldd and file and it seems like the binaries that this project provides are static, but I suspect that I may be doing something wrong.

Example output:

$ ldd gitea-1.12.5-linux-amd64
        not a dynamic executable

$ file gitea-1.12.5-linux-amd64
gitea-1.12.5-linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=a778211f8fbdcff5eee8acb8367da6b942490e75, not stripped

To be clear I'm not trying to imply you're wrong, I'm just sharing that I have run into some results that don't make a lot of sense (which of course you're not on the hook to explain).

You can always compile in alpine to get fully static binaries and musl is licensed under MIT

Thanks for the suggestion, I'll give that a try.

@atc0005 commented on GitHub (Oct 5, 2020): > @lafriks As we use CGO to support sqlite Gitea does not have fully static binaries imho, libc not included in them. Thanks for the feedback. I checked with `ldd` and `file` and it *seems* like the binaries that this project provides are static, but I suspect that I may be doing something wrong. Example output: ```ShellSession $ ldd gitea-1.12.5-linux-amd64 not a dynamic executable $ file gitea-1.12.5-linux-amd64 gitea-1.12.5-linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=a778211f8fbdcff5eee8acb8367da6b942490e75, not stripped ``` To be clear I'm not trying to imply you're wrong, I'm just sharing that I have run into some results that don't make a lot of sense (which of course you're not on the hook to explain). > You can always compile in alpine to get fully static binaries and musl is licensed under MIT Thanks for the suggestion, I'll give that a try.

GiteaMirror commented

2025-11-02 06:44:53 -06:00

@zeripath commented on GitHub (Oct 5, 2020):

Even if we do glibc statically compiled gitea we would still comply with the LGPL because we offer a link to the source code of gitea - this repository! - along with the preferred build scripts etc.

@zeripath commented on GitHub (Oct 5, 2020): Even if we do glibc statically compiled gitea we would still comply with the LGPL because we offer a link to the source code of gitea - this repository! - along with the preferred build scripts etc.

GiteaMirror commented

2025-11-02 06:44:53 -06:00

@atc0005 commented on GitHub (Oct 5, 2020):

@zeripath: Even if we do glibc statically compiled gitea we would still comply with the LGPL because we offer a link to the source code of gitea - this repository! - along with the preferred build scripts etc.

Thanks for the feedback. I asked on Slack earlier for some feedback and was pointed to https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic which notes:

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

As you say, it sounds like item one is covered.

It looks like glibc is using LGPL v2.1:

Does section 6 apply here?

As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

It sounds like this bit is already taken care of (as noted previously).

You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License.

Do you happen to know if this means that the license has to be included in the repo, mentioned in the README or something else?

You must supply a copy of this License.

This makes it sound like the LGPL license file must be added to the repo, or included alongside the binary provided for each release?

If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.

I didn't look hard, but I didn't see a copyright notice being emitted by the application.

Also, you must do one
of these things:

...

d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.

Does this mean that glibc has to be hosted from the repo? Presumably not?

@atc0005 commented on GitHub (Oct 5, 2020): > @zeripath: Even if we do glibc statically compiled gitea we would still comply with the LGPL because we offer a link to the source code of gitea - this repository! - along with the preferred build scripts etc. Thanks for the feedback. I asked on Slack earlier for some feedback and was pointed to https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic which notes: > Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic) > > For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3): > > (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. > > (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides. As you say, it sounds like item one is covered. It looks like glibc is using LGPL v2.1: - https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt - https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=COPYING.LIB;hb=HEAD Does section 6 apply here? > 6. As an exception to the Sections above, you may also combine or > link a "work that uses the Library" with the Library to produce a > work containing portions of the Library, and distribute that work > under terms of your choice, provided that the terms permit > modification of the work for the customer's own use and reverse > engineering for debugging such modifications. It sounds like this bit is already taken care of (as noted previously). > You must give prominent notice with each copy of the work that the > Library is used in it and that the Library and its use are covered by > this License. Do you happen to know if this means that the license has to be included in the repo, mentioned in the README or something else? > You must supply a copy of this License. This makes it sound like the LGPL license file must be added to the repo, or included alongside the binary provided for each release? > If the work > during execution displays copyright notices, you must include the > copyright notice for the Library among them, as well as a reference > directing the user to the copy of this License. I didn't look hard, but I didn't see a copyright notice being emitted by the application. > Also, you must do one > of these things: > > ... > > d) If distribution of the work is made by offering access to copy > from a designated place, offer equivalent access to copy the above > specified materials from the same place. Does this mean that glibc has to be hosted from the repo? Presumably not?

GiteaMirror referenced this issue

2025-11-02 06:55:22 -06:00

Bring back attachment preview/thumbnails #6424

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6089