credativ® Inside - Page 2 of 6 - credativ®

Configuring ZFS in Proxmox® requires precise planning and a thorough understanding of its various parameters. This guide shows you how to optimally set up and tune ZFS for maximum performance. The difficulty level is advanced, as ZFS configuration requires deeper system knowledge.

You will need approximately 2–3 hours for the complete setup. Prerequisites include a functional Proxmox system, at least two identical hard drives for the RAID configuration, and access to the Proxmox web GUI and an SSH connection. Upon completion, you will have a professionally configured ZFS system with optimal performance. (more…)

A stable Proxmox® cluster requires precise Corosync configuration for reliable cluster communication. This guide shows you how to optimally set up your Proxmox® cluster network and correctly configure Corosync. The usual process for system administrators with basic Proxmox® VE knowledge is correctly set up by the automatic installer or in the Proxmox VE frontend, requiring no manual work.

We explicitly advise against working on the configuration without deep knowledge of Corosync’s intricacies and the consequences of custom settings. This should be left to specialists with expertise. However, this overview may be helpful for experimentation and further education. (more…)

Introduction and Project History

Nowadays, cloud storage is included with every second account for various services. Whether it is a Google account with Drive or a Dropbox account created to collaborate with other project participants. Unfortunately, these are unencrypted, and it is often unclearly communicated how the service provider handles the stored data and what it might be used for. This means, however, that it cannot be used securely.

Cryptomator is an open-source encryption tool developed in 2015 by the German company Skymatic GmbH to enable the secure storage of data in cloud storage solutions. The project arose from the realization that while many cloud providers offer convenience, they do not guarantee sufficient control over the confidentiality of stored data. It addresses this problem through client-side, transparent encryption that works independently of the respective provider. This is implemented by creating encrypted vaults (“Vaults”) in any cloud storage, with all encryption operations performed locally on the end device. As a result, control over the data remains entirely with the user.

Since its release, Cryptomator has evolved into one of the most well-known open-source solutions for cloud encryption. In 2016, the project was even honored with the CeBIT Innovation Award in the “Usable Security and Privacy” category. Development continues actively, with a focus on stability, compatibility, and cryptographic robustness.

Licensing

The project itself is available under a dual licensing structure. The desktop version is licensed as an open-source project under the GNU General Public License v3.0 (GPLv3). This means that the source code is freely viewable, modifiable, and redistributable, as long as the terms of the license are met. The source code is publicly accessible on GitHub: https://github.com/cryptomator/cryptomator.

For companies wishing to integrate Cryptomator into commercial products (e.g., as a white-label solution), the manufacturer offers a proprietary licensing option. The desktop software remains free to use, while development is primarily funded through donations and revenue from the mobile apps.

The mobile applications for Android and iOS are available in their respective app stores. While the basic functions are free, full functionality requires in-app purchases which, as mentioned, fund the project.

Architecture and Functionality

Cryptomator is based on the principle of transparent, client-side encryption. It creates encrypted directories—so-called vaults—within any folder managed by a cloud synchronization service. The software mounts these vaults as a virtual drive, making them behave like a normal folder in the file system for the user. This also works in local folders and does not necessarily have to be located in a synchronized folder.

All file operations (reading, writing, renaming) are transparently intercepted and encrypted or decrypted by Cryptomator before they are stored on the hard drive and/or synchronized to the cloud. The actual synchronization is handled by the respective cloud client—Cryptomator itself does not perform any network communication.
Cryptomator generates many small files from the data (e.g., dXXX for data blocks). It is important that the cloud client synchronizes these reliably to avoid data corruption. However, this also ensures that no conclusions can be drawn from the number and size of the files.

The architecture is designed so that no central servers are required. There is no registration, no accounts, and no transmission of metadata. The system operates strictly according to the zero-knowledge principle: only the user possesses the key for decryption.

However, this also means that if the “vault key” is lost, there is no longer any way to access the data. There is, however, the option to have an additional recovery key created when a vault is set up. This should then be kept in a suitably secure location, such as in a KeePass database or another password manager of your choice.
Since the file masterkey.cryptomator is also critical for decryption, it must be ensured that it is not deleted. In case of doubt, it can simply be backed up externally, just like the password and the recovery key.

If a vault is unlocked, it can be selected directly via the GUI client and opened in the file manager using a button.

In the locally mounted and decrypted vault, currently only the initial file can be found:

$ ls -l ~/.local/share/Cryptomator/mnt/testtresor
total 0
-rw-rw-r-- 1 danilo danilo 471 10. Feb 11:07 WELCOME.rtf

In the actual file system where the vault was created in encrypted form, it looks like this instead:

$ tree ~/Cryptomator/testtresor/
/home/danilo/Cryptomator/testtresor/
├── c
├── d
│ └── KY
│ └── FEV7TA6N4UV5I3PFT6P7D7DCTNGLDU
│ ├── dirid.c9r
│ └── feotyFJDU3AD_3wyOp7Tbd83QUgUGcB46vYT.c9r
├── IMPORTANT.rtf
├── masterkey.cryptomator
├── masterkey.cryptomator.57A62350.bkup
├── vault.cryptomator
└── vault.cryptomator.2BB16E73.bkup
5 directories, 7 files

The IMPORTANT.rtf file created here only contains a note indicating that it is a Cryptomator vault and a link to the documentation.

Cryptographic Procedures

Cryptomator’s security is based on established, standard-compliant cryptographic procedures:

– Encryption of file contents: AES-256 in SIV-CTR-MAC or GCM mode, depending on the version. This ensures both confidentiality and integrity.

– Encryption of file and folder names: AES-SIV to enable deterministic encryption without opening security vulnerabilities.

– Password derivation: The master key is derived from the user password using **scrypt**, a memory-intensive key derivation algorithm that makes brute-force attacks more difficult.

– Key management: Each vault has a 256-bit encryption and MAC master key. This is encrypted with the Key Encryption Key (KEK) derived from the password and stored in the `masterkey.cryptomator` file.

Further details on the cryptographic architecture are described in the official documentation.

Integration of Third-Party Services

Cryptomator distinguishes between desktop and mobile clients regarding cloud integration.

On desktop systems (Windows, macOS, Linux), integration works via the local synchronization folder of the respective cloud provider. Since Cryptomator only encrypts a folder and does not perform direct network communication, compatibility is very high. Any provider that provides a local folder (e.g., Dropbox, Google Drive, OneDrive, Nextcloud) can be used. Aside from this, an official [CLI client](https://github.com/cryptomator/cli) is also available. However, this appears to be less actively developed than the GUI client; at least the last commit and release are already more than six months old.

On mobile devices (Android, iOS), integration takes place either via native APIs or via the WebDAV protocol. Supported providers such as Dropbox, Google Drive, or OneDrive are offered directly in the app. For other services that support WebDAV (e.g., Nextcloud, ownCloud, MagentaCLOUD, GMX, WEB.DE), a connection can be established manually via the WebDAV interface.

A current list of supported services is available here.

Important Notes on Integration

– WebDAV and Two-Factor Authentication (2FA): For providers with 2FA, an app-specific password is often required, as the main password cannot be used for WebDAV.
– pCloud: WebDAV is disabled when 2FA is activated, which makes use via Cryptomator impossible.
– Multi-Vault Support: Multiple vaults can also be managed in parallel in the client.

External Security Validation of the Project

In 2017, Cryptomator underwent a comprehensive security audit by the recognized security company Cure53. The test covered the project’s core cryptographic libraries, including cryptolib, cryptofs, siv-mode, and cryptomator-objc-cryptor. The audit was predominantly positive: the architecture was rated as robust and the attack surface as very small.

One critical finding concerned unintentional public access to the private GPG signing key, which has since been resolved. Another less critical note referred to the use of AES/ECB as the default mode in an internal class, which, however, was not used in the main encryption path.

The full audit report in PDF format is publicly available.

This is the only publicly available audit of the project that the author could find. However, since audits are generally expensive and time-consuming, the project should be credited for having it conducted and made publicly available.

All other known security issues are also listed on the project’s GitHub page and are visible to everyone.

Conclusion

Cryptomator represents a technically sophisticated, transparent, and cross-platform solution for encrypting data in cloud storage or local data. Through the consistent implementation of the zero-knowledge principle and the use of established cryptographic procedures, it offers high security combined with good user-friendliness.

The separation between encryption and synchronization enables broad compatibility with existing cloud services without them having to change their infrastructure. The open-source nature of the software allows for audits and fosters trust in its security.

Even for less technically savvy users who want to maintain control over their data, Cryptomator is one of the best options available thanks to the GUI client. The specific notes regarding the peculiarities of mobile integration and the fact that both the master key and the password must be strictly protected are, of course, still essential.

Update: Proxday will now take place on October 15, 2026. We have moved the date to avoid a clash with the Dutch Proxmox Day of our friends at Tuxis. All other information remains current – the CfP deadline is extended accordingly to July 31, 2026.

Save the Date: On October 15, 2026, we are bringing the Proxmox world together in Mönchengladbach. With Proxday 2026, we are creating an event that goes far beyond our previous formats. While our Virtualization Gathering and Business Breakfast have already provided valuable impetus, it is now time for the ‘Next Level’. We are dedicating a full day to Proxmox VE and finally giving the community the space it deserves – for deep dives, exchange of experiences, and technical innovations.

Proxday is organized by credativ GmbH and is intended as a meeting point by the community for the community. The focus here is on practical exchange of experience, in-depth technical knowledge, and networking among experts. To ensure the program reflects the full spectrum of the Proxmox world, we invite you to actively contribute to shaping the day.

Call for Papers: Share Your Expertise!

The Call for Papers (CfP) is now officially open. We are looking for exciting presentations, technical deep dives, and practical experience reports. Whether you have built a complex infrastructure, developed automation solutions, or successfully migrated to Proxmox – the community benefits from your knowledge.

Possible topics for your submission:

• Proxmox VE & Storage: Best practices for Ceph, ZFS, and high availability.
• Automation & IaC: Proxmox management with tools like Ansible or Terraform.
• Backup Strategies: Use of Proxmox Backup Server in enterprise environments.
• Networking & Security: SDN implementations and security concepts.
• Migration: Strategies and case studies for switching from other hypervisors.

The submission deadline for the Call for Papers is July 31, 2026.

Event Overview

We have chosen the Hotel Palace St. George in Mönchengladbach as the venue. With its combination of classic architecture and modern amenities, the hotel provides the perfect setting for a focused conference and intensive exchange.

• When: October, 15th 2026
• Where: Mönchengladbach (Hotel Palace St. George)
• What: A day full of expert presentations, networking, and community exchange around Proxmox.

Join us now

Take the opportunity to present your projects to an expert audience or to get early information about the event. All details about the Call for Papers and the venue can be found on the official event website.

We look forward to welcoming the Proxmox community to Mönchengladbach in October 2026!

👉 Click here to go directly to the CfP on www.proxday.de

LanguageTool: Powerful Language Checking on Your Own Network

LanguageTool is one of the leading open-source solutions for grammatical and stylistic text checking. While most users are likely familiar with the cloud-based version, the on-premise (self-hosted) variant is gaining increasing importance – especially for businesses, educational institutions, and organizations with high data protection and control requirements.

The core of LanguageTool is licensed under the GNU Lesser General Public License (LGPL-2.1). This license permits the free use, modification, and distribution of the software, even in commercial environments, provided that changes to the original code are also published under the LGPL. The license is “weak copyleft,” meaning that applications using LanguageTool as a library do not necessarily have to be open source. License information can be found in the official repository on GitHub in COPYING.txt. Third-party components such as dictionaries may be under different licenses (e.g., GPL).

There is an open-source version as well as an extended premium version with additional features such as improved style, semantics, and format checks. A detailed overview can be found on the website. It is important to note that for self-hosted instances, premium features are only available for commercial use and by individual quote. However, this is communicated with difficulty and primarily in the forum upon request. It also appears that not all premium features are available.

Unfortunately, LanguageTool made changes to the use of browser extensions in 2026: a premium subscription is now required for cloud usage. The self-hosted version remains unaffected – here, the browser extension can still be connected to your own server to enable seamless integration into web applications such as email, CMS, or forms.

Features

LanguageTool has a modular design and combines several technologies. These go far beyond the integrated spell checking of, for example, LibreOffice or Thunderbird. However, a much-desired feature is currently not yet available: support for multiple languages within a single document.

1. Morphological Analyzer & POS TaggerFirst, the text is broken down into sentences and words. Each word receives at least one Part-of-Speech (POS) tag (e.g., noun, verb, adjective). The analyzer also considers inflectional forms, so “gegangen” (gone) is correctly identified as a past participle.

2. DisambiguatorMany words have multiple meanings (e.g., “Bank” as a bench or a financial institution). The disambiguator uses contextual information to select the correct interpretation. This is done either rule-based or statistically and improves the accuracy of subsequent rule application.

3. Rule Engine (XML & Java)
   Error detection is based on a combination of:

   • XML Rules: Simple patterns like “dass instead of das” or “missing comma before weil.” These are easy to write and maintain.
   • Java Rules: Complex, context-dependent rules that are programmatically implemented, e.g., for sentence structure or cross-text repetitions.

4. N-Gram Model (optional)For improved detection of confusions (e.g., “ihre vs. ihre“), an n-gram model can be added. This uses statistical data from vast text corpora (e.g., Google Books) and compares the probability of word sequences. The n-gram data is not included in the standard package but can be downloaded locally.

5. User Dictionariesspelling_custom.txtCustom technical terms can be added to avoid false positives. This is done either via the API or by editing the
   .
6. Markup Support
   With AnnotatedText, HTML, LaTeX, or XML can be processed without distorting position information.
7. Java API
   For direct integration into Java applications, JLanguageTool offers a powerful interface

Integration

Integration is versatile: in addition to the browser extension, LanguageTool supports APIs for custom applications, plugins for LibreOffice, Microsoft Word, Thunderbird, and direct connection to development tools. The self-hosted solution thus offers maximum flexibility, security, and scalability – ideal for use in sensitive or regulated environments.

A complete list can be found in the following link. Notably absent is a dedicated plugin for the Outlook client. As far as could be ascertained, the effort was probably not justified by the demand. However, there are only older posts in the forum about this. Nevertheless, LanguageTool in the browser also works without problems with Outlook in the browser. The limitation should therefore only affect the desktop client.

Deployment

On Github, you will find various options for installing a self-hosted service. Especially for local installations, a Docker instance is probably the fastest to deploy.

Several images are linked here; the author chose one as an example.

The maintainer also offers various almost ready-to-use copy-paste solutions to start the service. This includes a Docker Compose template to start the service as an unprivileged user and keep the file system read-only:
To use this, the content must be written into, for example, a docker-compose.yml, the ‘ngrams’ and ‘fasttext’ directories created, and permissions adjusted for, for example, the ‘nobody’ user. All subsequent examples were performed on a Debian 13 system.

$ mkdir ~/Programme/Languagetool
$ cd ~/Programme/Languagetool
$ mkdir ngrams fasttext
$ chown nobody:nogroup ngrams fasttext


Below is the content of the compose-yaml with support for n-grams in German and English. It is important to note that the n-gram data is quite large and requires several GB of storage.
Currently, it is approximately 3 GB for German and 15 GB for English.

services:
languagetool:
image: meyay/languagetool:latest
container_name: languagetool
restart: unless-stopped
user: "65534:65534"
read_only: true
tmpfs:
- /tmp:exec
cap_drop:
- ALL
security_opt:
- no-new-privileges
ports:
- 8081:8081
environment:
download_ngrams_for_langs: de, en
volumes:
- ./ngrams:/ngrams
- ./fasttext:/fasttext


The service can then be started with the following command:

$ docker compose up -d
# Das Herunterladen der n-grams kann etwas dauern.
$ docker ps
2af60ed08544 meyay/languagetool:latest "/sbin/tini -g -e 14…" 4 weeks ago Up 3 hours (healthy) 0.0.0.0:8081->8081/tcp, :::8081->8081/tcp languagetool


The service is now available, and the plugins should be able to access it. There is no authentication or similar. Anyone with access to the URL and port can use it.

Conclusion

LanguageTool on-premise combines data protection-compliant text checking with flexible integration. The LGPL-2.1 license allows free use, while comprehensive interfaces enable seamless integration into office and web applications. With the correct configuration, a local server becomes a fully functional, enterprise-grade solution for linguistic checking.

Proxmox® system requirements vary significantly depending on the deployment scenario. For a basic installation, you need at least a 64-bit CPU with virtualization support, 2 GB of RAM, and 32 GB of storage space. However, production environments require considerably more resources, depending on the number of virtual machines and their workloads. Correct hardware sizing determines the performance and stability of your Proxmox infrastructure.
(more…)

Mönchengladbach (DE) / Naarden (NL) — February 4th, 2026

Splendid Data and credativ GmbH announce strategic partnership to accelerate Oracle-to-PostgreSQL migration for enterprises.

Splendid Data and credativ GmbH today announced a strategic partnership to help organisations modernize complex Oracle database environments by migrating to native PostgreSQL in a predictable, scalable and future-proof manner.

The partnership addresses growing enterprise demand to reduce escalating database licensing costs while regaining autonomy, ensuring digital sovereignty and preparing data platforms for AI-driven use cases. PostgreSQL is increasingly selected as a strategic database foundation due to its open architecture, strong ecosystem and suitability for modern, data-intensive workloads.

Splendid Data contributes its Cortex automation platform, designed to industrialize large-scale Oracle-to-PostgreSQL migrations and reduce risk across complex database estates. credativ adds deep PostgreSQL expertise, enterprise-grade platform delivery and 24×7 operational support for mission-critical environments. Together, the partners also align on PostgresPURE, a production-grade, pure open-source PostgreSQL platform without proprietary extensions or vendor lock-in.

Enterprises are making long-term decisions about licensing exposure, autonomy and AI readiness. This partnership combines migration automation with trusted PostgreSQL operations.

“Enterprises are making long-term decisions about licensing exposure, autonomy and AI readiness,” said Michel Schöpgens, CEO of Splendid Data. “This partnership combines migration automation with trusted PostgreSQL operations.”

Together we enable customers to modernize faster while maintaining control, transparency and operational reliability.

David Brauner, Managing Director at credativ, added: “Together we enable customers to modernize faster while maintaining control, transparency and operational reliability.”

The initial geographic focus of the partnership is Germany, where credativ has a strong customer base. The model is designed to scale toward international enterprise customers over time. Joint activities will include coordinated go-to-market efforts, enablement of credativ teams on Cortex, and the delivery of initial pilot projects with shared customers.

Both companies view the partnership as a long-term collaboration aimed at setting a new standard for large-scale, open-source database modernization in Europe.

About credativ

credativ GmbH is an independent consulting and service company focusing on open source software. Following the spin-off from NetApp in spring 2025, credativ combines decades of community expertise with professional enterprise standards to make IT infrastructures secure, sovereign and future-proof, without losing the connection to its history of around 25 years of work in and with the open source community.

About Splendid Data

Splendid Data is a PostgreSQL specialist focused on large-scale Oracle-to-PostgreSQL migrations for enterprises with complex database estates. Its Cortex platform enables automated, repeatable migrations, while PostgresPURE provides a production-grade, open-source PostgreSQL platform without vendor lock-in.

Contact credativ:

Peter Dreuw, Head of Sales & Marketing (peter.dreuw@credativ.de)

Contact Splendid Data:

Michel Schöpgens, CEO (michel.schopgens@splendiddata.com)

proxmoxer is a Python library for interacting with the Proxmox REST API, whose compact implementation stands in contrast with the API’s large amount of endpoints.

The library’s implementation does not need to change when endpoints are added or amended in new Proxmox releases, but as a consequence, the few functions which handle those many endpoints have not been annotated in a way that resembles the returned data type of each specific endpoint.

proxmoxer-stubs provides external stub files and data containers for proxmoxer, which it generates from the API documentation’s specification for Proxmox versions 6 to 9.

Static type-checkers may then infer the types of a call chain like this:

typing.reveal_type(
    proxmoxer.ProxmoxAPI().cluster.notifications.endpoints.smtp("argument").get()["mode"]
)

Revealed type is "Literal['insecure'] | Literal['starttls'] | Literal['tls']"

PostgreSQL offers various data types for the structured storage of different information in databases. The most important categories include numeric data types (INTEGER, BIGINT, DECIMAL), string data types (VARCHAR, TEXT), date and time data types (TIMESTAMP, DATE), and special data types such as JSON, BOOLEAN, and ARRAY. The correct selection significantly optimizes storage space and query performance.

What are PostgreSQL data types and why are they important?

PostgreSQL data types define what kind of data can be stored in a column and how that data is interpreted. They determine storage requirements, validation rules, and the available operations for each data value. Correctly selecting data types is crucial for database performance and data integrity.

Data types optimize storage space by precisely defining the required storage capacity. For example, an INTEGER requires 4 bytes, while a BIGINT uses 8 bytes. With millions of records, this difference has a significant impact on memory usage and query speed.

PostgreSQL organizes data types into various categories: numeric types for numbers, string types for text, date and time types for temporal data, and advanced types such as JSON, arrays, and geometric data structures. Each category offers specific functions and optimizations for different use cases.

Which numeric data types does PostgreSQL offer?

PostgreSQL provides several numeric data types: INTEGER, BIGINT, SMALLINT for integers, as well as DECIMAL, NUMERIC, REAL, and DOUBLE PRECISION for floating-point numbers. Integer data types differ in their value range and storage requirements, while floating-point types offer different levels of precision.

SMALLINT uses 2 bytes and stores values from -32,768 to 32,767. INTEGER requires 4 bytes for values between -2,147,483,648 and 2,147,483,647. BIGINT uses 8 bytes and supports extremely large numbers up to 9,223,372,036,854,775,807.

For decimal numbers, DECIMAL (synonymous with NUMERIC) offers exact precision without rounding errors, making it ideal for financial calculations. REAL uses 4 bytes for single floating-point precision, while DOUBLE PRECISION uses 8 bytes for double precision. In PostgreSQL development, the choice between exact and approximate arithmetic is crucial for data quality.

How do text and string data types work in PostgreSQL?

PostgreSQL offers four main types for text data: CHAR for fixed length, VARCHAR for variable length with a maximum, TEXT for unlimited length, and CITEXT for case-insensitive comparisons. VARCHAR and TEXT are the most commonly used options for most applications.

CHAR(n) always reserves n characters of storage space and pads shorter values with spaces. VARCHAR(n) stores only the characters actually used plus one byte for length information. TEXT has no length limit and offers maximum flexibility for large amounts of text.

Performance considerations show that VARCHAR and TEXT offer virtually identical performance. PostgreSQL optimizes both types equally efficiently. The choice between VARCHAR with a length limit and TEXT without a limit depends on validation requirements. PostgreSQL fully supports Unicode (UTF-8) and enables international character sets without additional configuration.

Which date and time data types are available in PostgreSQL?

PostgreSQL provides five temporal data types: DATE for calendar dates, TIME for times of day, TIMESTAMP for date and time, TIMESTAMPTZ for timezone-aware timestamps, and INTERVAL for time spans. TIMESTAMPTZ is recommended for most applications as it correctly manages time zones.

DATE stores only calendar dates without time information (YYYY-MM-DD). TIME records times of day with optional microsecond precision. TIMESTAMP combines both without a time zone reference, while TIMESTAMPTZ stores timestamps in UTC and converts them to the session time zone during queries.

INTERVAL allows calculations with time spans such as “3 months 2 days 14 hours”. PostgreSQL offers extensive functions for date arithmetic, formatting, and time zone conversion. Best practices recommend the consistent use of TIMESTAMPTZ for all time-related data in international applications.

What are special PostgreSQL data types and when should they be used?

PostgreSQL offers advanced data types for modern application requirements: BOOLEAN for truth values, UUID for unique identifiers, JSON/JSONB for structured documents, ARRAY for lists, and geometric types for spatial data. JSONB and ARRAY enable flexible data structures without separate tables.

BOOLEAN efficiently stores the truth values true, false, or null. UUID generates globally unique 128-bit identifiers, ideal for distributed systems. JSON stores documents as text, while JSONB provides a binary, indexable version with better performance.

ARRAY allows the storage of multiple values of the same type in a single column, for example, INTEGER[] for lists of numbers. Geometric types such as POINT, LINE, and POLYGON support spatial applications. These advanced data types integrate seamlessly into modern application architectures and reduce the complexity of data models through native support for complex structures.

How credativ® helps with the optimal use of PostgreSQL data types

credativ® supports companies in the strategic selection and implementation of the right PostgreSQL data types for maximum performance and data integrity. Our PostgreSQL solutions analyze your specific requirements and develop customized database structures:

• Performance Analysis: Evaluation of existing data structures and identification of optimization potential
• Data Modeling: Development of efficient schemas with optimally chosen data types
• Migration and Modernization: Secure transition of legacy data structures into modern PostgreSQL implementations
• Training and Consulting: Knowledge transfer for your development teams on best practices for data types
• 24/7 Support: Continuous support and optimization of your PostgreSQL environments

Contact us for a free initial consultation and find out how the right data type strategy can revolutionize your database performance.

PostgreSQL® uses a permissive open-source license known as the PostgreSQL License. It is based on the BSD license and allows both commercial and non-commercial use without restrictions. Companies can use, modify, and redistribute PostgreSQL free of charge, and only need to retain the original copyright notice.

What is the PostgreSQL License, and why is it so popular?

The PostgreSQL License is a BSD-like open-source license that grants maximum freedom in using the database. It was specifically designed to offer both developers and companies the greatest possible flexibility, without the legal complexities of other licensing models.

This license is particularly popular with companies because it contains no copyleft provisions. This means you can integrate PostgreSQL into proprietary software without having to disclose your own application’s source code. The license dates back to 1996 and has since established itself as a stable, trusted licensing model.

The core characteristics make PostgreSQL attractive for commercial projects: no license fees, no limits on the number of users or installations, and full control over modifications. Companies particularly value the legal certainty and the ability to use PostgreSQL without long-term contractual commitments.

How does PostgreSQL differ from other database licenses?

PostgreSQL differs significantly from other database licensing models due to its permissive structure. While MySQL® is licensed under the GPL, Oracle® uses proprietary licenses, and MongoDB® introduced the restrictive SSPL, PostgreSQL remains consistently open and business-friendly.

The comparison shows clear differences: MySQL under the GPL often requires paid licenses for commercial use in proprietary software. Oracle Database generally requires license fees and offers only limited free versions. With the SSPL, MongoDB introduced a license that obliges cloud providers to disclose their entire service software.

For companies, PostgreSQL offers clear advantages: no licensing costs, no legal pitfalls when integrating into commercial products, and no obligation to disclose proprietary developments. PostgreSQL support is also available from various providers, without vendor lock-in effects.

The PostgreSQL License is compatible with almost all other open-source licenses. For example, PostgreSQL code can be incorporated into a GPL-licensed project without any issues.

Comparison of the GNU General Public License (GPL), the GNU Affero General Public License (AGPL), and the PostgreSQL License.

This table highlights, in particular, the differences in the obligation to disclose source code, which is crucial for commercial use and proprietary software development:

The key business advantage of the PostgreSQL License

As the table shows, the biggest difference lies in how derivative works are handled and in integration into proprietary software.

The GPL and AGPL are strong copyleft licenses. This means: If you integrate software (such as a GPL-licensed database) into your own software and distribute this combined solution, the “viral effect” applies. Your own software is legally considered an extended work of the GPL software and must also be released under the GPL (including disclosed source code). The AGPL goes even further and requires source code disclosure even if you only offer the modified database as a service (SaaS/cloud) over a network.

The PostgreSQL License, by contrast, is a very permissive license (similar to MIT or BSD). It explicitly grants permission to use, copy, modify, and distribute the software and its documentation for any purpose, without fees or a written contract. The only condition is that the copyright notice and the two paragraphs of the disclaimer remain included in all copies. For a company, this represents a major business advantage: you can easily integrate a PostgreSQL database into a commercial, closed (proprietary) software product and sell it without ever being forced to disclose your own product’s source code.

Please note that this information reflects only the current state of our research and does not constitute legal advice. For a specific assessment of a particular use case, we recommend seeking individual legal advice for the respective case and the relevant jurisdiction.

What should you consider when using PostgreSQL commercially?

When using PostgreSQL commercially, you should follow basic compliance rules to ensure legal certainty. Document PostgreSQL usage in your project, retain copyright notices, and establish internal policies for handling open-source components.

Practical guidelines for legally compliant use include: maintain a software inventory list of all open-source components used, ensure development teams are informed about licensing terms, and store all relevant license texts and copyright notices in a central repository.

To minimize risk, professional support is recommended, especially for business-critical applications. Regular updates and security patches should be planned. Professional PostgreSQL support can help you manage both technical and legal aspects optimally and fully leverage the benefits of the permissive license. For a legal assessment of the licensing situation, please consult your attorney.

Liability

The PostgreSQL License also includes a warranty disclaimer. The software is provided “AS IS”. In our view, recourse against the authors or the project in the event of an error is therefore largely excluded. For this reason, in a business environment you should always safeguard PostgreSQL operations through a qualified service provider, such as the PostgreSQL Competence Center of credativ GmbH. Depending on compliance requirements, this may even be mandatory.

How credativ® supports PostgreSQL implementation

As an ISO 9001 and ISO 27001 certified service provider, credativ® offers comprehensive consulting and support for the optimal use of PostgreSQL. Our expert team helps you fully leverage the benefits of the PostgreSQL License while meeting all compliance requirements.

Our services include:

• Compliance consulting: Integrating PostgreSQL into your commercial software
• Technical implementation: Professional PostgreSQL installation and configuration
• 24/7 support: Continuous support for your PostgreSQL environment
• Migration and updates: Secure data migration and regular updates
• Training: Upskilling your teams on PostgreSQL best practices

Contact us today for a free consultation and learn how you can use PostgreSQL optimally and securely in your company.

Transparency notice:

Oracle® and MySQL® are trademarks of Oracle Corp. MongoDB® is a trademark of MongoDB Inc. PostgreSQL® is a trademark of the PostgreSQL Association, Canada. The mention of these trademarks is solely for the factual description of migration scenarios and services provided by credativ GmbH. There is no business relationship with the trademark owners mentioned with regard to the products referenced.

Open source software differs from proprietary software primarily in the availability of the source code and the licensing. With open source, the source code is freely accessible and can be viewed, modified, and distributed by users. Proprietary software, on the other hand, is distributed with closed source code that belongs exclusively to the manufacturer. These fundamental differences influence costs, flexibility, support, and strategic decisions in companies. In this article, I would like to attempt a comparison of open source software vs. proprietary software.

Many companies use open-source software without knowing what rights and obligations the respective license—whether GPL, MIT, or Apache—actually entails. Understanding open-source licenses is not purely a legal task, but a strategic prerequisite for any company that develops or deploys software. This guide explains the three most important open-source licenses in comparison and provides you with a practical decision-making foundation for your project.

Note: This article reflects the author’s professional assessment and does not constitute legal advice. For legal advice on licensing matters, please consult an attorney.

What are open source licenses and why are they important?

Open source licenses are legal agreements that define the terms under which software may be freely used, copied, modified, and distributed. They create legal certainty for developers and users by defining clear rules for dealing with the source code. Without these licenses, the use of third-party software would be legally problematic.

The legal significance of open source licenses is immense: they replace the standard copyright, which prohibits any use, with specific permissions. Companies need to understand these licenses, as violations can lead to costly litigation. The internationally recognized reference is the Open Source Initiative (OSI), a nonprofit organization that reviews and certifies licenses based on the Open Source Definition. OSI-certified licenses—including GPL, MIT, and Apache—meet defined minimum requirements for freedom of use, distribution, and source code access. For enterprises, the OSI certification is a reliable signal that a license is legally proven and accepted in the community.

Open source licenses can be divided into two main categories:

• Copyleft licenses (such as the GPL): require changes to be published under the same license
• Permissive licenses (such as MIT, Apache): allow integration into proprietary software without publication obligation

This distinction significantly influences your business strategy and product development. Copyleft licenses promote community development but can restrict commercial models. In the context of copyleft licenses, the term “infectious” conditions is often used, not with a negative connotation, but simply to indicate that by using copyleft-licensed code, derivative works are generally also subject to the same license. A distinction is made between strong copyleft (GPL), limited copyleft (LGPL), and file-based copyleft (MPL). Permissive licenses offer more flexibility for companies that want to develop proprietary solutions.

Important for enterprises: The copyleft effect of the GPL only applies when you distribute the software to third parties. If you use GPL-licensed software exclusively internally, without distributing it, there is no obligation to publish the source code.

What is the difference between GPL, MIT, and Apache licenses?

The open-source license comparison between GPL, MIT, and Apache is the first step for many companies in understanding open-source licenses and their practical implications. The GPL license is a strict copyleft license that requires all modifications and derivative works to also be under the GPL. MIT and Apache are permissive licenses that offer more freedoms, with Apache containing additional patent protection. The choice between these licenses determines how you can use the software in your projects.

GPL (General Public License) protects the freedom of software through the copyleft principle. If you use and distribute GPL-licensed software, you must:

• provide or make available the source code
• also place your changes under the GPL
• clearly identify the license terms

The MIT license is the simplest permissive license. It allows virtually anything as long as you:

• retain the original copyright notice
• include the license terms in copies of the software

The Apache license is similar to the MIT license, but also offers:

• explicit patent protection for users
• protection against trademark infringement
• clearer rules for contributions to the software

Practical examples of use: Use the GPL for community projects that should remain open. The MIT license is suitable for libraries that are to be widely distributed. The Apache license is ideal for corporate projects where patent protection is important.

Which license should you choose for your project?

The right open-source license choice depends on your business model, project goals, and desired community participation. Those who want to understand open-source licenses and select the appropriate open-source license should first examine what goals the project pursues and what dependencies already exist. Choose the GPL for maximum openness, the MIT license for maximum distribution, and the Apache license for enterprise projects with patent protection. Also consider the licenses of the software components you already use.

For community-driven projects, the GPL is suitable because it ensures that all improvements benefit the community. This choice encourages contributions from other developers and prevents companies from using your work without compensation.

For libraries and tools, the MIT license is often the best choice. The low legal hurdle leads to higher adoption and more feedback. Many successful JavaScript libraries use the MIT license for this reason.

For enterprise software, the Apache license offers the best balance between openness and legal certainty. Patent protection prevents legal problems and makes the project more attractive to other companies.

Important decision factors:

• Do you want to allow commercial use without an obligation to return?
• Is patent protection relevant to your project?
• What licenses do your dependencies use?
• How important is maximum distribution compared to community control?

Which licenses can be combined with each other?

MIT and Apache-2.0 are permissive licenses and can generally be combined with many other licenses without any problems. Code under MIT can be integrated into GPLv2 or GPLv3. Apache-2.0 is compatible with GPLv3, but not with GPLv2, as GPLv2 does not accept the Apache-2.0 patent clause. GPL licenses are copyleft, meaning that as soon as GPL code is combined, the entirety must be distributed under GPL. GPLv2 and GPLv3 are not mutually compatible, unless a project uses the “v2 or later” option.

Crosstab: Compatibility / Combinability

Overview

Here is a summary of the three major open-source license models:

GPLv2 vs. GPLv3: Why the Version of Your GPL License Matters

GPL Version 2 and GPL Version 3 both pursue the goal of ensuring software freedom, but differ in several key aspects. GPLv3, released in 2007, addresses technical and legal developments that were not yet considered in GPLv2 from 1991. An important difference is the handling of Tivoization: Manufacturers provide the source code, but technically prevent users from running modified versions. A classic example is a digital video recorder (such as the namesake TiVo) that uses GPL software but only accepts firmware signed by the manufacturer. Users can view and modify the code, but cannot install their changes on the device – a clear contradiction to the spirit of the GPL. The GPLv3 explicitly prevents this.

In addition, GPLv3 strengthens protection against software patents, improves license compatibility, and takes greater account of international legal spaces. Overall, it expands the freedom of use, while GPLv2 is considered more stable but less comprehensive.

Special cases

The AGPL dilemma: Protection vs. ecosystem

Switching to the Affero GNU Public License (AGPL) or even to specific “Source Available” licenses—as can be observed in prominent examples such as MongoDB (SSPL) or Elasticsearch (ELv2)—seems tempting at first glance in order to protect one’s own business model against commercial use by large cloud providers. In practice, however, this path often proves risky: such licenses frequently lead to legal uncertainty for corporate customers, a fragmentation of the developer community, and the loss of official “Open Source” status according to the OSI definition. Instead of sustainably protecting the project, there is a risk of undermining precisely the collaborative dynamics and trust that made the software’s original success possible in the first place. In fact, we are seeing a blanket rejection of such licenses, especially among large companies. In particular, the AGPL is very often found on a blacklist.

LGPL – Lesser GPL

The Lesser General Public License (LGPL) was also developed by the Free Software Foundation (FSF). The LGPL allows developers or companies to incorporate software under LGPL into their own projects without being forced to disclose their source code as a whole due to a so-called strong copyleft. However, end users must be able to change the LGPL-licensed code, which is why this code in proprietary software is usually outsourced to dynamic libraries that can also be replaced when the program as a whole is only available in binary code. The license represents a compromise between the various strict copyleft licenses such as GPLv2 or v3 on the one hand and permissive licenses such as MIT or BSD licenses on the other.

BSD and Mozilla Public License: Additional Relevant License Types at a Glance

In addition to GPL, MIT, and Apache, there are other open-source licenses that are regularly encountered in practice. In particular, the BSD license and the Mozilla Public License (MPL) are widely used in certain project contexts and deserve separate consideration. A basic understanding of these license types helps you correctly assess dependencies in your projects and make licensing decisions more confidently.

BSD License: The Permissive License for System-Level Software and Maximum Freedom

The BSD license is one of the oldest permissive open-source licenses and imposes even fewer requirements than the MIT license. It originated in the Berkeley Software Distribution, a Unix derivative from the University of California, and is now primarily used in two variants: BSD-2-Clause and BSD-3-Clause. Both variants require only the retention of the copyright notice and a disclaimer of liability; BSD-3-Clause additionally prohibits the use of the original developers’ names for advertising purposes without express permission.

Typical use cases for the BSD license are operating system components, network software, and Unix-like systems—many parts of BSD-based operating systems such as FreeBSD or OpenBSD are under this license. In terms of compatibility, the BSD license behaves similarly to MIT: BSD-licensed code can be integrated into GPLv2 and GPLv3 projects without any problems and combined with Apache-2.0.

Mozilla Public License (MPL): File-Based Copyleft as a Middle Ground

The Mozilla Public License 2.0 offers a middle ground between permissive licenses and strong copyleft: only the files that contain MPL-licensed code must be kept under the MPL—the rest of your project can be under a different license, including proprietary licenses. This concept of file-based copyleft makes the MPL particularly attractive for companies that want to contribute individual components to the open-source community without having to disclose their entire product.

Well-known projects under the MPL are Mozilla Firefox® and parts of LibreOffice®. As for compatibility, MPL 2.0 is explicitly compatible with GPLv2, GPLv3, and Apache-2.0, provided the respective files are correctly marked. For projects that want to incorporate MPL-licensed code, however, it should be noted that the disclosure obligation at the file level must be consistently observed.

Does an open-source license contradict every business model?

The clear answer is “No!” Open-source software and commercial business models are not mutually exclusive—on the contrary, thousands of successful projects show that open source code and economic success are very compatible. Which model fits best depends on your goals, your target audience, and the chosen license.

SaaS Model: Open-Source Development with Commercial Hosting

In the SaaS model, software development takes place entirely under an open-source license, while a commercial provider offers the software as a hosted service. Users benefit from the transparency of the open source code, but pay for hosting, maintenance, and support. A very well-known example is the blogging software WordPress®: the source code is freely available at https://wordpress.org/, while https://wordpress.com/ offers hosting and paid additional services such as cloud storage and backups. The advantage lies in broad community participation; the disadvantage is that competitors can also host the software.

Dual Licensing: Free and Commercial License in Parallel

In the dual licensing model, the same software is offered simultaneously under a free open-source license and a commercial license. Companies that want to use the software in proprietary products can purchase a commercial license that includes additional guarantees or extended usage rights. This model makes it possible to serve the open-source community while generating revenue from the commercial segment. The disadvantage is that managing two license tracks creates organizational overhead.

Open-Core Model: Community Edition and Full Version

The open-core model provides a community edition under an open-source license, while an extended “full version” with additional features is offered commercially and proprietary. In the community, this model is less popular, as it often results in only a small developer community voluntarily contributing to further development—the incentive to contribute to a project whose core features are commercially withheld is naturally lower. For providers, however, the model offers a clear monetization strategy.

Service and Consulting Model: Expertise Around Open-Source Software

In addition to product-based models, there is the option to sell services and consulting around open-source software. The software used remains completely open source, while companies pay for design, implementation, operation, and support. This is exactly the approach we take at credativ®: we advise clients for a fee on how they can implement their infrastructure with open-source software and support them in ongoing operations—consistently relying on pure open-source solutions.

But isn’t open-source software always free?

No, open-source licenses do not prevent the commercial distribution of software. However, they sometimes force the source code to be published, which may promote competitive products, but it is not necessarily free. Richard Stallman once formulated this as “Free as in free speech, not free beer.” In addition, a TCO analysis always includes costs for conception, rollout, and operation. These are just as present with proprietary software. However, open source offers the advantage that you get a high degree of independence with the source code, which means that you are not in a vendor lock-in trap if the provider massively increases prices.

What about software without license information?

Software without explicit license information is legally fully protected in most legal systems (“all rights reserved”). This means that users may neither use, copy, modify nor pass on the code, even if it is publicly accessible, for example on GitHub. An explicit license is therefore always necessary for permitted use.

Anyone who consciously wants to make software public domain can do this via CC0 (Creative Commons Zero). CC0 waives copyright claims – as far as legally possible – and enables almost unrestricted use without conditions.

It is important to distinguish between Open Source / FOSS and Public Domain: Open Source does not mean “free of rights”, but describes licensed software that grants certain freedoms of use (e.g. MIT, Apache, GPL). The Public Domain, on the other hand, is actually free of copyrights, either through the expiry of the protection period or through explicit waiver as with CC0.

What happens if you misuse open source licenses?

License violations can lead to costly litigation, claims for damages, and the obligation to publish your own source code. Common mistakes include ignoring copyleft provisions, missing license notices, and using incompatible licenses in a project. Preventive measures such as license audits protect against legal problems. There are also specialized service providers and software offerings that take over the analysis of the code used.

Legal consequences of license violations are diverse:

• Cease and desist orders that can stop your software distribution
• Claims for damages for lost license fees
• Obligation to subsequently publish the source code
• Attorney and court costs

Common mistakes in practice arise from a lack of awareness:

• GPL software in proprietary products without source code publication
• Removal or modification of copyright notices
• Mixing incompatible licenses without considering the implications
• lack of documentation of used open source components

Companies can protect themselves by conducting regular license audits, training developers, and using tools for automatic license detection. A clear guideline for the use of open source software helps to avoid problems from the outset.

Various software tools are also available for license audits, some of which are offered commercially or as SaaS. But of course, there are also various open-source tools that support you in the license audit. As an example, we would like to mention the following here:

• FOSSology – an open-source license compliance system that already supports code scanners during the development stage to avoid introducing unwanted license combinations.
• AboutCode ScanCode describes itself as an industry-leading SCA code scanner and can also be integrated into build pipelines for automatic code scanning.
• license checker is particularly exciting for web or web-related developers, as it fits seamlessly into the npm / npx universe.

Of course, the list does not claim to be complete and, as always, can change again and again in the open-source environment.

License Compliance in Daily Business Operations: Processes and Responsibilities

License compliance is not a one-time task, but an ongoing process that must be organizationally anchored. Many companies only react to license violations when legal consequences are imminent—yet most risks can be significantly reduced through proactive measures. Establishing structured compliance processes not only protects against legal problems, but also creates internal clarity about which open-source components are in use and under what conditions they may be used.

The following measures form the foundation of a robust open-source compliance program:

• Establish an open-source policy: Define internally which licenses are allowed, restricted, or completely prohibited in your projects. Such a policy provides developers with clear guidance and prevents problematic licenses from entering your codebase unnoticed.
• Introduce Software Composition Analysis (SCA): Integrate automated SCA tools into your development cycle to continuously capture open-source components used and their licenses and check for compatibility. Tools such as FOSSology or ScanCode can be integrated directly into build pipelines.
• Train developers regularly: License obligations are unfamiliar territory for many developers. Regular training ensures that your team knows the basics and acts in compliance with licenses in daily project work.
• Clearly assign responsibilities: Designate a responsible person or role—such as an Open Source Officer or compliance manager—who maintains an overview of the licenses used and serves as a point of contact for license questions.

Building such structures requires experience and a deep understanding of the open-source license landscape. This is exactly where we support you at credativ®—from developing a tailored open-source policy to implementing appropriate compliance processes in your company.

How credativ® helps with open source licensing issues

We support companies in the practical use of open source software through comprehensive consulting and practical implementation assistance. Our team of Linux specialists and open source experts knows many pitfalls and helps you avoid them while making the most of the benefits of free software.

With over 20 years of experience in the open source field, we understand both the technical and legal challenges. We help you to use open source software safely and effectively in your IT infrastructure without taking legal risks. Our comprehensive services cover all aspects of open source consulting.

Contact us for a non-binding consultation on your open source deployment. Together, we will develop a strategy that harnesses the innovative power of open source software for your company.