devel/apr1 1.7.2 has been available since 02/01/2023: https://apr.apache.org . It should be updated.
Created attachment 241245 [details] git diff for devel/arp1 ``` devel/apr1: Update to 1.7.3 * Update APR-util to 1.6.3 * databases/db5 is depreacated since 2022-06-30 [2] * Switch default BDB to 18 PR: 269857, 261523 [2] Approved by: joneum (apache) With hat: apache ``` Currently running testport on 12.3/13.1 i386/amd64
(In reply to Bernard Spil from comment #1) can you add this patch to the commit, too? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230538
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f473a726dba249ec936d340b8b1167ce5996bd30 commit f473a726dba249ec936d340b8b1167ce5996bd30 Author: Bernard Spil <brnrd@FreeBSD.org> AuthorDate: 2023-04-01 15:42:03 +0000 Commit: Bernard Spil <brnrd@FreeBSD.org> CommitDate: 2023-04-01 15:42:03 +0000 devel/apr1: Update to 1.7.3 * Update APR-util to 1.6.3 * Fix build with MySQL 8 [2] * databases/db5 is depreacated since 2022-06-30 [3] * Switch default BDB to 18 PR: 269857, 230538 [2], 261523 [3] Submitted by: ngie With hat: apache devel/apr1/Makefile | 15 ++- devel/apr1/distinfo | 10 +- devel/apr1/files/patch-PR59332 (new) | 18 +++ devel/apr1/files/patch-PR61517 (gone) | 126 --------------------- ...r-1.7.0_configure => patch-apr-1.7.3_configure} | 4 +- ...kqueue.c => patch-apr-1.7.3_poll_unix_kqueue.c} | 14 +-- devel/apr1/files/patch-bdb18 | 4 +- 7 files changed, 43 insertions(+), 148 deletions(-)
(In reply to commit-hook from comment #3) Linking with db18 means the devel/apr1 port should be subject to AGPLv3. See also bug 261523, comment 39.
Created attachment 241267 [details] [patch] devel/apr1 update for bdb support (allow no bdb, add correct AGPLv3 license if bdb18) (In reply to John Hein from comment #4) Here's an update to reflect the correct license requirements if using databases/db18 and also allow the user to select no BDB if desired - as it was option before https://cgit.FreeBSD.org/ports/commit/?id=f473a726dba249ec936d340b8b1167ce5996bd30 Also this fixes the case of neither BDB option (BDB_VARS_OFF no longer works as it was intended since there are two BDB* options now). That was broken with the commit. While here also fix spelling for 'BERKELEYDB'. Tested with all three combinations (WITH=BDB WITHOUT=BDB5, WITH=BDB5 WITHOUT=BDB, WITHOUT="BDB BDB5"). I will open a new bug if it is preferred (or if I don't get anyone responding to this).
Looking good sofar. Built OK with MariaDB 10.11.2 and MySQL 8.0 Should land shortly after testport run.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c3471a56d23194c594c5dcf30ce3e8cebf127a2c commit c3471a56d23194c594c5dcf30ce3e8cebf127a2c Author: Bernard Spil <brnrd@FreeBSD.org> AuthorDate: 2023-04-02 18:34:41 +0000 Commit: Bernard Spil <brnrd@FreeBSD.org> CommitDate: 2023-04-02 18:34:41 +0000 devel/apr1: Update BDB support * Allow no BDB * Correct license with BDB 18 * Spelling PR: 269857 Submitted by: John Hein <jcfyecrayz liamekaens com> devel/apr1/Makefile | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
(In reply to commit-hook from comment #7) Thanks.
Comment on attachment 241267 [details] [patch] devel/apr1 update for bdb support (allow no bdb, add correct AGPLv3 license if bdb18) Technically bdb 6.0+ is AGPL; all prior releases have a different license: the Sleepycat license, which is very similar to BSD 3-clause: https://opensource.org/license/sleepycat-php/ . Does it make sense to mark this APL if the library is linked dynamically? IANAL and I'm not sure about static linking, but I thought dynamic linking only affected the resulting program once the code (as a whole) was run?
(In reply to Enji Cooper from comment #9) Mea culpa: APL -> AGPL.
Created attachment 241284 [details] [patch] Modify it so that GDBM_VARS is used. (In reply to commit-hook from comment #7) GDBM_VARS is now ignored in commit c3471a56d2. So packaging fails when GDBM=on. ---Begin OPTIONS List--- ===> The following configuration options are available for apr-1.7.3.1.6.3_1: IPV6=on: IPv6 protocol support ====> Database support GDBM=on: GNU dbm library support LDAP=off: LDAP protocol support MYSQL=off: MySQL database support NDBM=off: NDBM support ODBC=off: ODBC database backend PGSQL=off: PostgreSQL database support SQLITE=off: SQLite database support ====> Berkeley DB provider: you can only select none or one of them BDB=off: Berkeley DB support (AGPLv3) BDB5=off: Berkeley DB v5 support (deprecated) ====> Cryptography provider: you can only select none or one of them SSL=on: OpenSSL crypto driver NSS=off: NSS crypto driver ===> Use 'make config' to modify these settings ---End OPTIONS List--- =======================<phase: package >============================ ===> Building package for apr-1.7.3.1.6.3_1 pkg-static: Unable to access file /wrkdirs/usr/ports/devel/apr1/work/stage/usr/local/lib/apr-util-1/apr_dbm_gdbm-1.so:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/apr1/work/stage/usr/local/lib/apr-util-1/apr_dbm_gdbm.a:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/apr1/work/stage/usr/local/lib/apr-util-1/apr_dbm_gdbm.so:No such file or directory *** Error code 1
(In reply to Toshimichi Masubuchi from comment #11) Thanks! This fixed the same issue for me, too. One thing to note. If BDB5 option is set, packages fine with GDBM option is set, regardless this patch is applied or not. (Don't know why, though.) Untested for BDB option, as I'm not 100% certain that doing so hurts original author of apr1 or not, with pollution by AGPL license of databases/db18. I consider print/ghostscript*-agpl* is usually fine because most ports depending on it uses ghostscript executable (gs) to convert input data to PostScript or PDF. FreshPorts lists graphics/xfig as "required by: for Library". But for databases/db18, listed as "required by: for Library". This makes those ports linking with databases/db18 as AFPL'ed, or at least makes gray-zone. So even not tried.
(In reply to Toshimichi Masubuchi from comment #11) Apologies - the stray backslash was my fault in attachment 269857 Thanks for catching that.
(In reply to Enji Cooper from comment #9) > Does it make sense to mark this AGPL if the library is linked dynamically? IANAL and I'm not sure about static linking, but I thought dynamic linking only affected the resulting program once the code (as a whole) was run? Whether devel/apr1 is considered a 'derivative work' of berkeley db is less of a technical question - static vs dynamic linking is not an important distinction here. It's a more of a legal question. FSF seems to want linking with (and presumably using) a library to indicate a derivative work: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL Whether a court agrees with that FSF assertion would likely depend on the case. The fact that FSF has always asserted that position for GPL openly in public may be part of the evidence that COULD be used in a court case. Until Oracle states that linking and using their AGPLv3-covered BDB library without modification can be treated as not a derivative work (or a court weighs in on it), it is probably best to follow the FSF published guidelines. It could also be that Oracle may state that certain clauses of the license do not apply (like publishing source code if distributing the derived work). It might be easier to just pick a different license than to publish exceptions to their license of choice - and they have not selected a different license. So I assume they picked AGPLv3 as the license that best matches their licensing desires. For devel/apr1, I might be inclined to turn off BDB as a default for apr1 now that the default is to use the AGPLv3, but I have not surveyed all uses of apr in the ports tree to see what would be affected by that change. But either way, it's best to mark it as affected by AGPLv3 so that unsuspecting users are not blind-sided by possible license violations. So answering your question(s) directly - yes, I believe it makes sense to mark this as AGPL if using the AGPL licensed bdb library (regardless of the method with which the library is pulled into apr).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=cf27094347f49c6705120a5a4079a8135a022ae6 commit cf27094347f49c6705120a5a4079a8135a022ae6 Author: Bernard Spil <brnrd@FreeBSD.org> AuthorDate: 2023-04-04 07:52:15 +0000 Commit: Bernard Spil <brnrd@FreeBSD.org> CommitDate: 2023-04-04 07:52:15 +0000 devel/apr1: Fix build failure for GDMB option PR: 269857 devel/apr1/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to John Hein from comment #4) No--BDB 1.85 is clearly BSD 4-clause based on the licensing in the source files distributed with FreeBSD libc (see lib/libc/db/... and lib/libc/hash/...). I don't understand why devel/apr1's license was changed if this feature is enabled. Multiple sources online clearly confirm that the licensing is BSD 4-clause. Here's a breakdown of BDB's licensing history from Wikipedia: > Starting with the 6.0.21 (Oracle 12c) release, all Berkeley DB products are licensed under the GNU AGPL.[8][9] Previously, Berkeley DB was redistributed under the 4-clause BSD license (before version 2.0), and the Sleepycat Public License, which is an OSI-approved open-source license as well as an FSF-approved free software license.[10][11] The product ships with complete source code, build script, test suite, and documentation. The comprehensive feature along with the licensing terms have led to its use in a multitude of free and open-source software. Those who do not wish to abide by the terms of the GNU AGPL, or use an older version with the Sleepycat Public License, have the option of purchasing another proprietary license for redistribution from Oracle Corporation. This technique is called dual licensing. PS database/db18 is version 18, not version 1.85. BDB 18.x > 2.x, and is clearly licensed under a copyleft license.
I see where my confusion was -- databases/db18 is 18.x, not BDB 1.85. I opened a change to support building the DBM with BDB 1.85: https://reviews.freebsd.org/D40366 .
(In reply to Enji Cooper from comment #17) Supporting db 1.85 in libc seems reasonable here. I added a few comments in the review.