View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001350 | bareos-core | General | public | 2021-05-11 09:44 | 2022-01-13 15:42 |
Reporter | fcolista | Assigned To | bruno-at-bareos | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 20.0.1 | ||||
Summary | 0001350: AGPL-3.0 compliance | ||||
Description | Hello. I'm the maintainer of BareOS in Alpine Linux. We got an interesting request, related to AGPL-3.0: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12641 Alpine ships some patches for BareOS, as you can see here: https://git.alpinelinux.org/aports/tree/community/bareos?h=master There is any possibility that you can enable Alpine to be AGPL compliant? Thank you very much for considering. .: Francesco Colista | ||||
Tags | No tags attached. | ||||
Hello, thanks you for your report. I've checked the report and I don't understand too much, what is missing from us to be compliant ? All the source code is coming from https://github.com/bareos/bareos ? Except your patches, which unfortunately are not documented not licenced. The webui is based on Zend Framework 2 (also contained into the source tree) and each component has its copy of Zend Framework license (which is a BDS/MIT like) compatible AGPL3.0, if I'm not wrong. Could you be more explicit, about what are you expecting from us ? Thanks. btw: Your patch for libdroplet will fail soon once we will have merged https://github.com/bareos/bareos/pull/985 |
|
Adding also this link from our documentation https://docs.bareos.org/bareos-20/Appendix/BareosCopyrightTrademarkAndLicenses.html |
|
Any news here ? | |
Hi. Following up this request on https://gitlab.alpinelinux.org/alpine/aports/-/issues/12641 appears that would be useful if we can have upstream support in order to have a way to configure a message to be shown on web interface, in order to satisfy that part of license condition. I have a patch to alert the user via CLI, but if only the webif is used, the user should be alerted too. If you can provide this kind of support, that would be great. Otherwise, we need to find a way to patch the web interface with a message. Thanks for following up on this. .: Francesco |
|
Ok I've now a better view about your problem. I've no idea why you want to patch Bareos, but certainly have your own reason. In that case yes you need to act as downstream, and provide source and access to them to your end-users. To make this happen, you will have to prepare a PR and submit code that could be acceptable. |
|
You can include a remark at the bottom of the login screen Patch needs to be placed in the following view. https://github.com/bareos/bareos/blob/master/webui/module/Application/view/layout/login.phtml.in |
|
There's also use the CMAKE variables BAREOS_BINARY_INFO see core/src/lib/version.cc to adapt your own Alpine signatures so it make it clear from where the build come, and what are the Changes made. | |
To be even more precise here's developper explanation you need to set compile_definitions for target version-obj like this: target_compile_definitions(version-obj PRIVATE -DBAREOS_BINARY_INFO="my very personal Bareos build") target_compile_definitions(version-obj PRIVATE -DBAREOS_SERVICES_MESSAGE="This is my personal Bareos. Go build one for yourself!") target_compile_definitions(version-obj PRIVATE -DBAREOS_JOBLOG_MESSAGE="whaterver") In our build process, core/CMakeLists.txt 146-149 sets the CMAKE_MODULE_PATH so files outside of the buildroot in specific locations will be considered, too. On Line 775 the module "BareosLocalBuildDefinitions" is optionally loaded which will load build-specific definitions if they were put in the right place. Finally, Jenkins places one of the files from CD/builddefinitions as BareosLocalBuildDefinitions.cmake in CMake's path before starting the build. Having your own builddefinitions added before the build will make it. |
|
Thank you very much for this interesting information. Eventually, I ended up in fixing the webui downstream with the following commit: https://gitlab.alpinelinux.org/alpine/aports/-/commit/86370bac8e74f966fc904c074330f0a2b3d13a25 I took the opportunity to do other adjustments. I will investigate the CMake variable too. I think that this issue can be closed. Thanks again! |
|
Issue fixed by downstream. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-05-11 09:44 | fcolista | New Issue | |
2021-11-17 09:55 | bruno-at-bareos | Assigned To | => bruno-at-bareos |
2021-11-17 09:55 | bruno-at-bareos | Status | new => assigned |
2021-11-17 10:06 | bruno-at-bareos | Note Added: 0004343 | |
2021-11-17 13:41 | bruno-at-bareos | Note Added: 0004344 | |
2021-12-09 10:28 | bruno-at-bareos | Note Added: 0004384 | |
2021-12-09 10:53 | fcolista | Note Added: 0004386 | |
2021-12-09 11:02 | bruno-at-bareos | Note Added: 0004387 | |
2021-12-13 15:45 | bruno-at-bareos | Note Added: 0004390 | |
2021-12-14 11:34 | bruno-at-bareos | Note Added: 0004393 | |
2021-12-14 13:46 | bruno-at-bareos | Note Added: 0004394 | |
2021-12-14 15:21 | fcolista | Note Added: 0004395 | |
2022-01-13 15:42 | bruno-at-bareos | Status | assigned => closed |
2022-01-13 15:42 | bruno-at-bareos | Resolution | open => fixed |
2022-01-13 15:42 | bruno-at-bareos | Note Added: 0004475 |