# When is db5 NOT going to included



## ProServ (Aug 9, 2022)

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.


----------



## rigoletto@ (Aug 9, 2022)

Pkg is a package manager only. Options/dependencies/etc. are resolved at build time.


----------



## monwarez (Aug 9, 2022)

Just build a custom repos with ports-mgmt/poudriere and install those dependency by using your custom repository.
Then pkg should not try to reinstall it (db5).


----------



## zirias@ (Aug 9, 2022)

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.


----------



## mer (Aug 9, 2022)

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.


----------



## kjpetrie (Aug 14, 2022)

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@ (Aug 14, 2022)

Read https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261523. It's being worked on.


----------



## zirias@ (Aug 14, 2022)

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


----------



## kjpetrie (Aug 14, 2022)

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.


----------



## zirias@ (Aug 14, 2022)

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.


----------



## cy@ (Aug 14, 2022)

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.


----------



## cy@ (Aug 14, 2022)

GPL violations are only for those companies with deep pockets.


----------



## kjpetrie (Aug 14, 2022)

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.


----------



## msplsh (Aug 14, 2022)

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,


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.


----------



## cy@ (Aug 15, 2022)

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.


Can you explain how GPL restricts an end user or an entity simply running software in this scenario, please?


----------



## zirias@ (Aug 15, 2022)

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.


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?


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.


----------



## kjpetrie (Aug 15, 2022)

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.


----------



## zirias@ (Aug 15, 2022)

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


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.


Through the definition of "derived work", it goes a *lot* deeper than you assume.


----------



## mer (Aug 15, 2022)

zirias@ said:


> As far as GPL is concerned, any form of linking (even dynamically) is "derived work".


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.


----------



## kjpetrie (Aug 15, 2022)

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.


----------



## kjpetrie (Aug 15, 2022)

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.


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.


----------



## zirias@ (Aug 15, 2022)

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.


----------



## mer (Aug 15, 2022)

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@ (Aug 15, 2022)

mer said:


> Start one port at a time that depends on something.


That's not how the `DEFAULT_VERSIONS` mechanism works. And without it, users wouldn't have any option to override our defaults.


----------



## mer (Aug 15, 2022)

zirias@ said:


> That's not how the `DEFAULT_VERSIONS` mechanism works. And without it, users wouldn't have any option to override our defaults.


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


----------



## cy@ (Aug 15, 2022)

zirias@ said:


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


I always understood that a person could use AGPL but not modify or distribute any such modifications. What you're suggesting is one cannot use AGPL in a commercial environment or make money off it. What's the point of distributing or even using such software then?

Reading the AGPL license one could argue that if a website is running an AGPL licensed web server, the content on the site is automatically AGPL. If a person then navigates to that site and uses the information on that site to develop some kind of work (not necessarily software but anything, for instance an essay) such work would also be AGPL. Am I understanding this correctly? Seems cancerous.


----------



## zirias@ (Aug 15, 2022)

cy@ I'm not entirely sure about such edge cases, the _intent_ of AGPL seems to be to "protect" software for any kind of "cloud services". But this ambiguity is typically one of the major legal problems about anything *GPL, isn't it?


----------



## cy@ (Aug 15, 2022)

zirias@,

I'm not enamoured with cloud services. It's a means to take control away from the individual and put it into the hands of the corporation, especially to maintain a constant revenue stream. An extreme example is M$'s Windows Cloud service. IMO GPL tries to make itself as arcane as possible in order to give them latitude should any dispute end up in court. This seems counterintuitive because ambiguity in legal matters is like rolling dice in a crap shoot. Overly complex contracts often end up in court.


----------



## kjpetrie (Aug 15, 2022)

DEFAULT_VERSIONS is not used in devel/apr1 and changing it has no effect. The default is in the Makefile. If building the port it is possible to choose the database it uses at the configuration stage. I deselected db5 and it then set gdbm instead. That's licensed under GPLv3+. I didn't choose it. It was chosen by default when I rejected db5.


----------



## kjpetrie (Aug 15, 2022)

Why speculate?
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses


----------

