Re: Hacking License
Thanks Simon for the time and effort you have dedicated for this valuable mail.
I really appreciate it.
On Wed, 12 Dec 2018 at 10:49, Simon McVittie <email@example.com> wrote:
> 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.
Let me say that I seriously consider your concerns and all other
I carefully considered many of the points you raise before starting to
draft the Hacking License.
Ultimately, I wasn't able to find a better way to achieve the wider
goals I have.
And as of today, I'm still unable to see one.
This is probably because of the goals themselves, but to achieve
ambitious (crazy? :-D) goals you cannot accept to lessen them.
> 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.
No, this is not a goal, but a mean.
I want all people to experience the values of Curiosity, Candor,
Freedom, Intellectual Honesty, Critical Thinking and Collaboration
that characterize the hackers' ethics.
And I want all people to learn how to hack their own software just
like we are able to read and write prose.
These are my goal.
The Hacking License, Jehanne and the lessons I give for free in the
school of my 10yo daughter... are different means to achieve these
> 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.
This is by design.
To fight group-think and conformism, we need to spread critical thinking.
> 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.
This is not a rational response, just a lazy one.
To give a rational response, you have to consider the alternatives and
the outcomes of contributing to that specific software under that
specific license in that specific time and place.
> 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.
Sure, it is.
But such cognitive load is the price of Freedom.
Since Hammurabi, if you can't read the Law by yourself, you are
effectively subject to others' will, and ultimately not Free.
There's no way around this.
But beyond this obvious political consideration, you can see maneuvers
to limit hackers' Freedom all around us, and from several different
Technology is a prosecution of Politics by other means.
Hackers change the world. We are "dangerous".
When I saw lawyers arguing to introduce formal barriers to the
introduction of new Copyleft on the OSI mailing list, I realized the
Hacking License was an urgent statement of Freedom against this sort
of power play.
> 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.
If you trust the Law and the Judge, there are two possible issues here:
1. the license is unclear
2. the license is clear but not enforceable in court
I did my best to make it clear and I really think it is (even more
thanks to all the feedbacks I got from this community and the
As for 2, I trust Judges to serve Justice as I serve Curiosity. That's
why I introduced the Severability clause.
> 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.
Oh... you mean like the WTFPL? :-D
At the end of the day, it's up to the user to understand if the GPL is
enforceable in his own jurisdiction.
No lawyer will ever pay with his money if it turns out that in a
particular legal system, present or future, the GPL is equivalent to a
MIT+total patent license.
The same apply to the Hacking License, but it makes the decision
explicit and conscious.
> 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
This is a good news!
When Jehanne will be influential and useful, the Hacking License will
I don't think it's weird, actually... but I'm not easy to offend. :-D
> but it isn't 1995 any more
That's true, it's December 12, 2018.
I'm used to start counting the history of Informatics since Turing.
Others hackers I respect start from Leibniz, but even if so we are
just 350 years in.
We are roughly 5000 years in the history of Writing.
Despite the 23 years passed, we are still at the Hieroglyphs of
> 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.
You are trying to measure a temperature with a meter.
Jehanne is a hack.
It's market share is totally irrelevant to me.
So is the number of contributors.
It's a gift. And a creative act of Curiosity.
> 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.
Nevertheless, I've heard of large evil companies that avoid AGPLv3.
I guess they would likewise avoid software under the Hacking License.
> This seems like a
> relatively tenuous benefit, compared with the cost of license proliferation.
I wonder how corporations can survive with all those different EULA! :-D
"License proliferation" is to engineers what "Operating System
proliferation" is to business people.
They blame what they do not understand.
Guess what? I'm writing an operating system. And a License! Bad me! :-D
> 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.
With all respect, I'm afraid you are wrong about this.
> 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.
AFAIK, in the US you don't need a signed contract for a non-exclusive
> 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).
On the other end, what happens if that non-exclusive copyright
assignment is valid in even just one country?
> 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),
You are right about this: you can break any law until you get caught.
But if you read the Hacking License more carefully, you will see it's
not designed to force someone doing something but to let everybody
> or avoid your software (oops, now you've lost another contributor).
To me, the number of the people that "give back" is not an interesting metric.
This is Free Software, not Open Source.
> 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)
Do you leave Politics to politicians?
> 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;
Or his freedom (broken encryption).
Or his life (broken health diagnostics).
I really think you are largely undervaluing how fundamental is our
power to the current world and how big is our responsibility.
> 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.
Again, in all jurisdiction I know, the lack of a valid license on a
copyrighted work is NOT "equivalent to a completely permissive
license", but to "all rights reserved".
> > 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?
Laws are written. ;-)
However, I can confirm that I've had NO legal advice that this
copyright assignment IS NOT valid in a jurisdiction I care.
In any case, it's up to people living in such jurisdictions to ask for
a different license to the copyright holders, because they cannot
satisfy condition 3.9.
> > 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
Fortunately, Jehanne is Free Software, not an Open Source project.
I know there is a lot of confusion about these terms in these days of
Also, Wheeler's essay assumes that the existing computing
infrastructure (where GPL is king-copyleft in OSS and in FS for
various reasons) is here to stay.
Jehanne is an heretical attempt to replace such infrastructure with a
simpler and more powerful one. So Wheeler's essay is largely
> 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'm sorry about this.
If you like to share your previous bad experiences with existing
licenses I'd like to read more about them (maybe off-list, if
I have shared mine earlier in this thread, and the behavior of well
known players back then, motivated me to create the Hacking License.
Maybe you could change your mind in the future?
> 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.
I'm sorry about this.
But note that you are talking about the relation between library and
executable, which is relatively less relevant in the distributed
architecture that I'm trying to build with Jehanne, where everything
is a file system.
> 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.
The GPL was designed for the GNU system, which is a free CLONE of an
existing proprietary system.
I wrote the Hacking License as a tool for hackers writing INNOVATIVE
However I would really pose no objection to the FSF if they added a
compatibility clause to a new, HACK-equivalent, GNU GPLv4 that let
people relicense the software under the Hacking License. :-p
Much as I love irony, I wouldn't be a computer scientist arguing
against license proliferation after writing a new license myself.
After all, this would just be a fair reciprocity, because software
under the Hacking License could already be relicensed under a clearly
equivalent license (provided it also comply to condition 3.5 and 3.6)
thanks to the copyright assignment granted at 2.3, so copyright
holders who trust FSF and prefer an equivalent license written by
their lawyers, could easily do the switch.
> We've been here before with the GPL and CDDL, for example.
The CDDL was designed to be incompatible with the GPL, for the
marketing purposes that open source (and OSI) is designed to serve.
The Hacking License is not compatible with GPL because it pursuits
more radical goals.
But such goals are just the natural evolution of the values spread by
Stallman with the GPL.
That's why the Hacking License does not limit Wrapper compatibility to
the Hacking License.
To acknowledge its own roots in Free Software, an expression of
hackers' culture that abhor conformism and group-think.