Re: Hacking License
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
Reply to: