Without trying, just reading this: In the current state, the proposed change would bring a conflict with a rejected AGPLv3 license, because then the version auto-selection would then be able to pick a version with a rejected license. If AGPLv3 is rejected, the "6" should not be in _DB_DEFAULTS - this end (avoiding to auto-select a restrictive license) was the whole point of my original effort.

db5/db6 are high-profile ports included by many other ports, which would be infected even when run on the server's end. AGPLv3 is extremely limiting in a BSD mindset as it requires you to reveal the sources of your software-as-a-service!

My idea is that if the user were to reject AGPLv3, the bsd database code should auto-select db5 instead. If this is representable in the current framework, and you could offer a revised patch that implements that, I'd be happy to re-evaluate the new patch, otherwise we'd go fight a lost cause.

This revision now requires changes to proceed.May 11 2017, 10:00 PM

Okay, that makes sense. Then the variable should probably be flipped to AGPLv3_FORBIDDEN or something. The problem is that now it works opposite to everything else in the ports tree, which defaults to accepting licenses.

You said, "My idea is that if the user were to reject AGPLv3, the bsd database code should auto-select db5 instead." Right now it assumes rejection, and that doesn't feel right to me. I completely agree that AGPLv3 is an onerous license, but now the only way that people can get db6 is if they read Uses/bdb.mk.

Well, I see what you are aiming at, and the proposal of looking at the license policy and use that to decide on the eligible db versions makes sense.

The effects of the changes proposed above depend on the context. The frameworks (ports with portmaster/portupgrade or bare metal vs. synth/poudriere-and-pkg) are in a bit of a flux and not exactly congruent.
The current code will work best for ports builds, where the decision logic will grab whatever db version is already there to avoid conflicts. Meaning the original intent (if nobody removed the code) was written such that if db6 were already installed and db5 were not, then the framework would use the existing db6 so as not to introduce an additional requisite. db6, by contrast, is not eligible as a default dependency if neither is on the system, which makes part of your assessment true for clean-room rebuilds, for instance, through poudriere - these should default to db5 also in the future.

Most of this should only apply if WITH_BDB_HIGHEST is enabled, so perhaps I am overestimating the importance of the switch, but I don't want to introduce db6 as a requisite to other packages lightly if those will be happy with db5. The respective maintainers would need to make sure that their port that USES Berkeley DB is not incompatible with AGPL licensing, so as not to cast end users or administrators or server operators between a rock and a hard place.

Personally I do not object to the AGPLv3 and have sympathy for copyleft licensing, and also for usability improvements, but we need to prepare this carefully. I probably need to play a bit with this.

On that occasion, db48 should also be dropped from the framework altogether and be demoted to a pure and direct *coin port dependency while they still can't get their act together to remove the dependency on the db48 lock table sizing internals and finally implement the long-promised switch to leveldb.

Additional thought, if we really were to pull db6 up to a default dependency, this would be worthy of notes in UPDATING, CHANGES and the RELNOTES of the upcoming FreeBSD releases on their respective branches. (10.4 if ever; 11.1, 12.0).