When is db5 NOT going to included

P

ProServ

db5 is a deprecated package. However consider the following when trying to run # pkg upgrade

# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (12 candidates): 100%
Processing candidates (12 candidates): 100%
The following 10 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
db5: 5.3.28_8

Installed packages to be UPGRADED:
bind-tools: 9.18.4 -> 9.18.5
libdrm: 2.4.111,1 -> 2.4.112_1,1
libgit2: 1.3.1 -> 1.3.2
mutt: 2.2.6_1 -> 2.2.7
nspr: 4.34 -> 4.34.1
unbound: 1.16.0 -> 1.16.2
wayland: 1.20.0_3 -> 1.21.0

Installed packages to be REINSTALLED:
apache24-2.4.54 (options changed)
apr-1.7.0.1.6.1_2 (options changed)

Number of packages to be installed: 1
Number of packages to be upgraded: 7
Number of packages to be reinstalled: 2

The process will require 49 MiB more space.
6 MiB to be downloaded.

Proceed with this action? [y/N]: n

Seems pkg doesn't look at /etc/make.conf because

DEFAULT_VERSIONS+=apache=2.4
DEFAULT_VERSIONS+=bdb=18
# DEFAULT_VERSIONS+=perl5=5.28
# DEFAULT_VERSIONS+=perl5=5.30
DEFAULT_VERSIONS+=perl5=5.32

FETCH_CMD=axel
FETCH_BEFORE_ARGS = -n 10 -a
FETCH_AFTER_ARGS=
DISABLE_SIZE=yes

Until they get db5 out I am unable to run pkg upgrade as it will install a deprecated package.

pkg remove the following and install via ports in order to avoid db5
ap24-mod_fastcgi: 2.4.7.1
ap24-mod_fcgid: 2.3.9
apache24: 2.4.54
apr: 1.7.0.1.6.1_2
mod_php80: 8.0.20

However this still doesn't help with pkg upgrade. So when there are vulnerabilities, one is SCREWED.
 
Please read this commit message: https://cgit.freebsd.org/ports/commit/?id=64fde89d49029e00b86e66041f3dfda16725ead7

In a nutshell, you can't just build packages with newer bdb versions because of licensing issues. The AGPL would forbid distributing packages of software with "incompatible" licenses linking bdb.

Something about the behavior of Oracle is written there, too, which is why the maintainer didn't want to continue the work on db5. Takers would most likely be very welcome.

So far, I don't know of any real threats using db5, but as it's now unmaintained, there is a certain risk. If you want to avoid it, all you can do for now is build locally with a newer bdb version. The resulting packages are legal to use, just not always to distribute.

I'd recommend to try ports-mgmt/poudriere-devel instead. It has a package fetching option, so you'll only need to build packages that are affected by your local settings, other packages will be taken from the official repos.
 
Deprecated doesn't always mean there are known vulnerabilities, of course that doesn't mean "there are none". Even if there is a known vulnerability, the "how" of it makes a lot of difference. If you have a system that is not publically exposed, that limits the how a lot of times. But Yes, Of Course, all known should be fixed.

Building ports for oneself is not always an option.
I see the same thing as a result of dailysecurity runs, but things needing it, all boil down to libreoffice for me. redland, apr, serf which are all depended on by libreoffice.
Serf depends on db5 because it depends on apr which depends on db5.
The question becomes, do redland and apr really need whatever functionality is coming from db5? I don't know haven't been bothered to check.
Then we can also ask, does libreoffice really need whatever is being provided by redland, apr and serf? If not, then the answer for me would be for the default options of libreoffice to change and the package updated. Again, something I haven't looked at.

Licensing is one of those things that a lot of people claim to care about, but lots of people ignore when terms inconveinence them. I am glad that someone other than me cares about terms of a license, even when it bothers them.
 
Given databases/db5 was deprecated 6 months before it was due to be removed at the end of June, I would have thought port maintainers would have had plenty of time to try alternatives and ensure it was no longer the default choice for any build. That does not seem to have happened, which I find worrying. I'm not clear why devel/apr1 requires a database backend as I don't consciously use one, but if it does it has a choice of four or five.

I don't know what compatibility problems might arise if the default database for programs with db5 on their backend is changed but, given that databases/db5 is deprecated and discontinued the issues need to be handled because it's not coming back, so it would seem sensible to handle them within the chosen time frame or to explain why that could not be done and when it is expected to happen. Otherwise it does tend to look as if no one cares.

I chose FreeBSD for my servers because I believed it had a superior security model to other systems, and this situation has damaged my confidence a little.
 
cy@ I'm surprised, after reading the commit message I linked above, I expected there would be at least a few "hard" licensing problems with just moving forward. Very nice to see this seems to be an option 👍
 
Thanks. The last 3 comments (12-14) look like a misunderstanding as the patch was updated about three weeks ago, but the updated patch is still being requested. Or maybe I've misunderstood!

For myself, using ports-mgnt/poudriere I've removed the configuration for DBD and it has defaulted to GDBM instead. I'm not quite sure what prevents the maintainers going for that option if db18 is difficult. Maybe it's licensing again.
 
kjpetrie speaking out of just recent experience, anything involving any flavor of GPL is a can of worms. And that's btw what kept the default BDB version at 5 for so long.

Berkeley DB changed license (as far as I know, might be even more) twice. Since version 6, it's AGPL, and this can really be troublesome when combining it with other software of different licenses. Our base libc still has an ancient BDB (IIRC version 1.18) built in, see db(3), which is still BSD licensed.
 
zirias@,

Licensing in ports isn't nearly the issue it is in base. The reason it's an issue in base is because vendors may wish to use FreeBSD in embedded or other products and my not want to distribute their source code, especially for hardware which will make it easier for competitors to reverse engineer hardware. I can see their point: invest in R&D and someone else reverse engineers the product, sells for less and puts you out of business. Reminds me of what happened to Nortel.

Using a BSD license circumvents this.

If a vendor wants to use ports they can but typically they'd probably want to build their own apps on top of FreeBSD. Otherwise they repackage FreeBSD like some firewall and GUI distributions.
 
My understanding was that the main difference between the two licences is that AGPL doesn't allow the component to be used in a closed source project. Since ports are source code I don't see how distributing them could breach the AGPL. The problem would only arise if someone tried to use the AGPLed port in a closed-source application they wished to distribute as such or use on a server after modification. But that's not FreeBSD's problem, that's theirs.
 
cy@ said:
Licensing in ports isn't nearly the issue it is in base. The reason it's an issue in base is because vendors may wish to use FreeBSD in embedded or other products and my not want to distribute their source code,
Click to expand...
This is a huge issue for people just running servers though (say they put email users in BDB) not just people creating distributable products with FreeBSD.
 
msplsh said:
This is a huge issue for people just running servers though (say they put email users in BDB) not just people creating distributable products with FreeBSD.
Click to expand...
Can you explain how GPL restricts an end user or an entity simply running software in this scenario, please?
 
kjpetrie said:
My understanding was that the main difference between the two licences is that AGPL doesn't allow the component to be used in a closed source project.
Click to expand...
No. It also disallows distributing packages of software linking it that doesn't have at least "GPL-compatible" license terms. A closer look "case by case" is necessary if you don't want to violate anything.
cy@ said:
Can you explain how GPL restricts an end user or an entity simply running software in this scenario, please?
Click to expand...
AGPL indeed adds such a scenario, in case you offer services to other users. In contrast to plain GPL, it's not only relevant who "runs" (operates) the software, but also who uses it e.g. in their web browser.
 
AGPL requires a user offering services to third parties through the licensed component to publish to those third parties the source code of their modified version if they modify the component.

I don't see how that restricts a user simply running it unmodified. Nor does it stop people modifying it for their own use. Even if they modify it to do something public, it only requires them to share what they've done. It doesn't restrict them unless they want to use it to create a monopoly in the service.

As for licence compatibility, that's one for the lawyers. I would expect any licence which doesn't try to modify the terms of another to be compatible, but I'm not a lawyer.

devel/apr1 is licensed under the Apache v2.0 licence.
databases/db18 is triple-licensed under AGPLv3, BSD 3-clause, and UPLv1.0

Working that lot out is definitely a lawyer's job!

Whether devel/apr1/databases/db18 constitute a "larger program" or an "aggregate" under the AGPL might depend on whether the combination is through linking or a "Standard Interface", but it's above my pay grade. I would only observe that running Apache products on GNU systems is normal practice.
 
kjpetrie said:
AGPL requires a user offering services to third parties through the licensed component to publish to those third parties the source code of their modified version if they modify the component.
Click to expand...
As far as GPL is concerned, any form of linking (even dynamically) is "derived work". Only LGPL has exceptions for this.
kjpetrie said:
As for licence compatibility, that's one for the lawyers. I would expect any licence which doesn't try to modify the terms of another to be compatible, but I'm not a lawyer.
Click to expand...
Through the definition of "derived work", it goes a lot deeper than you assume.
 
zirias@ said:
As far as GPL is concerned, any form of linking (even dynamically) is "derived work".
Click to expand...
And my opinion, that is the main problem.
I can understand the position of "If you modify the code you must give the modifications back to the community" but "I'm writing code that links against a library that I am not distributing or changing and I have to give my code to the community" makes no sense to me.
 
The purpose of the FSF is to fight proprietary software. They were founded in protest against it and are ideologically committed to the idea that software is public knowledge, not intellectual property.

It all started when MIT bought a printer and asked their technical fixer, one Richard Stallman, to write an interface for their computer to operate it. The printer manufacturer considered the printer's instruction set a trade secret and refused to release it, offering (no doubt for an inflated fee) to write the software for them (which would have threatened Stallman's job if it became the norm). Eventually, after a huge row, Stallman got the information on signing a non-disclosure agreement. He determined to fight for freedom of access to code and set up the FSF to do that.

So it's a sort of Culture War - public knowledge versus Intellectual Property - a very American conflict of ideas.

Forbidding linking without disclosing source forces people using Free libraries to release their work to the public.
 
  • Like
Reactions: mer
zirias@ said:
As far as GPL is concerned, any form of linking (even dynamically) is "derived work". Only LGPL has exceptions for this.
...
Through the definition of "derived work", it goes a lot deeper than you assume.
Click to expand...
Have you actually read the AGPL? It does not use the term "derived work". It does use the term "Corresponding Source", which includes "the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."

"However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work." (Those sentences appear in the opposite order in the paragraph.)

The question then, from a technical viewpoint, is whether apr is "specifically designed" to require db18? Clearly not as it can use alternatives and FreeBSD is merely choosing one database among others for that purpose.

Whether that choice creates a specific requirement (as apr won't install without an associated database) is one for the lawyers, as is whether extension in this context of the AGPL to cover apr conflicts with the Apache, BSD, or UPL licences in any way.
 
Oh great, now you're nitpicking about wording in AGPL that differs from GPL and essentially means the same anyways? And restricting the issue to "apr" specifically is just "moving the goalpost": Changing the default BDB version in ports affects all consumers. Coming up with an "optimistic" interpretation of a license text is a slippery slope.

All I'm telling you is: There's a reason (beyond purely technical build problems) this isn't a "simple change". If you refuse to acknowledge that, there's nothing I can do about it.
 
I disagree that specifically talking about apr is moving the goalpost. Why? Because I get the warnings about db5 on my systems because apr comes in as a downstream dependency of libreoffice :)
I don't the discussion on apr is "db18 vs db5" to me it's "why does apr need bdb anything?" If apr really does need bdb functionality or it's useless, then is there a "bdb" around that provides that functionality with a more friendly license? If so then to me the answer is "change the default dependency in the apr port".

Start one port at a time that depends on something.
 
zirias@ said:
That's not how the DEFAULT_VERSIONS mechanism works. And without it, users wouldn't have any option to override our defaults.
Click to expand...
I know that. I'm not strictly talking about DEFAULT_VERSIONS here. But you start with one port like apr that is using db5 and say to yourself "why does apr need db5 or berkley-db?" I took a very quick look at the Makefile in the port and it seems to be tied to "Utils" so the question is "if I disable berkley-db, what do I lose?"
Perhaps the functionality in apr requiring db5 is used by say 5% of the folks that use apr (directly or indirectly). To me that would imply maybe it should be turned off by default and those 5% will need to rebuild the port to include the functionality.

If it's more like 85% that use the functionality, then the question becomes what does it take to migrate this one port off db5 onto something else? Can the something else coexist on a system with db5 or not? Some ports can, others conflict, so the result of that changes how to solve it.

That's what I meant by start with one port at a time. Look at the ports that have db5 as a dependency, see how easy it would be to change each port, with change also including "do we need it" evaluation. After going through all the ports you wind up with fixed.

And yes, I am fully aware that me writing all this is easy and trivial while the execution is not at all easy and trivial when you focus on the entire ports tree. Kind of like "eating an elephant, you take one bite at a time".
 
You must log in or register to reply here.
Back
Top