Please take a step back from the specifics of this license and think about its wider goals, and whether writing a new license helps to achieve them. I suspect it actually doesn't.
Presumably you're aiming for something similar to the copyleft effect of the GPL and AGPL: you want people to improve your software, and you want them to share their modifications with everyone else. However, every time someone considers whether to redistribute your software or whether to invest their time in understanding and modifying it, they need to decide whether the license terms are acceptable to them. When faced with a non-standard license with unclear terms and no community consensus on its consequences, it's quite a rational response to think "I don't have time to think about this" and decide to contribute to something else instead. The same contributor, considering whether to redistribute or improve GPL or LGPL software, will likely think "this is the GPL, I already know about this from Linux" or "this is the LGPL, I already know about this from glibc" and not need to think about it. That's true whether your license terms actually do what you want them to or not - the cognitive load of deciding whether a license is acceptable is a cost in its own right. One risk of contributing to or relying on a project with an unclear license is that the license is too restrictive (e.g. a very strong copyleft) and prevents you from doing something you wanted to. The opposite risk is also present: if some or all of the license turns out to be too unclear to be enforceable in court, then contributors have no recourse if someone takes the project and modifies it in ways that (the unenforceable part of) the license was intended to prevent. We know (because it's happened) that the GPL can be enforced in court; we can be reasonably sure that other standard licenses written with the help of lawyers can also be enforced; but we don't know that about your new license. The more influential and useful a piece of software is, the more willing people are (either as individuals or as representatives of a company) to put up with a pre-existing weird license, but it isn't 1995 any more: there are a lot of open source software projects out there, and the more potential contributors a new software project puts off with a non-standard license, the less likely it is to get that influential. It's also worth considering what would happen if someone violates your license. Assume a large evil company relies on your software in a SaaS situation without sharing their modifications with their users. The AGPL-style restriction in the license can only help you if: their users somehow find out that this has happened, and what the applicable license is; their users tell a copyright holder; and the copyright holder has the resources to successfully sue a large evil company. This seems like a relatively tenuous benefit, compared with the cost of license proliferation. On Wed, 12 Dec 2018 at 00:55:47 +0100, Giacomo Tesio wrote: > If a company violates the Hacking License, the upstream copyright > holders could, since they have received "all permissions and patent > licenses granted to the Users of the Hack, and all rights, title and > interests in any Copyright the Hackers have in the Hack to the extent > permitted by Law." I don't think this works. Who holds copyright is a matter of law, not licensing, and my understanding is that in many (most? all?) jurisdictions, you can't reassign copyrights from one legal entity to another (whether those legal entities are people or companies) without a signed contract. If your license claims to make this happen implicitly, and an upstream relies on it having done so, in a jurisdiction where this is not actually possible, then the upstream and the company are now violating each other's copyright, and each could plausibly win damages from the other (possibly after an expensive legal fight, which in many jurisdictions means the larger entity will probably win, because it can stall until the smaller entity runs out of money). Any time you think "my license forces someone to do what I want", you should be aware that that's only shorthand for "my license forces someone to choose between doing what I want, or violating my copyright and facing the consequences of that, or not interacting with my software in ways that are restricted by copyright". If they have no legal authority to do what you want - perhaps because they signed a contract reassigning copyright in what they write to their employer - then their only options are to violate your copyright (which has no practical consequences unless you find out and can successfully sue), or avoid your software (oops, now you've lost another contributor). I am not a lawyer in any jurisdiction, but as far as I know, neither are you. I would recommend that you save your innovation for software, and leave the innovation in licensing to lawyers (or at least involve qualified lawyers in the process early and often), because the consequences of a bug in a license can be worse than the consequences of a bug in software. If your software has a bug, the user might lose some data or some time; if your license has a bug, users of the license can end up either placing their own work under a license that cannot be enforced in court (equivalent to a completely permissive license, which does not seem to be what you're aiming for), or violating copyright and at risk of being sued by a copyright holder. > Hackers don't waive their Copyright, but share it upstream. > > This non-exclusive copyright assignment is one of the pillars of this > License that make it stronger than the others existing copyleft. Do you have legal advice that tells you which of the jurisdictions of interest to you have a concept of sharing copyright like this? > However you are right on this point: AFAIK you cannot mix in the same > program code under the Hacking License and code under a GNU copyleft. You're downplaying this, but I think this is a major disadvantage. https://dwheeler.com/essays/gpl-compatible.html is the classic essay on this. Open source projects live or die by their contributors, but contributors (and particularly experienced developers who have been burned by this sort of thing before) are going to be put off by use of a non-standard license that isn't GPL-compatible - I know I would be. I already work on one project (dbus) where I'd like to be able to copy in code from another project I work on (GLib), but because of licensing technicalities (and an early copyright holder that went out of business and can no longer grant permission to relicense), I can't. The result is that dbus ends up with a bad implementation of many of the same concepts that GLib already does better. This is a harmful situation to be in and I would strongly recommend doing your best to minimize it. Proliferation of permissive licenses (for example MIT/X11-style) is annoying, but not *so* bad, because they're simple, highly permissive, and compatible with each other (it's straightforward to combine code under different permissive licenses). Proliferation of copyleft licenses is harmful (and the stronger the copyleft, the more harmful it is), because each copyleft license is incompatible with any copyleft license that adds an additional restriction. We've been here before with the GPL and CDDL, for example. smcv
