Originally posted by mos87
View Post
Announcement
Collapse
No announcement yet.
Fedora Looking To Transition The RPM Database From Berkeley DB To SQLite
Collapse
X
-
Originally posted by RahulSundaram View Post
That's correct. The problem with the Berkeley DB license change (from GPL to AGPL) is that it was driven by Oracle as a way to generate more revenue after the acquisition but it introduces licensing incompatibility for the users like RPM. RPM is under GPLv2 and this is AGPLv3 incompatible. To comply with the license, one would have to relicense RPM as well as its dependencies to be AGPLv3 or later. Red Hat doesn't use any copyright license agreement with RPM and RPM has hundreds of contributors and a long history. It would be a huge undertaking to do this. It is just much easier to switch the database backend instead
Comment
-
-
Originally posted by jabl View Post
sqlite is a good choice for an embedded key-value store with ACID properties even if you don't use the full power of SQL.
but there are actual stable and modern key-value engines, why go for something so 'catch all' for something so basic and stable as your system's very backbone...
Comment
-
Originally posted by mos87 View Post
suppose so.
but there are actual stable and modern key-value engines, why go for something so 'catch all' for something so basic and stable as your system's very backbone...
- Likes 2
Comment
-
Originally posted by RahulSundaram View Post
That seems to imply Sqlite is not stable or modern. In reality Sqlite is extremely robust and used pretty much everywhere, iOS for storing text messages, Firefox config store, FreeBSD for its package management system and heck, Solaris even uses it for basic bootup via SMF
I'm surprised that FreeBSD and Solaris use it for system stuff.
The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..
PS firefox ios et al cases are not surprising tho. I know FF uses it - but so it does a lot of other weird stuff. All web things do for that matter.Last edited by mos87; 17 March 2020, 10:52 AM.
Comment
-
Originally posted by mos87 View Post
I never intended to imply that.
I'm surprised that FreeBSD and Solaris use it for system stuff.
The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..
PS firefox ios et al cases are not surprising tho. I know FF uses it - but so it does a lot of other weird stuff. All web things do for that matter.
Sqlite is the most deployed DB engine on the planet (a lot of applications manage their settings and other internal data using Sqlite), so if it works for all those people, it can't be the poorest choice for rpm, can it?
- Likes 1
Comment
-
Originally posted by CommunityMember View Post
The general beef with AGPLv3 for something like BDB is the claim that it discriminates against a category of user (those that want to use the software/library in their non-open solution), as the linking exception does not apply (in simple terms, you can't link to (later versions of) BDB without open sourcing everything). AGPLv3 is typically used to ensure that only the developer themselves can decide how to monetize any use of their work (typically by providing a dual-use license for those that do not want to open source all their software), although even AGPLv3 has a cloud service loophole which the SSPL was intended to address (to ensure, again, that the developer could determine monetization). Whether every piece of software *should* be open source is an interesting discussion, but *requiring* all software to be open source is considered a step too far by many (at least Debian and RedHat) as it eliminates freedoms.
Sure, many companies like Oracle use AGPL or even just the GPL plus a CLA to make sure they have a monopoly on proprietary forks of a project. But your use of 'typically' is unfair. The FSF didn't create the AGPL with proprietary forks in mind, and hundreds of projects that adopt the AGPL don't use it with proprietary forks in mind either.
I suppose you would argue that Cuisinart manufactures knives typically for sale to murderers, too.
Comment
-
Originally posted by mos87 View Post
The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..
Comment
Comment