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

rigoletto@

rigoletto@

Developer
The objective of the 'Dæmon License' is to create a license completely and clearly incompatible, directly and indirectly, with the COPYLEFT philosophy.

Beyond personal convictions, a possible use would be for the corporation XYZ willing to open some random code to be improved community-wise but they are afraid of doing it because someone could fork this code, stamp a GPLvX in there (what I call code smuggling) for the all new code, and somehow the majority of the contributions end up on this fork instead of the original code.

The thing could then end up as an awesome code which the XYZ corporation will not be able to benefit of it because they cannot import GPLvX code in their base for some reason.

They have the option to order a custom license, but they have to deal with the risk of that be circumvented due to something not being well written/implemented, or while they are willing to open the code they are not interested on spending money with bureaucracy to do that (specially thinking about medium/small business).

The main reason I didn't write it yet are:
  1. my lack of proper knowledge of the subject (law-wise)
  2. lack of proper English grammar knowledge
  3. I do not have any code to publish
Everybody know the COPYLEFT philosophy and objectives. I personally do not think the main objective of the copyleft licenses is the code freedom but third party code appropriation: anything that directly integrates or directly links to substantial portions of GPL software becomes GPL.

Several people, each one with its own reasons, does support free software but are against the COPYLEFT practices, but the available licenses do not provide protection to those people code to avoid its code be used on copyleft projects, something they do not support or are against of. Evidently, again, I am talking about individuals and small business who can't afford specialized lawyers to write a custom license for them.

The idea is to start with a BSD3CLAUSE BSD2CLAUSE license and add two others clauses with these objectives:
  1. make it "crystal clear" copyleft incompatible, directly and indirectly, not allowing the use of custom licenses between (think LGPL) to workaround the 'Dæmon License'
  2. a counter-measure clause against license violation, a builtin punishment
  3. eventually an exception for code that will never be published, but just for internal consumption
Just making it clearly incompatible was supposed to be enough, but everybody know GPL licensed projects are often violated and the code owner does not have means to fight against that violation due to high costs. Too bad for them to embrace a bi-polar licensing model they cannot afford.

The idea of the license is simple: do not get any of this code involved with COPYLEFT in anyway, but if you do insist there is the retro-viral medicine.

One time the Dæmon licensed code is violated the medicine is automatically applied, what means all involved copyleft code become 'Dæmon Licensed' as punishment for the violator. And so the owner of the violated code can publish (or use, doesn't matter) all copyleft affected code under the 'Dæmon License'.

If I give something for free, I GIVE, but at the same time I do not want it to potentially become part of a practice I am against of, even if indirectly, specially if it is predicable to happen.

I am not implying everyone should support this kind of licensing, anyone can publish anything with any license they desire, but to attract people who is willing to HELP. Reddit-like comments are not welcome, as we do not need more noise than we already have on this forum.
 
Last edited:
I don't think 3'rd parties can re-license the code, only the original author(s). The BSD license calls for distribution of the conditions paragraph, which is as it is (very liberal), and is a not a GPL license paragraph. OTOH, IANAL ...
 
Third parties cannot re-license the software (unless the license allow it), I was talking about the 'marketing' thing they do.

Ex. get a BSD code and put one line of code (and preferecially change the name of everything involved), then add it to GitHub with a GPLv3 License because all code from now will be GPLv3. Later add the necessary BSD disclaimer very hidden somewhere in the repository and never talk about it. Next step, tell to everyone how your code is marvelous.

This is the same people do on proprietary software but those don't try to sell their code is free. I do not agree copyleft software is free software since it force you to comply with their philosophy. It is even worse than proprietary (IMO).

The objective of GPL is to appropriate of third party software[1]. If someone make a mistake[2] while implementing something that include third party GPL software, it can potentially afect all involved code forcing everything to become GPL licensed.

[1] if you want your code to be free you just need keep it free. Nobody (usually) can for you to re-license your software.
[2] you can search around the forums for some serious 'real world' concerns ralphbsz brought from business when GPL code get involved.
 
Who cares though?

That so called "anti viral clause" you speak off reminds me of the sole reason I dislike the GPL: it limits one freedom because it demands that all work based on the Original should also be licensed under the GPL. Which is why many compare the GPL with a virus due to its intended spreading.

The whole idea behind the BSD license is to provide a true form of freedom. And yes, that also means that this can be (ab?)used in ways the OP describes. Yet I don't see a problem. Anyone who knows their stuff can poke right through stuff like this.

Still, in the end things work as intended: people gain access to open source and the freedom to use that as they please (to certain extends).
 
Are you aware of the BSD 3-Clause Clear License license? Oddly, if the license is made to keep another entity from taking it over, it becomes a little more like a GPL license, unless you use an Apache license, which is very complicated. (I'm unsure where CDDL is on the spectrum).

The original license cannot be changed, only their additions to it. It is important to save the code that have original licenses, before additions get added to it.

I don't like how something is under a FreeBSD license, then it seems like it gets absorbed in a predatory kind of way. Then it becomes something that GNU fans take credit for. There was a newer BSD license, that was incompatible with GPL licenses of that time. Then GPL 3? license was made, which was able to absorb code from that later BSD license.

Other than something like a ClearBSD or Apache type of license, I don't know what else can be done without breaking the tradition of free to use for all.

I think when code is started from a liberal license like MIT, ISCL or BSD, completion of it has to be vigilant, so that any more incorporation cannot be much more useful than the original code. An author can also hold on to it, then release it later to one of these licenses. Some from other opensource projects who use code from one of these licenses, seem to have no interest in doing this.

There has to be some understanding of copyright that is helpful. Of course different countries and institutions have different rules of copyright law.

An "ad Minimus" addition to a BSD code is not a creative expression enough to prevent putting a GPL or copyright stamp on it. GPL can use it, but they cannot use the ad Minimus additions exclusively. An ad Minimus addition would be like adding the words "an", "the" or punctuation; then they cannot prevent a BSD entity, any other person or organization from incorporating that to the original code under the BSD style license. In other words, any addition that is ad Minimus would belong to the original BSD, MIT, ISCL style of license. It may be abstract or up to opinion what constitutes ad Minimus.

It is also in copyright law, that I read, but I'm not sure if this is all encompassing, that machine generated code cannot be copyrighted, because it is not of original creative expression. I'm unsure if it can always be proven if code is machine generated. Lists and tables cannot be copyrighted, despite that it may take days, weeks, months or years of work to accomplish attainment of that knowledge. If a table is styled with artwork, then that can be copyrighted, or trademarked or something like that.
 
I believe an interesting example of what the OP is talking about is OpenOffice.

From a distance it seems quite sad seeing it being trampled on by LibreOffice from the fact that LibreOffice can take patches from OpenOffice (Apache, MIT) and yet OpenOffice cannot take patches from LibreOffice (GPLvX).

But at the same time, as a consumer, this does not affect me. I was also never going to attempt to repackage and resell OpenOffice, so professionally it does not affect me either. And many of the OpenOffice developers are quite happily working on LibreOffice so it doesn't really affect them either. On a closer inspection, noone has really been hurt by this system.

In my personal opinion, there is a need for both GPL and fully permissive licenses. There is also no real harm in allowing BSD/MIT licenses being affected by the GPL viral effect either because that is still a much better prospect than a company simply closing up the source entirely (which remember they can do with BSD/MIT).
 
sidetone said:
I don't like how something is under a FreeBSD license, then it seems like it gets absorbed in a predatory kind of way.
Click to expand...

The exactly same thing happens with GPL, and most of time they can't do anything because of the lack of resources. So, they usually only have means to enforce on individuals or small business (and when they have), what is an ever bigger joke than what they talk about BSD/MIT.
 
lebarondemerde said:
CDDL was created to be GPL incompatible (it is well know Solaris engineers didn't want ZFS on Linux), but the thing was not well implemented.
Click to expand...

Personally I don't think so; my opinion is that the rumor about Sun developers willing to purposely damage Linux and FSF is more of a bashing trend spread by GPL-fanatics, bothered by someone going copyleft -while re-implementing the whole concept in a saner way- and actually not using their beloved license (alias postmodernist phylosophy), and based on an immotivated assertion from the OpenSolaris dev Danese Cooper at 2006 DebConf, which was
promptly proved wrong by Simon Phipps. In 2015 Bryan Cantrill (who, no secret, I'm fan of) when asked: "Was the CDDL designed to prevent Sun technologies from entering Linux?", answers:
Great question, and the answer was that we didn't know -- but the expectation was that it would be ported to Linux relatively quickly. I remember vividly standing over a terminal with a bunch of people as we actually launched OpenSolaris (like, clicked carriage return on making the DTrace code live -- which was the first in the chute), and the Sun Legal guy and I were chatting. We were both wondering if DTrace was going to show up in Linux in a month or if it would take two years. But that was the range of guesses: neither of us believed that the Linux community themselves would hold up CDDL as an obstacle, and certainly if you told me that a decade later, DTrace wouldn't be in Linux because of licensing FUD, I wouldn't have believed you. Of course, in hindsight, it all seems so clear: NIH is enormously powerful, and we were fools for discounting it. After all, as Jared Diamond pointed out in "Collapse", the Norse in Greenland starved to death when their domesticated livestock died rather than eat fish like heathens...
Click to expand...
 
I think a solution is to use a combination of an open BSD, ISCL, MIT license, with clearly marked components that are exclusively BSD3 Clear license. So they can absorb parts of it, but for parts incompatible with the GPL license, they will completely have to rewrite, or plug it into their GPL code to make use of the free code. Either that, or have publishers who first hold on to the code, then later release it with a liberal license, once it is functional and near completion.

Considering how cluttered or bloated much of GPL code is, there is a lot of room for improvements with BSD style used with its licenses. If done, it must be done meticulously, before it gets absorbed in a large way. But that is too much to ask.

Apart that in GPL code, there is a tendency to pile on, because people do not want to contribute a lot of effort that they cannot use exclusively, but allow entities who own the copyright to get exclusive use of. When a lot of GPL code is proactively developed, I don't know if by design or by coincidence (I think both) that a lot of GPL code has a tendency to be cluttered. In other words, in GPL style of code, a lot of code is passively piled on, causing clutter, but when code is not passively piled on, it seems to proactively be cluttered. It is like heavy developers are trying to tangle knots.

lebarondemerde said:
The exactly same thing happens with GPL, and most of time they can't do anything because of the lack of resources. So, they usually only have means to enforce on individuals or small business (and when they have), what is an ever bigger joke than what they talk about BSD/MIT.
Click to expand...
Yes, I understand and sympathize with that to an extent. I was kind of describing that. Admittedly, many open source projects lack resources. While GPL can benefit BSD code at times, I don't like how some bash BSD projects, after the GPL code they are praising, was done on top of BSD code.
 
I've added "3. eventually an exception for code that will never be published, but just for internal consumption".

I am logging it in here to avoid EDIT on the original post.
 
There are at least two what I see as successes in MIT, ISCL or BSD styles of source code (aside from what's in the base of BSD OS'es). x11-wm/jwm and audio/sndio. sndio is so different than what is at Linux, that there's little reason yet for them to implement it. jwm used to be GPL, but it was later released to MIT by the author. These can be forked with little consequence, because in terms of functionality (not necessarily in features) they are complete.

Maybe there can be a type of license, that you can do anything with the code, but if you fork it, you cannot do it under the same program name (kind of like how DocBook's license is), but you must attribute the original authors and other important details.


I don't see an excuse for hardware drivers, which the manufacturers made to be open, and made on top of BSD code to be made into a GPL type of license. If they made it from scratch, then they should do it. I wish hardware manufacturers would make it so you can't close off contributions to software to their hardware that are based on top of code that the manufacturers contributed, but you can keep them as a trade secret.
 
Added to OP.
Another unlikely but possible use would be a XYZ corporation willing to open some random code but they don't want it going thru GPL/Linux madness because of some reason (doesn't matter), like they end up in a situation where the code got improved but they now cannot import this code back because the improvements are GPLvX - someone did a fork stamped a GPLvX license in there for all new code and somehow everyone contributed to that fork instead of the original code.

They have the option to order a custom license, but they have to deal with the risk of that be circumvented due to something not being well written/implemented, or while they are willing to open the code they are not too interested on spending money to do that.
 
As long as there are an infinite way to write code to accomplish a specific result. Using the code that's under the original BSD type license, before it was forked, then adding to that should be no problem. I just don't know if there are many ways to complete a piece of code.
 
Yes, but why someone who opened the original code and can't stand to GPL would like assume the risk have to re-write (what cost money) all contributions just because someone (totally not related with them) decided GPLvX IS the way to go. Not to say there still have the discussion of what derivative work is.
 
lebarondemerde said:
Yes, but why someone who opened the original code and can't stand to GPL would like assume the risk have to re-write (what cost money) all contributions just because someone (totally not related with them) decided GPLvX IS the way to go. Not to say there still have the discussion of what derivative work is.
Click to expand...
It all cost someone time or money to make any piece of code. Starting from the BSD licensed code is a good starting point.

I wish I could make big contributions of efficient coding, but I have a lot on my plate at the moment to take on big learning projects on programming.
 
kpedersen said:
I believe an interesting example of what the OP is talking about is OpenOffice.

From a distance it seems quite sad seeing it being trampled on by LibreOffice from the fact that LibreOffice can take patches from OpenOffice (Apache, MIT) and yet OpenOffice cannot take patches from LibreOffice (GPLvX).
Click to expand...

Just FTR: OpenOffice was being gutted and bled to death by oracle (like everything else they've touched...) to develop their renamed variant of StarOffice. The rotten carcass of OpenOffice.org was then thrown over the fence (or "generously donated" in Oracle terms) of the Apache Foundation, which still keeps it on life support for unknown/questionable reasons as it is de facto a stale project. All core developers left OO and joined LibreOffice a long time ago (~2010-2011) and that's where all development has happened since.

As OpenOffice.org was already licensed under GPL, continuing with that license this might have been the only available choice for LibreOffice. Apache re-licensed AOO much later, so the incompatibility with AOO was surely not a goal for LibreOffice.
 
First draft, and actually based on BSD2CLAUSE instead of BSD3CLAUSE. It does not met all requirements yet.

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. Derivative work cannot not be distributed under any form of imposition that derivative work should be distributed under the same or part of the same terms, ever if those terms make exeptions to parts of the work.

4. If derivative work become distributed under terms that impose that derivative work should be distributed under the same or part of the same terms, ever if those terms make exceptions to parts of the work, the aforesaid terms are applied instead.

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...
 
Draft 2

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. Derivative work cannot not be distributed under terms that impose restrictions of how derivative work should be distributed, ever if exceptions are granted to the present work.

4. If derivative work become distributed under terms that impose restrictions of how derivative work should be distributed, ever if exceptions are granted to the present work, the present license is applied instead.

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...
 
OK. I'll bite. I'm not at all fond of the poisonous *GPL* license, and I'm no fan of Stallman. I really appreciate the MIT/BSD license. I guess (in the context of your writings) I'd simply use the MIT/BSD 3 clause, adding simply one more clause:
o The source covered by this license may NOT be re-licensed under any GPL, or derivative license thereof. Nor may any contributions to this source carry the same.
I think that covers it.
After all. Isn't hat really your (and may(s)) beef? :)

--Chris
 
Chris_H said:
OK. I'll bite. I'm not at all fond of the poisonous *GPL* license, and I'm no fan of Stallman. I really appreciate the MIT/BSD license. I guess (in the context of your writings) I'd simply use the MIT/BSD 3 clause, adding simply one more clause:
o The source covered by this license may NOT be re-licensed under any GPL, or derivative license thereof. Nor may any contributions to this source carry the same.
I think that covers it.
Click to expand...
That's one brilliant solution.

The freedom of MIT/BSD licenses getting taken in by restrictive licenses is a paradox.
 
I thought on something like that but would be pretty easy to write a completely new license without any relation with GPL archiving the same effects.

The spefic characteristic of the *GPL* licenses is the term forcing derivative work to be licensed under the same terms, and so I did the first draft. But, it is doable to write a license that does not enforce the "same terms" but manage to archive the same results using different terms (this is moot but doable).

So, a closer look and those licenses are about removing the freedom[1] of the permissive-like licenses imposing restrictions. I do not know any other licenses that impose those kind of restrictions since proprietary does not have derivative work to be distributed.

[1] of course *GPL* cannot re-license a work under BSD/MIT but one time a lot of work is done on top of it, it is often counter productive to re-write the whole thing back to a permissive license - it is like they try hijack the work to impose their political visions.
 
You must log in or register to reply here.
Back
Top