View Issue Details

IDProjectCategoryView StatusLast Update
0001350bareos-coreGeneralpublic2022-01-13 15:42
Reporterfcolista Assigned Tobruno-at-bareos  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version20.0.1 
Summary0001350: AGPL-3.0 compliance
DescriptionHello.
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

TagsNo tags attached.

Activities

bruno-at-bareos

bruno-at-bareos

2021-11-17 10:06

manager   ~0004343

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
bruno-at-bareos

bruno-at-bareos

2021-11-17 13:41

manager   ~0004344

Adding also this link from our documentation
https://docs.bareos.org/bareos-20/Appendix/BareosCopyrightTrademarkAndLicenses.html
bruno-at-bareos

bruno-at-bareos

2021-12-09 10:28

manager   ~0004384

Any news here ?
fcolista

fcolista

2021-12-09 10:53

reporter   ~0004386

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
bruno-at-bareos

bruno-at-bareos

2021-12-09 11:02

manager   ~0004387

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.
bruno-at-bareos

bruno-at-bareos

2021-12-13 15:45

manager   ~0004390

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
bruno-at-bareos

bruno-at-bareos

2021-12-14 11:34

manager   ~0004393

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.
bruno-at-bareos

bruno-at-bareos

2021-12-14 13:46

manager   ~0004394

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.
fcolista

fcolista

2021-12-14 15:21

reporter   ~0004395

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!
bruno-at-bareos

bruno-at-bareos

2022-01-13 15:42

manager   ~0004475

Issue fixed by downstream.

Issue History

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