Re: Hacking License
On Wed, 12 Dec 2018 at 16:06, Ian Jackson
wrote:
>
> Giacomo Tesio writes ("Re: Hacking License"):
> > If the problem is not in the text of the license, how can I fix it?
>
> In the short term, you can add a clear compatibility clause that
> allows relicensing as a well-known existing licence, or you can use an
> existing licence.
This is a suggestion to fix a problem in the license.
Unfortunately such fix would completely weaken the Hacking License too much.
> In the longer term you can engage with the copyleft community - in
> fora other than debian-legal - to move the wider community's centre of
> opinion in your preferred direction.
I already have an operating system to write! :-)
This is not an excuse: the operating system itself will move the
"community's centre of opinion".
But as "a voice of one calling in the wilderness", I wouldn't be much effective.
> Or you can try to find some DD who has the time and inclination to
> - sponsor your package at a technical level
> - ignore or disagree with recommendations from people like me
> - review your licence in detail
> - engage with you and with Debian ftpmaster to help resolve
> whatever issues they and you and ftpmaster identify
Now that you describe the process, I recall that in 2002 I tried it
(with no success, I can't recall why) for a small game.
https://lists.debian.org/debian-italian/2002/09/msg00722.html
> For the avoidance of any doubt, I think I am probably not opposed to
> your political goals. I may well even support them. That seems
> likely. Maybe they are even important enough to justify a new
> licence, but I think they don't justify trying to go it alone in the
> way you seem to be doing.
There are several reasons why I'm "trying to go it alone".
Some have been outlined in the response to Simon McVittie.
At the end of the day, being alone has several big advantages:
- I'm free
- I've nothing to loose
- I cannot do much harm if I fail
- I can do a lot of good if I succeed
But on the specific matter of the Hacking License, I obviously welcome
help and suggestions.
> > However, if you express the consensus in Debian, I suggest to fix the
> > texts at https://lists.debian.org/debian-legal/ and at
> > https://people.debian.org/~bap/dfsg-faq so that it more clearly
> > express the intents, boundaries and goals of this mailing list.
>
> As for the first link, it says only
>
> | Copyright, licensing and patent issues
> | Discussions about legality issues such as copyrights, patents etc.
>
> which IMO accurately describes the scope of the list within Debian.
I'd say that we are talking about licensing issues, in this thread.
> I'm sorry that not all of Debian's practices, including our
> disinclination to help with the detailed review and drafting of
> bespoke licences, are documented. If this were to be documented it
> would be in the Developers' Reference, probably, and certainly not the
> mailing list description.
Fine.
However the current documentation look somewhat misleading or very outdated.
https://www.debian.org/legal/licenses/ for example says
"debian-legal is advisory. The actual decision-makers are the
ftpmasters and the package maintainers. However, if one
cannot convince most of the generally liberal debian-legal
contributors, it's probably not clear that the software follows
the DFSG."
That sentence, together with the DFSG FAQ linked from there was what
directed me here.
To be honest, I've never considered the Hacking License a draft, but I
was open to corrections that could have been pointed out here.
On the other hand, I really thought this was the right place to
discuss the compatibility of a license with Debian vision of free
software.
And actually I received some feedback on this regard (that I tried to address).
I suppose that lack of further objections about the Debian
compatibility of the Hacking License doesn't mean that I convinced
most of debian-legal contributors, but that on the contrary they agree
with you and that no software under the Hacking License should go in
Debian, whatever is actually written in the license itself.
That's why I asked "If the problem is not in the text of the license,
how can I fix it?" because, at times, some exchanges seem
(legitimate!) political opinions about the opportunity of a license
instead of problems with this specific license.
That's why I supposed that we lack a forth test that could clearly
exclude the Hacking License.
Some how, I think this unstated insight of Debian Developers should be
verbalized.
> The second link is someone's personal web page over which I have no
> control, and over which Debian exercises no control other than to
> avoid things like Code of Conduct breaches. It has the word `DRAFT'
> in the page title. If you have read anywhere that it is in any way
> official, please let me know and I will arrange to have its status
> made clearer.
That link is suggested at the end of
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 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 people's suggestions. 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 goals. > 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. This is by design. To fight group-think and conformism, we need to spread critical thinking. > 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. 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 parties. 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 copyleft-next's members). 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
Re: Hacking License
Giacomo Tesio writes ("Re: Hacking License"):
> On Mon, 10 Dec 2018 at 18:31, Ian Jackson
> wrote:
> > I recommend to my fellow Debian Developers that they do not try to
> > introduce into Debian a package with this licence. In particular,
> > I would recommend to my fellow DDs not to sponsor such a package.
> > That will save ftpmaster the bother of reviewing this licence.
>
> I guess this is a political recommendation with the weight of an order.
I have no more authority on this question than any other DD. Maybe
you will find one who disagrees. Debian is far from homogenous.
> Is there something I can do about it?
> If the problem is not in the text of the license, how can I fix it?
In the short term, you can add a clear compatibility clause that
allows relicensing as a well-known existing licence, or you can use an
existing licence.
In the longer term you can engage with the copyleft community - in
fora other than debian-legal - to move the wider community's centre of
opinion in your preferred direction.
Or you can try to find some DD who has the time and inclination to
- sponsor your package at a technical level
- ignore or disagree with recommendations from people like me
- review your licence in detail
- engage with you and with Debian ftpmaster to help resolve
whatever issues they and you and ftpmaster identify
For the avoidance of any doubt, I think I am probably not opposed to
your political goals. I may well even support them. That seems
likely. Maybe they are even important enough to justify a new
licence, but I think they don't justify trying to go it alone in the
way you seem to be doing.
> However, if you express the consensus in Debian, I suggest to fix the
> texts at https://lists.debian.org/debian-legal/ and at
> https://people.debian.org/~bap/dfsg-faq so that it more clearly
> express the intents, boundaries and goals of this mailing list.
As for the first link, it says only
| Copyright, licensing and patent issues
| Discussions about legality issues such as copyrights, patents etc.
which IMO accurately describes the scope of the list within Debian.
I'm sorry that not all of Debian's practices, including our
disinclination to help with the detailed review and drafting of
bespoke licences, are documented. If this were to be documented it
would be in the Developers' Reference, probably, and certainly not the
mailing list description.
The second link is someone's personal web page over which I have no
control, and over which Debian exercises no control other than to
avoid things like Code of Conduct breaches. It has the word `DRAFT'
in the page title. If you have read anywhere that it is in any way
official, please let me know and I will arrange to have its status
made clearer.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
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
