Re: Hacking License
On Tue, 11 Dec 2018 at 23:30, Eloi wrote: > > El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: > > 2. Sencha releases as GPLv3 only the first major version and the first > > minor version of a new release, and only release as proprietary the > > code the successive minor versions (that can largerly extend the > > widget available). > > This is, as you stated, what could happen if the original work was > licensed under the GPLv3. However, if we're talking about a derived > work, then the proprietary selling of this extended package is already a > violation of the GPL. The fact that, with your license, this would too > end in a violation is moot: your "new" protection already exists. Yes but not exactly in the same way. If a company violates the GPL, his right to distribute the Derived Work ends, but the copyright on the Derived Work is still under its full control. Thus a third party could not take the (let's suppose) leaked code from the Derived Work and merge the interesting parts upstream. 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." > What I said is where "public domain" is not a valid status for a work is > because some author rights cannot be waived. One of them, the transfer > of authorship. The non-transferable rights granted to authors under a jurisdictions are excluded from the copyright assignment (see the definition of "Copyright" and the grant 2.3). > > The non-exclusive copyright assignment doesn't waive any right, just shares > > the transferable ones with upstream copyright holders "to the extent > > permitted by law" and under the license conditions (if the upstream > > copyright holders violate such conditions they lose such rights). > > And what makes your license different from the GPL in that point? Grant 2.3: If the Hack is a Derived Work, the Hackers grant to the Copyright holders of the Inspiring Hacks 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. 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. > If you > make modifications subject to copyright law, you retain the full > copyright while also having your changes subject to the GPL. From the > modifier's point of view, the GPL protects you against downstream > picking up your changes and privately licensing them (so both upstream > *and* you can sue) while copyright law protects you against upstream > doing the same (because *you* are the copyright holder of your > modifications). The Hacking License incentivate modifiers to fulfill the license because if they try to, say, impose additional constraints or restrictions to the Users, the Users are in turn incentivated to take on their business model with the support of the upstream developers. > However, on the broader issue I > understand that Debian is not only obliged, by manifesto, to have only > free software on main, but also to make sure that the resulting combined > work is also distributable: just think about the infamous "OpenSSL > exception". That fact that your license may be considered free software > is a requirement, but by itself is not enough: OpenSSL is free software, > a program which uses OpenSSL may be free software by itself, but the > combined work may not without the exception clause. I don't think that the problem is just for Debian here: without the exception clause, any distribution would face the same issue because the problem is in the licensing of the Derived Work, as the software that depends on OpenSSL would be licensed under an incompatible license. 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. Fortunately this doesn't make all works based on the Hacking License non-distributable, just those that would require the violation of one or more of the licenses of the works they derive. In the case of a library that depends on few POSIX system calls, this compatibility issue do not arise. Giacomo
Re: Hacking License
On Tue, 11 Dec 2018, Paul Jakma wrote: 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). To clarify: 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. The abusive cases are exploiting grey lines in the /current/ copyleft licences. We can move the grey lines so those cases are much further from the grey lines, by making public source distribution a requirement, upon distribution - modulo "desert island" and "dissident" escape clauses. I want to have a copyleft licence available that does that, for next time I want to distribute code under copyleft terms. The Hacking licence proposed is intriguing, but doesn't quite do that for me (along with some other issues), as it stands, AFAICT. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The goal of science is to build better mousetraps. The goal of nature is to build better mice.
Re: Hacking License
On Tue, 11 Dec 2018, Eloi Notario wrote: Furthermore, these patches will be protected by the GPLv3 and even if publicly available Sencha will be unable to sell them, Probably you know this, and you meant "sell them exclusively or somesuch", but just to note: Nothing in the GPL prevents one from selling GPL source code. ;) regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Life is divided into the horrible and the miserable. -- Woody Allen, "Annie Hall"
Re: Hacking License
El 11/12/18 a les 22:33, Giacomo ha escrit: > On December 11, 2018 7:54:16 PM UTC, Eloi Notario wrote: >> El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: >>> [...] >>> 2. If ExtJs was a Derived Work of a software release under the >> Hacking >>> License, Sencha would have no right to keep any version proprietary. >> Being Sencha the copyright owner (noting for clarity as I cut that from >> the quote), I am quite skeptical this argument will hold at least under >> Spanish law and probably under all those jurisdictions where the >> "Public Domain" concept is not acknowledged because no author rights can be >> waived. This includes the right to decide how -and if- a work is to be >> distributed. > As should be clear in the text you quoted, I was talking about an > hypothetical ExtJS that was > > - a Derived Work > - of a software under the Hacking License Maybe I cut too much text from the original quote. Let me pick a previous paragraph: > 2. Sencha releases as GPLv3 only the first major version and the first > minor version of a new release, and only release as proprietary the > code the successive minor versions (that can largerly extend the > widget available). This is, as you stated, what could happen if the original work was licensed under the GPLv3. However, if we're talking about a derived work, then the proprietary selling of this extended package is already a violation of the GPL. The fact that, with your license, this would too end in a violation is moot: your "new" protection already exists. > This, just like with the GPL, would bind them to distribute their Derived > Work under the same License that they received it. > > Also, in no way the Hacking License put the covered work under public domain > (and if you read it this way, I would really appreciate if you can explain > your interpretation so that I can clarify the text). I did not say so. Even more, where I live any "public domain" license is actually void and as such may mean the same as full protection, that's why the Creative Commons came with a CC-0 license that says "if where you live is public domain legally acknowledged then that's what you have, if not then your rights are essentially "do as you please" with this work as long as you don't claim ownership". What I said is where "public domain" is not a valid status for a work is because some author rights cannot be waived. One of them, the transfer of authorship. > The non-exclusive copyright assignment doesn't waive any right, just shares > the transferable ones with upstream copyright holders "to the extent > permitted by law" and under the license conditions (if the upstream copyright > holders violate such conditions they lose such rights). And what makes your license different from the GPL in that point? If you make modifications subject to copyright law, you retain the full copyright while also having your changes subject to the GPL. From the modifier's point of view, the GPL protects you against downstream picking up your changes and privately licensing them (so both upstream *and* you can sue) while copyright law protects you against upstream doing the same (because *you* are the copyright holder of your modifications). This was just pinpointing a detail. However, on the broader issue I understand that Debian is not only obliged, by manifesto, to have only free software on main, but also to make sure that the resulting combined work is also distributable: just think about the infamous "OpenSSL exception". That fact that your license may be considered free software is a requirement, but by itself is not enough: OpenSSL is free software, a program which uses OpenSSL may be free software by itself, but the combined work may not without the exception clause.
Re: Hacking License
On December 11, 2018 7:54:16 PM UTC, Eloi Notario wrote: >El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: >> [...] >> 2. If ExtJs was a Derived Work of a software release under the >Hacking >> License, Sencha would have no right to keep any version proprietary. > >Being Sencha the copyright owner (noting for clarity as I cut that from >the quote), I am quite skeptical this argument will hold at least under >Spanish law and probably under all those jurisdictions where the >"Public Domain" concept is not acknowledged because no author rights can be >waived. This includes the right to decide how -and if- a work is to be >distributed. As should be clear in the text you quoted, I was talking about an hypothetical ExtJS that was - a Derived Work - of a software under the Hacking License This, just like with the GPL, would bind them to distribute their Derived Work under the same License that they received it. Also, in no way the Hacking License put the covered work under public domain (and if you read it this way, I would really appreciate if you can explain your interpretation so that I can clarify the text). The non-exclusive copyright assignment doesn't waive any right, just shares the transferable ones with upstream copyright holders "to the extent permitted by law" and under the license conditions (if the upstream copyright holders violate such conditions they lose such rights). Giacomo
Re: Hacking License
El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: > [...] > 2. If ExtJs was a Derived Work of a software release under the Hacking > License, Sencha would have no right to keep any version proprietary. Being Sencha the copyright owner (noting for clarity as I cut that from the quote), I am quite skeptical this argument will hold at least under Spanish law and probably under all those jurisdictions where the "Public Domain" concept is not acknowledged because no author rights can be waived. This includes the right to decide how -and if- a work is to be distributed. However, for that to work requires Sencha being the sole author (and you pointed he refuses patches for this very reason), but nothing forbids other contributors to fork and then patch Sencha's work. Furthermore, these patches will be protected by the GPLv3 and even if publicly available Sencha will be unable to sell them, forcing him to either reimplement in his own way or not to use them at all if he wishes to distribute privately.
Appuntamento con il nuovo ciclo di lectiones magistrales di AFIP International
Se non visualizzi correttamente questo messaggio, clicca qui: http://www.mailant.it/nl.aspx?idp=14715=101034=0E2FA94E582CE1334891A9A307CD9E07B21F6098=6388417=A0C054D045F9E72E2A2E5836C01B76DB4EDE4FB6
Re: Hacking License
On Tue, 11 Dec 2018, Giacomo Tesio wrote: On Tue, 11 Dec 2018 at 13:06, Paul Jakma 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
Re: Hacking License
On Tue, 11 Dec 2018 at 13:06, Paul Jakma wrote: > On Tue, 11 Dec 2018, Giacomo Tesio wrote: > > The point is, made available to whom? > > To anyone. > 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. > The more options are given for not distributing modifications widely, > the more opportunity there is for abusers to find loop-holes. That's why the Hacking License give right upstream. In the moment an abuser abuse the license, all his rights are terminated. But the right obtained by others still holds, including the copyright assignment and the patent licenses on the abuser's work. Now think about it: would you sue a competitor that simply uses the rights you have granted him through the adoption of a software under the Hacking License (and that you have violated in the first place)? I guess this would be a pretty complex position to hold in court. > 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. > > - it would disincentive hack for personal purpose for the burden to > > prepare a 3rd party readable patch > > No. > > Copyleft usually only regulates and imposes conditions upon distribution > (so long as the licence is adhered to generally). The conditions on > making the sources available are imposed only if one wishes to > distribute the work. 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). > If "personal hack" means "no distribution to others", then there's no > obligation to make the modifications public. If you write a personal hack of `wc` that counts the sentences in your language and you give ssh access to your machine to your little brother that is still a personal hack. Same for your grampa. When it stop being a personal hack and you have to publish the patch somehow? According to the Hacking License, it's perfectly fine to do just let users access the modified sources. > > In both case, strictly applied, such rule would create weird practical > > issues to free software. > > I think you're objections were not with what I had imagined. ;) Maybe. :-) 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. > > That's why the Hacking License assigns copyright and patent license > > upstream but without turning upstream copyright holders into Users. > > That does not require the modifier to make the modifications available > to the upstream, or anyone though. No, the modifier must make the modifications available only to their Users. > > They can also become users, obviously, but they can also just benefit > > from the copyright assignment and patent license to reimplement > > similar behavior without legal issues. > > How would I benefit from copyright assignment in modifications to my > code, if I can never get (perhaps never even know about) those > modifications? 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. Or you might be informed about the inner working of the modifications without being able to see the change yourself. In any case you would have the right to reproduce such change if you feel so inclined. 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. > Note that one _already_ gets a copyright interest in any modifications > to one's work (GPLed or whatever), if those modifications constitute a > derived work. (In at least some jurisdictions). > > Just being a copyright holder in some derived work of one's own work is > not per se sufficient to ensure one can get access to that derived work > though. Right, but it can make very hard to sue
Re: Hacking License
On Tue, 11 Dec 2018, Giacomo Tesio wrote: On Tue, 11 Dec 2018 at 12:22, Paul Jakma wrote: Personally, I want a copyleft for the 'gitlab/github/gogs' era: Source must be made available, unless you're on a desert island or there is a credibly physical risk of imprisonment or harm to individuals by disclosing their identity. The point is, made available to whom? To anyone. 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? The more options are given for not distributing modifications widely, the more opportunity there is for abusers to find loop-holes. To the users? Sure. Upstream? In a world where people happily hack their own software, this might open a can of worms upstream and downstream: - it would impose a review process (and infrastructure) for patches that would slow down development Making available != getting integrated upstream. - it would disincentive hack for personal purpose for the burden to prepare a 3rd party readable patch No. Copyleft usually only regulates and imposes conditions upon distribution (so long as the licence is adhered to generally). The conditions on making the sources available are imposed only if one wishes to distribute the work. If "personal hack" means "no distribution to others", then there's no obligation to make the modifications public. In both case, strictly applied, such rule would create weird practical issues to free software. I think you're objections were not with what I had imagined. ;) That's why the Hacking License assigns copyright and patent license upstream but without turning upstream copyright holders into Users. That does not require the modifier to make the modifications available to the upstream, or anyone though. They can also become users, obviously, but they can also just benefit from the copyright assignment and patent license to reimplement similar behavior without legal issues. How would I benefit from copyright assignment in modifications to my code, if I can never get (perhaps never even know about) those modifications? Note that one _already_ gets a copyright interest in any modifications to one's work (GPLed or whatever), if those modifications constitute a derived work. (In at least some jurisdictions). Just being a copyright holder in some derived work of one's own work is not per se sufficient to ensure one can get access to that derived work though. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Another hour, another error report... - Eric S. Raymond on linux-kernel
Re: Hacking License
On Tue, 11 Dec 2018 at 12:22, Paul Jakma wrote: > > Personally, I want a copyleft for the 'gitlab/github/gogs' era: Source > must be made available, unless you're on a desert island or there is a > credibly physical risk of imprisonment or harm to individuals by > disclosing their identity. The point is, made available to whom? To the users? Sure. Upstream? In a world where people happily hack their own software, this might open a can of worms upstream and downstream: - it would impose a review process (and infrastructure) for patches that would slow down development - it would disincentive hack for personal purpose for the burden to prepare a 3rd party readable patch In both case, strictly applied, such rule would create weird practical issues to free software. That's why the Hacking License assigns copyright and patent license upstream but without turning upstream copyright holders into Users. They can also become users, obviously, but they can also just benefit from the copyright assignment and patent license to reimplement similar behavior without legal issues. Giacomo
Re: Hacking License
On Tue, 11 Dec 2018, Paul Wise wrote: If you are talking about grsecurity, Had more personally significant cases in mind, not GrSec per se, but GrSecurity is an example, on the contract side. That said, wrt "abusive corporates", I'd put GrSec more on the /victim/ side, and I have some sympathy for them, but that's another discussion. ;) the contract from 2017 was on their website, is now on archive.org but the current version is not public: https://web.archive.org/web/20170805231029/https://grsecurity.net/agree/agreement.php That looks like the kind of side-agreement that would be good to clearly make impermissible or impossible to hold people to, while also wanting to avail of a copyleft licence - to me. Personally, I want a copyleft for the 'gitlab/github/gogs' era: Source must be made available, unless you're on a desert island or there is a credibly physical risk of imprisonment or harm to individuals by disclosing their identity. I think that would depend on the protocol used and that many of them would have room for extensions that could include instructions for obtaining source code. If you add an extension, how do you know the other supports that extension and showing it to the user? How do you show the user "interacted" with your software? Seems unreliable / risky / unlikely to achieve the goal, if tested. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Conceit causes more conversation than wit. -- LaRouchefoucauld
Re: Hacking License
Il giorno mar 11 dic 2018 alle ore 06:15 Paul Wise ha scritto: > > On Tue, Dec 11, 2018 at 1:45 AM Paul Jakma wrote: > > > There is an issue with the GPL style copyleft of abuse by corporates. In > > particular, abusing the ability to discharge source distribution > > privately, and then using various forms of side-contracts to > > (indirectly) "discourage" recipients from exercising their GPL rights. > > > > As this all happens in private, it makes it hard for copyright holders > > to take action. It can be hard to gather basic facts (e.g. the side > > contracts). The recipients - who are potentially having their GPL > > rights impinged - are not necessarily willing to even tell the > > copyright holders about this, never mind co-operate. Etc. > > If you are talking about grsecurity, the contract from 2017 was on > their website, is now on archive.org but the current version is not > public: If Linux was licensed under the Hacking License, the Grsecurity rights to modify it would be terminated by the introduction of the Stable Patch Access Agreement. However, Linus and all the Linux developers that had contributed before their target versions, would have had assigned their copyright on their patches, so they would be able to simply import them. Another GPL based practice and interpretation that the Hacking License wants to regulate is that of ExtJS a GPLv3 JavaScript library (originally derived by YUI) dual-licensed by Sencha. AFAIK there are two issue there (I'm not sure if they addressed them recently, but they used to be): 1. Sencha (ExtJS's copyright holder) states that any server-side code that produces ExtJS based code or data that must be fed to ExtJS based code, must be released as GPLv3 too. 2. Sencha releases as GPLv3 only the first major version and the first minor version of a new release, and only release as proprietary the code the successive minor versions (that can largerly extend the widget available). AFAIK, the GPLv3 interpretation that lead to 1 is VERY weak (it's basically lawyers-based power play), but Sencha does not accept external contributions to hold the rights for 2. If ExtJS (or a similar client side library in a distributed system) was released under the Hacking License, this would happen: 1. Server side code that produces/interacts ExtJS would form an Application and would be considered as a Wrapper, to be licensed with a compatible license (but not necessarily under the Hacking License). 2. If ExtJs was a Derived Work of a software release under the Hacking License, Sencha would have no right to keep any version proprietary. They would still have the right to sell copies of it or to sell bug fix priority token or support subscriptions... just not to private other hackers from hacking their Derived Work. Also, Sencha would grant all copyright holders of all the software they compose (including software under permissive licenses like MIT or BSD) the non-exclusive copyrights on ExtJS, so that if they had to misbehave, tons of people could legally take on their business model. The Hacking License is not designed to forbid commercial use of Free Software, but it's designed to put much stronger incentives to fair play. Giacomo
