Questions & Answers of the Privative-Friendly Source-Shared License (PFSSL).
The full text of the PFSSL v1.0 can be found here.
Table of Contents
Why the PFSSL?
In today’s world, where cloud computing and online services are becoming essential, the need for libre software tailored for cloud environments is growing. However, traditional open-source and libre-software licenses often lack provisions to ensure that source code will always be made available—especially when integrated with proprietary software and cloud-based services.
The PFSSL was created to address these gaps, ensuring:
- Users are granted the rights to use, modify, and distribute the software freely.
- The code can easily be integrated with proprietary software without forcing private code to be released.
- Users can always obtain the source code, even in cloud environments or when the software is provided as a service.
Additionally, the following key provisions were added to ensure both fairness and transparency:
- Authors and contributors must always be credited, and their names cannot be removed from the project.
- Prevention of misleading or unauthorized use of the software's name, logo, or brand, ensuring fair recognition and avoiding false claims.
The PFSSL offers a balanced approach, making it ideal for modern software development where open collaboration and proprietary integration can coexist seamlessly.
PFSSL Main Constrains
The PFSSL should be applied when you want to ensure that the source code of your project remains available to users, even when integrated into proprietary software or provided as a service. Below are some key elements of the license that you should be aware of:
- Source Code Availability: If you distribute the software, or use it to provide a service, you must provide the source code for the PFSSL-covered files.
- Attribution & Modification: You cannot remove any previous authorship data, and if you modify PFSSL-licensed code, you must include a clear modification notice in the modified files, including the year and the name of the author of the changes.
- Responsible Reuse: If you make major changes to the software, you must add a notice, change the name of the software, add a suffix, or implement any visible method to warn users that it is not the original software. Additionally, you cannot use the names or brand of the original authors to promote your modified version.
These are some key elements, but for full understanding and compliance, please refer to the full text of the PFSSL. It is important to read and understand all terms of the license when applying it to your project.
Compatibility With Other Licenses
Permissive Licenses (Public Domain, CC0, MIT, MPL2)
Permissive licenses, such as Public Domain, CC0, MIT, and MPL2, can be integrated into a PFSSL-licensed project. If the global license of the project is PFSSL, then the whole source code must be made available under PFSSL terms, and PFSSL’s trademark and attribution requirements will also apply to the entire project.
GNU Lesser General Public License (LGPL)
The LGPL is not compatible with the PFSSL for the following key reasons:
- Privative Software Integration: PFSSL allows a more friendly approach to integrating with privative software, enabling it to be used alongside privative code without requiring the release of the entire software. This makes it easier for developers to use PFSSL in commercial or private projects while maintaining control over their proprietary code.
- Source Code Disclosure: PFSSL ensures that the source code for PFSSL-covered files is always made available, including in cloud environments or SaaS applications, which the LGPL fails to do.
GNU General Public License (GPL)
The GPL is not compatible with the PFSSL because GPL-licensed code cannot be merged with privative code.
If you are looking for a GPL license that guarantees freedom in cloud usage, consider using the Affero GPL instead.