Re: Hacking License
Il December 1, 2018 10:56:51 AM UTC, Francesco Poli <invernomuto@paranoici.org> ha scritto:
>Hello,
>thanks for writing a new library and for willing to distribute it as free software.
Hi Francesco, thanks to you for reading and commenting the license.
>As far as the licensing choice is concerned, please try hard and avoid
>writing your own custom license.
I appreciate your advice but I really thought hard about this, I know the previous debates and the stigma on hackers writing their own license.
AGPLv3 has been my default choice since it exists but now I realised it's not strong enough for the goals of the software I'm going to distribute.
As you might guess if you looks at Jehanne operating system (and actually from the license itself), my goals are pretty different from the ones of companies trying to maximise their revenues by over limiting the freedom of their users.
>A newly written license, especially a strong copyleft one, adds to the
>already rampant license proliferation craziness (which is bad in
>itself) and is incompatible with many other licenses (thus causing more
>headaches to everyone in the community).
Consider that the library I'd like to distribute to Debian is a sort of compatibility layer to ease the interaction of Unix users with Jehanne.
Jehanne is a new distributed operating system, so I'm in control of the software I'm gonna port and I could just NOT port incompatible one, because the goal is not the software, not even Jehanne, but the Freedom of the users.
>
>Please do really consider adopting the GNU GPL v2, if you want a strong copyleft license.
I have read and carefully considered all the free licenses listed by FSF pages.
Unfortunately none matches the needs of my vision.
>
>> AFAIK, it conforms to the DFGL and pass the three corner-case tests,
>> but I'd like to know your legal opinions and criticisms, as I'm going
>> to package such library for Debian too.
>
>I don't think that software released under the "Hacking License"
>complies with the Debian Free Software Guidelines (DFSG).
I'm more than happy to discuss the matter and adjust the wording when needed.
>[...]
>> Hacking License
>> ===============
>[...]
>>
>> 1. Definitions
>> --------------
>[...]
>
>Some definitions are really awkward and counter-intuitive.
>They may have unintended consequences on the rest of the license...
They have been carefully crafted to have intended consequences on the rest of the license.
Being awkward and counterintuitive is not a problem if they are clear and they are at the beginning of the license to instantly clarify that while readable, this licence is NOT obvious and requires a careful read and understanding.
Given that, if you see specific problems in the definitions I'd really like to know and possibly address them.
>
>[...]
>> 2. Grants
>> ---------
>>
>> Permission is hereby granted to any User of the Hack to study, copy,
>> use, wrap, modify and/or distribute the Hack, and to distribute any
>> Derived Work under this License but with a different name and logo.
>
>The requirement to change the name is permitted by DFSG#4, but is
>discouraged.
>The requirement to change logo is not as clearly permitted.
This seems a bit strange, I added that "but..." after reading it in a FSF approved license (but unfortunately I cannot recall which one).
I can remove "and logo" if it turns out to be incompatible with Debian guidelines, but I'd like to know more about the incompatibility.
Any license as been defined as not-free by Debian in the past because of this?
>> Furthermore, if the Hack is a Derived Work, the Hackers grant to the
>> copyright holders of the Inspiring Hack all rights, title and
>interests
>> in any copyright the Hackers have in the Hack.
>
>This seems to effectively transfer the rights in the Derived Work to
>the copyright holders of the original work ("Inspiring Hack"),
It doesn't trasfer the copyright but shares it with them along with the Hack.
>As a consequence, the copyright holders of the original work get many
>more rights on the Derived Work than anyone else.
Not just more rights but more constraints.
If they violate the conditions once they would lose the copyrights they received with any Derived Work, with interesting outcomes (that would not affect the rights of others who had received rights from them)
>I don't think this clause complies with the DFSG.
>I would say it fails DFSG#3, since I cannot distribute a derived work
>to the author of the original work under the same terms as the license
>of the original work, since I am forced to grant more rights.
You must distribute the Derived Work under the same license that defines the term and conditions.
The copyright assignment that the Hacking License requires is designed to be resilient to abuses but yet give the flexibility to address new attacks to user freedom.
>
>[...]
>> 3. Conditions
>> -------------
>>
>> The grants provided by this License are subject to the following
>conditions:
>[...]
>> 2. The source of the Hack shall be made available with the Hack
>and/or
>> by other reasonable means to every User, according to this License
>> and without additional constraints or requirements, such as
>further
>> agreements, any royalty or other fee.
>
>This seems to allow binary package distributions (as done by the Debian
>mirror network) just because of the "or by other reasonable means"
>phrase. I hope it can be considered enough, but I am not sure it would
>hold water in a court of law...
As far as I can remember, AGPLv3 has a similar wording.
>
>[...]
>> 4. The tools, dependencies and know-how required to perform any of
>the
>> activities permitted by this License shall be made available to
>the
>> User with the source of the Hack (except for those tools and
>> dependencies that are already available to every User either free
>of
>> charge or in off-the-shelf distributions of the Runtime) and
>without
>> additional constraints or requirements, such as further
>agreements, any
>> royalty or other fee.
>
>This seems to be troublesome, although well-meaning.
>If for instance the work is written in the Ruby programming language,
>the clause could be interpreted as requiring to make a full programming
>course about the Ruby language available.
Well this would be a stretch of the license that I don't think a judge would consider, but I welcome suggestions for adjusting the wording.
The know how to be included should exclude what is already available for free to the users by other reasonable means.
The fundamental right I'm trying to grant here is self-hosting of Applications that integrate the Hack.
>
>[...]
>> 6. No patent infringement litigation claim (excluding counterclaims
>and
>> cross-claims) alleging that all or part of the Hack directly or
>> indirectly infringes a patent shall be initialized by the User.
>
>This is controversial and has been discussed several times on
>debian-legal, with different opinions expressed by many people.
>It _may_ comply with the DFSG, but I am not sure.
No problem, thanks for pointing it out
Let's wait for more definitive opinions...
>> 7. The User has never violated any of the previous conditions.
>[...]
>
>This lacks a forgiving provision.
It's on purpose.
Previous bad experiences with violations of my GPLv2 works shows that forgiving provision would be abused by the strongest party.
(more here if you are interested: https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696 )
>I mean: it seems that a User who has done wrong once, can never be
>forgiven and will never again be granted any rights by this license
>(maybe even for *any* work under the Hacking License, not only for the
>work the violation was about...).
>I don't think this is fair.
No, the license only covers a specific Hack and it's derivatives.
Thus temination would be limited to these works.
Giacomo
Reply to: