Re: Hacking License
On Tue, 11 Dec 2018, Giacomo Tesio wrote:
On Tue, 11 Dec 2018 at 13:06, Paul Jakma <paul@jakma.org> wrote:
On Tue, 11 Dec 2018, Giacomo Tesio wrote:
Unless there is some really compelling reason the modifier can not make
their changes available (desert island, dissident), why not just require
they make the changes available - given how easy it is to distribute
software these days?
This is not a binary state, either easy to distribute or impossible
to. The world is large and the bandwidth you assume is not cheap or
easily available to everyone.
That may be true, but there may come a point where a line must be drawn.
Either the distributor does have sufficient Internet access to not meet
some "desert island" clause, or they do not. Either there is sufficient
risk to meet some "dissident" clause, or there is not.
The world may not be binary, but in the event of a dispute sufficient to
take the matter to court, a judge will draw that line, according to the
context, in terms of the parties involved (not the world). (This is also
why it is important to use terms that the legal world prefers and has
already reasoned about, rather than inventing your own).
If someone can download copies of software I have made available, and if
they are able to distribute their modifications to others using the
Internet, then they are going to have a hard-time arguing that they
could not also upload the software to, say, either GitHub, or else my
instance of gogs with free hosting for modified versions of said
software (specifically there to facilitate that licence requirement).
The corporate abusers I have in mind are very clearly not on a desert
island, very clearly are active on the Internet, very clearly are fully
capable of making their modifications available to all.
That's why the Hacking License give right upstream.
In the moment an abuser abuse the license, all his rights are terminated.
The GPL also terminates. The GPLv2 has very strong termination
conditions even.
That's not what happens though, the abuser finds a loophole, to carry
out their abuse (not giving back) in a way that can be argued to not
violate the licence.
Making available != getting integrated upstream.
This is an oversimplification: by making available a severe zero-day
fix that would likely to get lost among the thousands of "newly
available" patches of the week, you might set up a blame campaign on
the upstream hackers that are "unable to live up to their success".
Free Software is a gift. I want it to remain a gift.
As such it cannot become a burden on those who donate.
I don't see how it could be a burden, if one is openly distributing
modified versions of some copylefted work on an ongoing basis, to also
be required to upload a copy to any of a number of free open-source
source code hosting sites.
AGPLv3 also poses a condition to the execution: beyond the wording, if
you make a covered work available across a network (a use) you have to
make the sources available to the users. The Hacking License is
simpler: as a condition to the all the grants provided, you should
make the source available to any User (as defined in the License
itself).
The corporate abusers I have in mind would be able to fulfill that
condition.
And I'm back to square one, with the same problem I have with the GPL.
The Users have a disincentive to pass the source on, through
side-contracts.
And I'm in the same position as before with the GPLv2: The question of
whether those side-contracts are at odds with the licence, or whether
they are orthogonal and wholly separate things, does not have an obvious
answer.
Much easier would be a licence where all you had to show was that the
software was passed on, and that that act on its own was sufficient to
trigger the general source distribution requirement (modulo "desert
island", etc., which pretty obviously do not apply to the general
corporate abusers).
Same for your grampa. When it stop being a personal hack and you have
to publish the patch somehow?
I don't know. There is some line though, and - if it comes down to it -
a judge can draw that line.
Just as the corporate abusers are obviously not on a desert island,
these abusive cases generally do not involve people distributing a hack
to their granda via SSH access.
The abusive cases are far from the grey lines, so there is little need
to worry about /exactly/ where they lie - and ultimately that comes down
to a judge.
Despite its evidence, may people cannot see the parallel between
writing in Ancient Egypt and information technology today. So they
tend to discard issues that will arise when programming will be easy
and diffused as it's writing today.
The legal system will find a way of deciding these matters though, where
people care enough to bring them to a court.
No, the modifier must make the modifications available only to their Users.
This is open to abuse, as explained. ;)
If you add time into the equation, it should be easy to see.
As time goes on, someone able and interested to spread the
modifications might share them with you.
The case I'm thinking of, we havn't had "Users" spread the
side-contract-restricted modifications in a decade+.
So... I disagree. It's empirically untrue, at least within time-scales I
care about.
This however is particularly interesting if someone try to use a SaaSS
to make modifications privates.
If you can deduce the changes, you have the rights (including patent
licenses) to introduce them.
And you can transfer such rights to third parties with the Derived Work.
It's kind of useful in that respect, to get a copyright to the
modifications themselves (beyond the rights you hold in a derived work
anyway).
It doesn't solve my abuse problem though.
regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
The secret of healthy hitchhiking is to eat junk food.
Reply to: