Zeronet: Fixing Licensing Issues

Created on 2 Nov 2019  ·  59Comments  ·  Source: HelloZeroNet/ZeroNet

Ok, so first we have our license violations. All of these have a license that's currently incompatible with ZeroNet's GPLv2 License:

  • Sidebar/media_globe/globe.js - Apache 2
  • pyelliptic - GPLv3
  • msgpack - Apache 2
  • rsa - Apache 2
  • gevent websocket - Apache 2
  • bencode.py - BitTorrent License
  • Coincurve - Apache 2
  • python-bitcoinlib

Now... I propose 2 steps that will solve all of this:

  1. Switch to GPLv3 license. This will allow for pyelliptic, python-bitcoinlib, and all Apache 2 licensed-libraries being used (Apache 2 is not compatible with GPLv2, but is compatible with GPLv3)
  2. Switch out bencode.py for an alternative that @imachug has just published to PyPi - https://pypi.org/project/bencode-open/

If you don't wish to change to GPLv3, then we need to find a way to replace all of the 8 libraries above, or we can switch out pyelliptic and python-bitcoinlib for an alternative and find a new license that is compatible with Apache 2.

Most helpful comment

For reference for anyone still wondering about patent issues in GPLv3: (CC: @0x6a73 )

https://www.gnu.org/licenses/quick-guide-gplv3.html says:

Stronger Protection Against Patent Threats

In the 17 years since GPLv2 was published, the software patent landscape has changed considerably, and free software licenses have developed new strategies to address them. GPLv3 reflects these changes too. Whenever someone conveys software covered by GPLv3 that they've written or modified, they must provide every recipient with any patent licenses necessary to exercise the rights that the GPL gives them. In addition to that, if any licensee tries to use a patent suit to stop another user from exercising those rights, their license will be terminated.

What this means for users and developers is that they'll be able to work with GPLv3-covered software without worrying that a desperate contributor will try to sue them for patent infringement later. With these changes, GPLv3 affords its users more defenses against patent aggression than any other free software license.

https://www.gnu.org/licenses/rms-why-gplv3.html also says:

Another threat that GPLv3 resists is that of patent deals like the Novell-Microsoft pact. Microsoft wants to use its thousands of patents to make users pay Microsoft for the privilege of running GNU/Linux, and made this pact to try to achieve that. The deal offers rather limited protection from Microsoft patents to Novell's customers.

Microsoft made a few mistakes in the Novell-Microsoft deal, and GPLv3 is designed to turn them against Microsoft, extending that limited patent protection to the whole community. In order to take advantage of this protection, programs need to use GPLv3.

Microsoft's lawyers are not stupid, and next time they may manage to avoid those mistakes. GPLv3 therefore says they don't get a “next time”. Releasing a program under GPL version 3 protects it from Microsoft's future attempts to make redistributors collect Microsoft royalties from the program's users.

GPLv3 also provides users with explicit patent protection from the program's contributors and redistributors. With GPLv2, users rely on an implicit patent license to make sure that the company which provided them a copy won't sue them, or the people they redistribute copies to, for patent infringement.

The explicit patent license in GPLv3 does not go as far as we might have liked. Ideally, we would make everyone who redistributes GPL-covered code give up all software patents, along with everyone who does not redistribute GPL-covered code, because there should be no software patents. Software patents are a vicious and absurd system that puts all software developers in danger of being sued by companies they have never heard of, as well as by all the megacorporations in the field. Large programs typically combine thousands of ideas, so it is no surprise if they implement ideas covered by hundreds of patents. Megacorporations collect thousands of patents, and use those patents to bully smaller developers. Patents already obstruct free software development.

The only way to make software development safe is to abolish software patents, and we aim to achieve this some day. But we cannot do this through a software license. Any program, free or not, can be killed by a software patent in the hands of an unrelated party, and the program's license cannot prevent that. Only court decisions or changes in patent law can make software development safe from patents. If we tried to do this with GPLv3, it would fail.

Therefore, GPLv3 seeks to limit and channel the danger. In particular, we have tried to save free software from a fate worse than death: to be made effectively proprietary, through patents. The explicit patent license of GPLv3 makes sure companies that use the GPL to give users the four freedoms cannot turn around and use their patents to tell some users, “That doesn't include you.” It also stops them from colluding with other patent holders to do this.

The tl;dr is that, indeed, the GPLv3 is better than GPLv2 if you oppose software patents.

All 59 comments

Btw, I think if we go the GPLv3 route, we should only do GPLv3-only and not "plus".

Also, if we have the ability to replace pyelliptic (btw, the original repo for pyelliptic is BSD - the PyBitcoin version is GPLv3), then I would actually prefer that.

It might be better to switch out pyelliptic now since the official repo is deprecated. And it's the main stopping block for other licenses that we could switch to.

PyElliptic's original author suggested this as alternative. It is dual-licensed under Apache or BSD. There are also some other alternatives.

Unfortunately, cryptography dropped support for some common OpenSSL versions.

Let me collect all the issues we have found so far.

  1. bencode.py. It uses BitTorrent Open Source License which is incompatible with GPL but I've made my own package that does the same.
  2. msgpack-python. Apache 2.0.
  3. gevent-websocket. Apache 2.0.
  4. maxminddb. Apache 2.0.
  5. globe. Apache 2.0.
  6. rsa. Apache 2.0.
  7. pyelliptic. This is GPLv3 only but it's a fork. The original library is MIT. This means that it should be fairly easy to fork the original library and make it compatible with the current pyelliptic version whilst still using MIT license.
  8. python-bitcoinlib. This is GPLv3+. That's not a big problem but we might want to change this if we retain GPLv2.

We have to get rid of bencode.py for sure.


Then, if we switch to GPLv3, we'll automatically resolve all the problems. However, asking all contributors for permission might take a lot of time. Here's a list of all contributors (except @shortcutme/@HelloZeroNet):

  1. imachug (63 commits)
  2. tangdou1 (24 commits)
  3. TheNain38 (23 commits)
  4. cclauss (23 commits)
  5. rllola (29 commits)
  6. MuxZeroNet (18 commits)
  7. lmath (17 commits)
  8. redfish (15 commits)
  9. Matthew Bell (12 commits)
  10. sirMackk (10 commits)
  11. Idealcoder (8 commits)
  12. 0polar (6 commits)
  13. daniell (6 commits)
  14. filips123 (6 commits)
  15. grez911 (6 commits)
  16. anoadragon453 (6 commits)
  17. Ashley Perpetual (5 commits)
  18. Barrabin Fc. ⚑ (5 commits)
  19. Felix Imobersteg (5 commits)
  20. OliverCole (5 commits)
  21. Sergei Bondarenko (5 commits)
  22. ysc3839 (5 commits)
  23. Kûipumu (4 commits)
  24. Th3B3st (4 commits)
  25. Thibaut Broggi (4 commits)
  26. Vadim Ushakov (4 commits)
  27. cxgreat2014 (4 commits)
  28. erqan (4 commits)
  29. iShift (4 commits)
  30. radfish (4 commits)
  31. Arthur Poulet (3 commits)
  32. krixano (3 commits)
  33. Maciej Krüger (3 commits)
  34. Nathan Tym (3 commits)
  35. Richard Yu (3 commits)
  36. frerepoulet (3 commits)
  37. krzotr (3 commits)
  38. l5h5t7 (3 commits)
  39. aitorpazos (2 commits, #587)
  40. TigerND (2 commits, #96)
  41. barrabinfc (2 commits, #278)
  42. yowmamasita (2 commits, #292)
  43. Biosias (2 commits, #1469 and #1179)
  44. reezer (2 commits, #867 and #868)
  45. danielquinn (2 commits, #50)
  46. xfq (2 commits, #1155 and #863)
  47. gyulaweber (2 commits, #371 and 607)
  48. HostFat (2 commits, #664 and #665)
  49. JeremyRand (2 commits, #1444 and #1445)
  50. volker48 (2 commits, #36)
  51. Mathieu Tortuyaux / AwesomeTurtle (2 commits, #890) Dead account
  52. rarbg (2 commits, #121)
  53. ppsfassa (2 commits, #1421)
  54. brunogarciavaz (2 commits, #856)
  55. caryoscelus (2 commits, #2218 and #1800)
  56. mishfit (2 commits, #912 and #842)
  57. vitorio (2 commits, #1479)

and 56 more contributors with 1 commit. If we really want to switch the license, we'll probably need to ask all these people.

Sidenote: I've looked through a few accounts with 2 commits and marked them with related PRs. We might want to spend some time removing their code from ZeroNet, especially from dead accounts. I also didn't use @ not to ping all of them before it's the right time.


On the other hand, we can replace our incompatible dependencies:

  1. msgpack-python. There's u-msgpack-python which I haven't looked at yet but it's MIT.
  2. gevent-websocket. No idea yet, probably rewriting it from scratch is the way to go.
  3. maxminddb. We only use that for IPs so it shouldn't be difficult to change the format to something else.
  4. globe. No idea yet.
  5. rsa. We use OpenSSL already so it shouldn't be difficult to use OpenSSL's RSA.
  6. pyelliptic. This is a thin wrapper on top of OpenSSL. It shouldn't be difficult to make our own wrappers (I've worked on a similar task before, check one of my pyelliptic-related PRs)
  7. python-bitcoinlib. This is a big wrapper on top of OpenSSL. It will probably take a while to make it work but it's only time-consuming and should be easy to do.

I'd recommend to start with replacing msgpack-python, gevent-websocket and maxminddb. After that, we'd replace pyelliptic and rsa. (@HelloZeroNet: Can we assume that all users have OpenSSL or do we need a pure-Python fallback?) After that, we'd replace python-bitcoinlib and globe. It will probably take some time to fix the last part (i.e. globe), so we can side-load the globe (say, via ZeroHello) and show a "would you like to" message to user before downloading it.

Libsecp256k1 seems to be small enough for a single person to create and maintain a wrapper. I agree with your dependency replacement option. I have taken a look at u-msgpack-python and it seems like it's quite mature and still maintained, so it might be worth to try to use it.

It looks like u-msgpack-python is pure-python which means that it's rather slow. We should try to make a wrapper on top of the C library.

To add on to what imachug is saying, the C library, magpack-c, is Boost Software License which is a very permissive non-copyleft license that is compatible with most things.

Wasn't the last version of pyelliptic relicensed to a 2-clause BSD license though?
https://github.com/yann2192/pyelliptic/commit/5604cf3788ac40972df1c412abf327e065709c21

@0x6a73 ZeroNet uses fork from BitMessage which is licenced under GPLv3. Original pyelliptic was also using GPLv3, but switched to BSD at some later point.

Hello. I hereby relicense my contributions to this repo under GPLv3+. I'm happy to provide an OpenPGP-signed statement to that effect if you request it.

@JeremyRand Great, thanks for confirming.

@0x6a73 It looks like in another issue (which I won't link to since that issue is a shitshow), you said something about the patent-related provisions in GPLv3 being potentially objectionable. Any chance you could elaborate on that point? This is a new concern to me, and I'm curious what info you can provide.

@JeremyRand As far as I know, GPLv2 doesn't allow ZeroNet to be used in patents, while GPLv3 allows that. That's why @HelloZeroNet has expressed his lack of approval for switching to GPLv3. Here's a quote from that thread addressing that issue:

Antifa: Upgrading to GPLv3 allows me and anyone else to use ZeroNet in patents if we wish and the current GPLv2 is a threat against me and others from Hungary.
krixano: This is why I oppose GPLv3. Patents are aweful and disgusting. So, if there's any way we can remove this "upgrade to v3" ability, I'll support it.

As an aside, not to put pressure on you guys, but we're intending to apply for funding from NLnet regarding Namecoin improvements that are targeted at improving ZeroNet integration (I haven't spoken to Tamas about this yet, but will soon), and license issues are almost definitely something that NLnet will want resolved prior to awarding funds, and probably even prior to committing funding to a project. So, I do hope that these issues can be worked out as soon as reasonably achievable.

@JeremyRand As far as I know, GPLv2 doesn't allow ZeroNet to be used in patents, while GPLv3 allows that. That's why @HelloZeroNet has expressed his lack of approval for switching to GPLv3. Here's a quote from that thread addressing that issue:

Antifa: Upgrading to GPLv3 allows me and anyone else to use ZeroNet in patents if we wish and the current GPLv2 is a threat against me and others from Hungary.
krixano: This is why I oppose GPLv3. Patents are aweful and disgusting. So, if there's any way we can remove this "upgrade to v3" ability, I'll support it.

@0x6a73 I'm almost certain that this is bullshit from the troll account and that GPLv3 doesn't do what he's insinuating, but lemme look into it more closely and I'll get back to you.

@JeremyRand Thanks for clarifying. Still, it might be a problem to relicense the whole project to GPLv3 due to commiters whose accounts are deleted or dead, as they have to state their will for the change to GPLv3 too. If there's a solution to that problem though, I have no problems with switching to GPLv3 then.

@0x6a73 AFAICT he's probably referencing this: https://www.gnu.org/licenses/gpl-faq.html#v3PatentRetaliation

Does GPLv3 have a “patent retaliation clause”?

In effect, yes. Section 10 prohibits people who convey the software from filing patent suits against other licensees. If someone did so anyway, section 8 explains how they would lose their license and any patent licenses that accompanied it.

Which, AFAICT, means that GPLv3 is actually better than GPLv2 if you oppose software patents.

@JeremyRand Oh, great. I'm for switching to GPLv3 then. However, how do we resolve the previously mentioned dead account issue then?

@JeremyRand Thanks for clarifying. Still, it might be a problem to relicense the whole project to GPLv3 due to commiters whose accounts are deleted or dead, as they have to state their will for the change to GPLv3 too. If there's a solution to that problem though, I have no problems with switching to GPLv3 then.

@0x6a73 I mean, if I were you, I'd first try to contact the relevant contributors before spending too much effort on this. There's a good chance that most of the contributors will be fine with a relicense and are reachable either via GitHub ping or via the email address in their Git commits' metadata. Once you have a better knowledge of how much code would potentially have to be re-written in order to licence to GPLv3, then you can make much more informed and useful decisions than is possible right now.

Also, I'd recommend that if project leadership wants to switch to GPLv3 in the future, you should at least require newly contributed code to be licensed under both GPLv2 and GPLv3, so that the problem doesn't grow over time as you try to re-implement whatever code is needed.

@0x6a73 More specifically: A GitHub account may be dead, but the email address in the Git commit metadata may still be reachable.

For reference for anyone still wondering about patent issues in GPLv3: (CC: @0x6a73 )

https://www.gnu.org/licenses/quick-guide-gplv3.html says:

Stronger Protection Against Patent Threats

In the 17 years since GPLv2 was published, the software patent landscape has changed considerably, and free software licenses have developed new strategies to address them. GPLv3 reflects these changes too. Whenever someone conveys software covered by GPLv3 that they've written or modified, they must provide every recipient with any patent licenses necessary to exercise the rights that the GPL gives them. In addition to that, if any licensee tries to use a patent suit to stop another user from exercising those rights, their license will be terminated.

What this means for users and developers is that they'll be able to work with GPLv3-covered software without worrying that a desperate contributor will try to sue them for patent infringement later. With these changes, GPLv3 affords its users more defenses against patent aggression than any other free software license.

https://www.gnu.org/licenses/rms-why-gplv3.html also says:

Another threat that GPLv3 resists is that of patent deals like the Novell-Microsoft pact. Microsoft wants to use its thousands of patents to make users pay Microsoft for the privilege of running GNU/Linux, and made this pact to try to achieve that. The deal offers rather limited protection from Microsoft patents to Novell's customers.

Microsoft made a few mistakes in the Novell-Microsoft deal, and GPLv3 is designed to turn them against Microsoft, extending that limited patent protection to the whole community. In order to take advantage of this protection, programs need to use GPLv3.

Microsoft's lawyers are not stupid, and next time they may manage to avoid those mistakes. GPLv3 therefore says they don't get a “next time”. Releasing a program under GPL version 3 protects it from Microsoft's future attempts to make redistributors collect Microsoft royalties from the program's users.

GPLv3 also provides users with explicit patent protection from the program's contributors and redistributors. With GPLv2, users rely on an implicit patent license to make sure that the company which provided them a copy won't sue them, or the people they redistribute copies to, for patent infringement.

The explicit patent license in GPLv3 does not go as far as we might have liked. Ideally, we would make everyone who redistributes GPL-covered code give up all software patents, along with everyone who does not redistribute GPL-covered code, because there should be no software patents. Software patents are a vicious and absurd system that puts all software developers in danger of being sued by companies they have never heard of, as well as by all the megacorporations in the field. Large programs typically combine thousands of ideas, so it is no surprise if they implement ideas covered by hundreds of patents. Megacorporations collect thousands of patents, and use those patents to bully smaller developers. Patents already obstruct free software development.

The only way to make software development safe is to abolish software patents, and we aim to achieve this some day. But we cannot do this through a software license. Any program, free or not, can be killed by a software patent in the hands of an unrelated party, and the program's license cannot prevent that. Only court decisions or changes in patent law can make software development safe from patents. If we tried to do this with GPLv3, it would fail.

Therefore, GPLv3 seeks to limit and channel the danger. In particular, we have tried to save free software from a fate worse than death: to be made effectively proprietary, through patents. The explicit patent license of GPLv3 makes sure companies that use the GPL to give users the four freedoms cannot turn around and use their patents to tell some users, “That doesn't include you.” It also stops them from colluding with other patent holders to do this.

The tl;dr is that, indeed, the GPLv3 is better than GPLv2 if you oppose software patents.

@JeremyRand Ok... so in antifa's issue, I disagreed about the whole patenting thing for GPLv3. However, I did not know about this (I don't think he ever quoted this while I was still looking at the issue - perhaps someone has after my last comment, when I stopped looking at that issue):

In addition to that, if any licensee tries to use a patent suit to stop another user from exercising those rights, their license will be terminated.

My main concern was about contributors patenting and suing other contributors or forks for their own contributions. In this case, it looks like this protects against that, so I think GPLv3 is fine, so I would be fine with a change to GPLv3 as long as @HelloZeroNet (and everyone else obviously) is fine with it.

I just want to give an update on what @imachug is doing - he's currently rewriting one of the GPLv3 libraries (pyelliptic), just in case @HelloZeroNet might not want to go with GPLv3. Additionally, this library is outdated anyways, so it needs rewritten.

I'll wait for @HelloZeroNet 's opinion on this matter. Also, if we choose to proceed with an alternative license, I'm ready to help create new, permissively licensed Python libraries/bindings for Bitcoin-related libraries, as I've worked in the past both with/on libsecp256k1 and some Bitcoin-related programs and libraries.

I'm not a fan of copyleft licenses (I prefer MIT/ISC/BSD licenses), but I believe that it's a right thing to leave the final decision on the future of this project to @HelloZeroNet . As explained in this post, in both cases his decision is what matters right now:
https://github.com/HelloZeroNet/ZeroNet/issues/2268#issuecomment-549160864

I personally think that copyleft is only good for software and not libraries. I was just talking with @filips123 about him thinking that parts of ZeroNet could be released as MIT. I agree with this if parts of ZeroNet could be libraries, in which case I mentioned to him that we could separate these out to other repos (like @imachug did with the bencode alternative he made).

In my point of view a library is not part of the application, so there is no license issue, but I would support change the license to MIT, GPLv3 or any other similar license to make it more clear.

@HelloZeroNet I would recommend to modularize ZeroNet a bit more (#2063). Then "one part" (but multiple libraries) would be internal ZeroNet libraries (licensed under MIT) and another part would be a program (licensed under GPL). This would also make ZeroNet mode embeddable (and hopefully more popular) as developers won't have to worry about all license issues.

@HelloZeroNet @filips123 emailed FSF to see if that is true or not (whether Pypi packages' licenses need to be followed).

Btw here is the list of the contributors by active code line number: https://gist.github.com/HelloZeroNet/8fe032e877fe9fe7395357debd2a904e

Does that count displaced/replaced code or something like that?

And contributors whose code was replaced/deleted?

@shortcutme @HelloZeroNet I've made a simple license change utility. You can check it on test data here. Do you think we could use that for this repository?

Ok, I've started the bot on issue #2271 so that we can track who would accept a license change and what license they would accept.

Ok, we had to redo the poll, so now everyone please vote on the new issue here: #2273

I'm not a fan of copyleft licenses (I prefer MIT/ISC/BSD licenses), but I believe that it's a right thing to leave the final decision on the future of this project to @HelloZeroNet .

I was just talking with @filips123 about him thinking that parts of ZeroNet could be released as MIT. I agree with this if parts of ZeroNet could be libraries, in which case I mentioned to him that we could separate these out to other repos

I would support change the license to MIT, GPLv3 or any other similar license to make it more clear.

i see ya'll got together and decided to re-license this whole thing? where have i been?

__+1 for MIT (if at all possible)__

@d14na You can vote for a license on issue #2273

@krixano __voted!__ i like what i see ya'll doing here lol

__question:__ what sort of "libraries" would fall under LAX? i'm ready to push some code after the dust settles

Notice: "Lax/Permissive license" does not include Public Domain licenses. They do, however, include BSD 2/3, MIT, ISC, and Apache-2.0

MIT, GPL, and Apache are the 3 most used licenses on github I believe. BSD is also probably up there.

@HelloZeroNet Can you close the locked issues (#2265 #2268 #2270)? The issue tracker is polluted with license issues now.

You all fell for a troll. There are hundreds of p2p systems and applications and chances that Zeronet licensing will be anyhow important is very low. There are many caveats in licensing and copyright laws and you are wasting your effort on dealing with unimportant things. Now you will have to watch for every commit and library included.
There's even a slim chance that antifa is assigned to disrupt freedom related projects as he/she/it can respond 24/7.
I would put the enhancement tag on the licensing issue and dealt with it with lowest priority.

@krzysztof113

Sure.. ZeroNet is probably low on the list, but we should try to remain legal. Finally, even with the incompatibility issues, there are other reasons for upgrading the license to GPLv3. For example, some people might prefer GPLv3 because of the patent retaliation protections. Some people also might not even want GPL at all. The vote allows nofish and everyone else to say what they think is best and possibly reach a consensus on this. As far as I'm concerned, this is not "unimportant".

@krixano have you considered simply not changing license?
for more info on what this would cause, see here
there are various big projects already doing similar, like the FFMPEG media processing tool / converter or the Spigot serverside modding API for Minecraft

@namazso Have you simply read the original body post for this issue?

If we don't change the license we have to get rid of or replace 8 dependencies.

Now, I don't know if pypi packages count or not with this whole licensing stuff, so it'd be nice to get clarification on that aspect.

Finally:

even with the incompatibility issues, there are other reasons for upgrading the license to GPLv3.

@krixano as far as I'm aware, those are only libraries (read: independent works) and not part of the ZeroNet core code. Was any code from them copypasted into ZeroNet code? If not, they still are independent works, which can have their own license. The only problem arising is that obviously at some point you want to link them together, and distribute the result, which would indeed be a violation. To solve this, you can provide tools for users to build ZeroNet themselves on their own machine. I'm wondering if you have simply read my previous post.

I'm not saying GPLv3 wouldn't be better, but considering the hassle, I'm not sure if it's worth it.

What about this though:

But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

What does "work based on the program" mean. ZeroNet can't really function without the libraries it uses, especially msgpack which is one of the violations I believe.

but considering the hassle, I'm not sure if it's worth it.

Commenting on a post to see if we have a consensus isn't really a hassle. It takes like 5 seconds to comment your vote.

The only problem arising is that obviously at some point you want to link them together, and distribute the result, which would indeed be a violation. To solve this, you can provide tools for users to build ZeroNet themselves on their own machine. I'm wondering if you have simply read my previous post.

Of course I read this, it's just stupid, sorry (but not really sorry).

@namazso @krixano

Now, I don't know if pypi packages count or not with this whole licensing stuff, so it'd be nice to get clarification on that aspect.

I contacted FSF if they allow using projects with incompatible licenses as PyPI packages/dependencies in the GPLv2-licensed project (also with some other questions). They haven't answered yet as their response may take a few days.

However, ZeroBundle could still be a problem. I also asked FSF about this.

even with the incompatibility issues, there are other reasons for upgrading the license to GPLv3.

Here I would also say that another thing we should/could do when updating licenses would be to split ZeroNet into libraries and release libraries as MIT/BSD/similar license and main program as GPL. This would enable developers to develop third-party solutions for ZeroNet without having to worry about license incompatibilities.

So I recommend you to vote for "GPLv3 and Lax" option. Voting is your opinion of course so you can also chose other options if you want.

What does "work based on the program" mean.

I am pretty certain that code that does not include any such licensed code at all cannot be considered to be a work based on the program.

ZeroNet can't really function without the libraries it uses, especially msgpack which is one of the violations I believe.

The point is, you can distribute independently non-functioning code, then the user can make it functioning on their own machine. You can even provide tools that help this. Look at Spigot for example: obviously a Minecraft server modding API cannot work without the Minecraft server, but their licenses are incompatible. They provide the build tools that you can use to build your own binary (redistribution of which would be illegal though).

The point is, you can distribute independently non-functioning code, then the user can make it functioning on their own machine.

If we're requiring users to do this, then this is a dumb idea. Why would we sacrifice user experience just because developers don't want to put in the work to make their product actually good. Typical Unix mindset if you ask me....

@namazso But this won't be good for normal users which don't know much about programming and building/compiling programs. And one thing that ZeroNet really needs to be popular is an easy way to install and use it.

Also, licensing core ZeroNet libraries as Lax would also enable third-party developers to implement custom ZeroNet solutions, just like some developers are already using IPFS to build custom solutions (which is dual-licensed MIT/Apache2). In case if ZeroNet core libraries would remain GPLv2, that developers would have to worry about all license incompatibilities too much. But main program would be still licensed as GPL as it probably won't be meant to be used in third-party solutions so much.

The only thing we need to switch to GPLv3 and fix all the violations is to get consensus from all contributors. That's it. We have around 107 contributors and quite a lot have responded so far.

I'm indeed not sure how difficult it would be to write an "installer" that does all the hassle of pulling the libraries and building ZeroNet automatically would be, or how much time/space/bandwidth such installer would take compared to the current one.

I guess the voting has already begun anyways, so just hope for the best that about all of the contributors agree on something.

I'm indeed not sure how difficult it would be to write an "installer" that does all the hassle of pulling the libraries and building ZeroNet automatically would be, or how much time/space/bandwidth such installer would take compared to the current one.

We first need to wait if FSF considers this as accepted. If so, we will probably do this for ZeroBundle. For source code installation, PyPI will also mostly cover this (and PyPI can probably also be embedded to ZeroBundle if needed).

Btw, we don't need 100% of contributors to agree. Other projects like Firefox went through software re-licensing and they only got 95% consensus.

You can see this is the Wikipedia page for Software Re-licensing.

@krixano It would be good to tell this to antifa, lol

This is a bit unrelated, but I'm putting this up here because I already know that the post is going to be deleted:

Screenshot from 2019-11-08 20-01-50

@HelloZeroNet As we have replaced bencode.py with bencode_open and all the cryptography libraries with sslcrypto, I believe all the libraries are GPLv3-compatible now. I guess this issue can be closed now and the only thing left is to make sure we don't have any contributions which weren't (re-)licensed under GPLv3 in #2273.

@HelloZeroNet Do you think this issue can be closed?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sermont picture sermont  ·  3Comments

DaniellMesquita picture DaniellMesquita  ·  3Comments

Forbo picture Forbo  ·  3Comments

jerry-wolf picture jerry-wolf  ·  4Comments

sergei-bondarenko picture sergei-bondarenko  ·  3Comments