'Dæmon License': an anti-viral license.

How about a license with one part that applies to propriety additions, and another part that applies to GPL like licenses.

Clear BSD, Apache and maybe CDDL licenses apply to propriety use of code. Clear BSD is simple, so use that. Make it compatible with Apache, CDDL, Mozilla and similar licenses. Prevent companies from trolling copyrights and patents with this part.

Add a clause to Clear BSD license that says, it can't be used with a open-source license that forces people to give up their code, as what GPL does.

This makes the most sense. To remain simple and functional, it needs two parts: one to apply to proprietary use and one to apply to open-source use.

Also, maybe something borrowed from LGPL, that allows more leniency on linked libraries under this license. This will allow proprietary code to be used in any way they want without getting it mixed in with this licensed software. This will also allow a GPL-like piece of code to be stripped down to the library (obviously remaining under those terms), and linked to from this (that is allowed to do so) without getting software from different licenses clouded up.
 
I think the correct definition (clause) is something like: "This software cannot be linked statically with any software module or library licensed under GPLv2, GPLv3 or future modification of GPL. GPL is GNU General Public License defined and maintained by Free Software Foundation, Inc.". Maybe it is good to include LGPL as well. Dynamic linking is allowed.
 
6502 said:
I think the correct definition is something like: "This software cannot be linked statically with any software module or library licensed under GPLv2, GPLv3 or future modification of GPL.
Click to expand...

I like the idea but what if you still want it to be able to function alongside and with GPL software, but not for the viral effect to spread?
 
I think dynamic linking may help in many cases. The idea is not for upgrade of BSD license but making new type of sub-license which is protected against GPL forks.
 
kpedersen said:
Can something more restrictive in terms of license compatibility be used?

"This software may not be relicensed"

"This license is final and is not compatible with any other license"
Click to expand...
That's a good point, but then it more resembles CDDL.
I am not sure of rigoletto@'s motivation, but I would assume licensing in some other form, say MIT, would be ok because it preserves the 'spirit' of the BSD license, whereas GPL does not because of its derived works nonsense.
 
I found this...

Given that the inclusion of a few lines of "GPL-tainted" work into a larger body of work will result in restricted distribution -- and given that further work will likely build upon the "tainted" portions, making them difficult to remove at a future date -- there are inevitable circumstances where authors would, in order to protect their goal of providing for the widespread usage of their work, wish to guard against such "GPL-taint".
Click to expand...

It's from 2002.
 
mark_j said:
I read it, I read it again and I read it again. I just cannot see where it protects against gpl-isation.
Can you?
Click to expand...

Clause 4 applies to open licenses.
4. Modification and redistribution under open license.
Click to expand...
Keeping clear distinction of BSD code from code by other open source licenses.
clearly indicate the nature and date of any changes made to the Program.
Click to expand...
The following, open source code derived with code from this license can't used in a dual manner that restricts access.
cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License
Click to expand...
For instance, when a company duel licenses a code, where they are allowed to absorb others contributions, while they get to keep their contributions out of the opensource licensed code.
 
I was looking into licenses; Thread mozilla-public-license-2-0-mpl-about.85010 is some look into it.

Apache License 2.0 and Mozilla Public License 2.0 must indicate code licensed by these separate from other licensed code. Forget BSD Clear as it's obsolete and doesn't have patent use rights. Apache License 2.0 and MPL 2.0 allow patent rights, and are heavy enough to back their licenses. MPL 2.0 requires that its license code be kept together in the same file(s). If it's allowed, these would be good licenses to use together, while allowing the code to remain with these respective licenses. These are by definition non-viral licenses, as they only determine use by other code and not what they do with it. MPL 2.0 only requires files of its license to be MPL 2.0. Apache License 2.0 is incompatible with GPL2 and LGPL2.

If you really wanted to stop code from being used with any GPL code, a simple provision can be added, code under this license cannot be used with code (of a viral license) that forces any code not a part of it to be given up to its license (with the exception of multi-licensed code).

I wouldn't need this, I'm good with Apache License 2.0 and MPL 2.0. In fact, I would want to be able to have compatibility with LGPL dependencies, until those are replaced with code that uses a better license. For common dependencies, BSD licenses are good too.


Update: the terms aren't exactly clear to me, however, the author of MPL 2.0 code can choose to opt in or opt out use with (L)GPL code. Previous MPL versions, when updating to MPL 2.0 require authors' permissions to opt in to (L)GPL. Ironically, some of this useful information comes from a project which the topic of this thread is about avoiding main licenses it uses.

In the Mozilla License FAQ, wording on Apache 2.0 and MPL 2.0 use together is unclear, but it appears these two can be used together. Unsure if this has to be about the section pertaining to a larger work, or if they can be used together as is, each keeping their separation of code and of their respective license. Since each of these two licenses don't restrict use of code (including proprietary code) beyond their own boundaries as long as it adheres to the respective licenses, it looks like can be used together, as long as they keep their separations. (L)GPL restricts code beyond its boundaries, so it needs the clause on larger works for MPL 2.0.

For a common dependency, I would rather use a BSD licensed or other type of license that allows me to be compatible with (L)GPL while not have to dual license to it. Apache is compatible with (L)GPL3, but not (L)GPL2. GNU considers Apache License 2.0 a good license, it's that the GPL2 was in existence before Apache 2.0. Then, (L)GPL3 addressed some compatibility concerns with Apache License 2.0. If Apache License allows enough compatibility with (L)GPL3, maybe that, because of its patent protections.
 
6502 said:
Click to expand...
Interesting, so adding the following:

"This Source Code Form is “Incompatible With Secondary Licenses”, as defined by the Mozilla Public License, v. 2.0."
Click to expand...

Would seem to do it? I wonder if that can be done to MIT or BSD?

It is useful to know because I occasionally come across projects where someone has added one or two changes to a project (i.e to make it build on Linux) and then relicensed the entire project to GPL because their tiny additions. Whilst they *are* welcome to do so, I feel this is a little bad taste (i.e here).

Original OpenBSD's source code is under the same license as it was. My changes
(the portable bits) are under GPL-2.0-only. That makes the final program
licensed under GPL-2.0-only.
Click to expand...
 
bakul said:
IMHO the whole point of the BSD license is to not worry about such things. It is a "non-judgmental" license :)
Click to expand...
Yeah, to be fair you aren't wrong.

Part of me really wants to ensure that the "non-judgmental" license is passed further down the chain so my user's, user is guaranteed to also benefit from an absolutely permissive license but to be honest that would end up making me a control freak like a lot of the GPL fanatics.

Life is too short to worry about these little tricks.
 
"Those are my principles, and if you don't like them... well, I have others."

docs.freebsd.org

Chapter 1. Introduction

This chapter covers various aspects of the FreeBSD Project, such as its history, goals, development model, and so on
docs.freebsd.org docs.freebsd.org

1.3.2. FreeBSD Project Goals​

The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support.
That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software we do, however, prefer software submitted under the more relaxed BSD license when it is a reasonable option to do so.
Click to expand...
There are two types of users:
- Those who are here because they like Unix.
- Those who are here because they hate Windows and systemd.
No one is here for the license, essentially.
 
6502 said:
“The only thing necessary for the triumph of evil is for good men to do nothing.”
Click to expand...
Perhaps applying the label of “evil” to something one disagrees with is the cause of many problems?
The FreeBSD Daemon does not demonize anyone!
 
kpedersen said:
It is useful to know because I occasionally come across projects where someone has added one or two changes to a project (i.e to make it build on Linux) and then relicensed the entire project to GPL because their tiny additions. Whilst they *are* welcome to do so, I feel this is a little bad taste (i.e here).
Click to expand...
That's just like, his opinion, man. Yeah, I've run into that "fork" of acme-client. I wish there was a version of acme-client that ran on Freebsd. The Python and shell alternatives give me the heebie-jeebies.
 
Proposal for a directory level license, that puts everything under it under its terms, while allowing freedom for it to be used with other software, keeping the license terms clearly separate. Started with a BSD3 clause license, added condition 4, and patent protection that's of the Apache 2.0 License as condition 5. The difference between BSD 2 clause and 3 clause licenses are condition 3 below.
Copyright <YEAR> <COPYRIGHT HOLDER>

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

4. Contributions or modifications under this top level directory remain under this license, with the exception of the "altlicense" subdirectory, with folders below it ideally of under those licenses' names. The "altlicense" subdirectory is intented to make this software compatible with other works that are dedicated to those licenses, while keeping license terms of code clearly separate. This software can be used with any other licensed software that permits it, without this license otherwise affecting software outside of this directory.

5. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Click to expand...
If there's a way to make the patent grant compatible with patent grants of other licenses. It may be possible, but difficult to do. While Apache 2.0 license is permissible, it does have restrictions because of minor variations of the patent clause with other licenses with a patent clause.

This patent clause from MPL 2.0 may be better, while lacking compatibility with Apache 2.0's patent clause:
If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate.
Click to expand...
It wouldn't prevent the licenses from working together from their respective separate places. The better terms may be better than incorporating different patent terms.

The license would be intended to absorb permissive licensed code within it, that doesn't have a patent clause, in terms of keeping it preserved and clearly marked from viral licenses and more restrictive ones. Also, the license is intended to be non-viral, while if possible allowing use if a viral license accepts use alongside code under this license.
 
Man... looking at this licensing fight from the sidelines, I'm thinking that 'Licensing' as a whole is nothing more than a mechanism to try and take control of the coding talent out there.

Let's take the LibreOffice example from earlier in this thread. That project does have a talented dev team and a pretty big crowd of users. I will contrast that against Microsoft's Office - it also has a talented dev team and pretty big crowd of users. The big difference between the two, the game-changer is frankly the money. Yes, Microsoft's stuff costs money. But in exchange, it's got well-compensated talent, an enforcement structure, and it can make quality guarantees to the customers. Licenses are nothing more than a way to track the installed base and actually deliver on the quality guarantee. Because the license seat was paid for, MS is actually under some legal obligation to deliver on the quality guarantee - an obligation that LibreOffice did not take on by virtue of being free as in free beer.

This begs the question, "Why is LibreOffice making an effort to compete with MS Office on features and quality anyway?". And the answer is (IMHO): Because there's enough users who don't want to pay for Microsoft's product, and are willing to put up with bugs and other imperfections. There's a fine balance, though - if LibreOffice was too buggy to be usable, that would drive the users to either buy MS Office or learn to program and fix the bugs. If LibreOffice were facing the problem of a shrinking user base (due to being too buggy to be usable), then closing shop would be a logical move. But trying to actually sustain a quality project - that brings a different set of considerations to the foreground.

With LibreOffice being free as in free beer, there's no money to be made, which makes for a pretty strong economic incentive to sell the dev skills to Microsoft. This scenario assumes, of course that coding talent is a pool that both Microsoft and LibreOffice draw from. And there's benefits and pitfalls for going to either camp. Licenses offer a structural/enforcement framework to the situation. Yes, unfortunately, they can be used as a bullying tactic.

I'm frankly of the same opinion as ShelLuser on this... Ppl who know how to code and compile - they will do it anyway, just to make their own lives a bit easier.
 
kpedersen said:
It is useful to know because I occasionally come across projects where someone has added one or two changes to a project (i.e to make it build on Linux) and then relicensed the entire project to GPL because their tiny additions. Whilst they *are* welcome to do so, I feel this is a little bad taste (i.e here).
Click to expand...

Yeah, I saw that, and also thought it nasty. I was tempted to do my own patchset for acme-client, but when I realised it didn't work for wildcard domains, I went down the python certbot route, using the own-dns server plugin (I've created a port for it, but not got around to submitting it yet) - I find that much cleaner. Just stick it on an IPv6 address, and it starts up its internal server just for creating/renewing certificates. It means no faffing around with the httpd or dns configurations - just run certbot renew from cron with an apache (graceful) restarter:

05 01 * * 4 certbot /usr/local/bin/certbot --quiet --non-interactive --work-dir /usr/native/daemons/certbot/db/ --config-dir /usr/native/daemons/certbot/conf/ --logs-dir /usr/native/daemons/certbot/logs/ --deploy-hook /usr/native/compiled/libexec/certbot-apache-restarter renew

And to create a new domain, i just run 'create-new-cert <domain name> [<domain name>...] and that's it!


Anyway, as for the acme-client patches, I know the licenses allow it, but the "fair" outcome there if he insisted on his patches being GPL would be that he wasn't able to distribute the code with the patches. That's how I would have personally done it. I'm not really a license zealot, but that decision of his felt uncomfortable to me.
 
You must log in or register to reply here.
Back
Top