Hacker News Reader

Comment by echelon | Hacker News Reader

GPLv4 needs to address a number of new problems:

* "any user data serviced by this software must be easily exportable; no attempt must be made to block other 3rd party companies or services from consuming this data"

* "if this software is itself sold as a service, any automation or tooling built in service of this system must also be made available as open source"

* "any devices using this software must not actively prevent or prohibit users from running their own software"

View on HN

It’s like a catch-22 though. If I start a company using open source and must give away the software I then build on top of it as open source then I likely fail to capture revenues and my company fails.

What would be a nice option in GPL 4 is a mandatory commercial licensing fee structure to pay either to author of software or to EFF / FSF if the author doesn’t provide payment details. That would give a commercial incentive to startups to pursue using open source AND provide real revenues back to the community.

> It’s like a catch-22 though. If I start a company using open source and must give away the software I then build on top of it as open source then I likely fail to capture revenues and my company fails.

How is that the open source author's problem? Open source is meant to enable user freedom, not to save corporations money. If you want to use something, contact the author and get a commercial license.

I agree. I guess what's missing is some coordination mechanism for the "contact the author and get a commercial license" part. If it's one author it's easy, but if it's eighty, it's hard to contact each even if they would all be willing to provide such a license.

That's not a problem of open source itself, of course.

If you want to dual license, you probably should have a contributor license agreement. (It may be possible to relicense absent such an agreement, especially if it's permissively licensed, but a CLA certainly makes things clearer.)

It's a problem for the community that it still creates no long term motive for people to invest in the code. There needs to be sustainability (profits) that funnel back into the community somehow.

Two of those are already in the GNU AGPLv3 (2007).

last one is sort of basically what GPLv3 has.

This is a bad idea. All licenses released under GPLvX or later where X<4 will be not affected by this as the company could always pick X. It would further increase license fragmentation in the GPL sphere which is one of the reasons why BSD style licenses became more popular. I'd recommend looking into Rob Landley and why he created 0BSD. [1]

The whole reason why we are in this mess and why GPL died is because the people behind GPL wanted to push their political views using the weight of persons using GPLv2 or later. The Linux kernel reacted by switching GPLv2 only. The only reason why would might want to name it GPLv4 is to use the weight of code of GPLvX or later people. Don't do that In addition some of you clauses have been shown to be easily enforceable by laws like GDPR and attempting to use contract is a crutch. They way to some of your points is phrased might be unenforceable in court and might void the complete license if it is ever testing in court. -> very bad

[1] https://youtube.com/watch?v=MkJkyMuBm3g somewhere around 25 min it starts

What about actually including a clause about pushing your changes upstream because from my recent HN readings, that clause is not present.

The source code has to be provided. From this, one can easily generate a diff. The only thing that such a clause will do is having to inform the original maintainer of this.

But I don't think that such a clause is a good idea: very often these internal modifications are not of the required quality. Also, I can easily imagine that some projects might drown in low-quality upstream pushes.

Bug fixes is what I am thinking about.

It is often not clear what is a bug and what is "unexpected/surprising (but 'correct') behavior". Also, many bug fixes of authors that don't have a good understanding of the code cause lots of additional regressions or don't fit the original architecture of the software well.

GPLv4 cannot exist. The GPL was a clever hack the first time it became popular, but it is fundamentally a singleton that cannot be instantiated more than once.

Not like we didn't try.

Which is why we have three versi…oh, wait.

I'm curious, why not?

For projects with copy-left license one has to contact all contributors and ask for their permission to relicense:

https://opensource.stackexchange.com/questions/33/how-can-a-...

Most of the time, when you license something under GPLv3, you explicitly allow for later versions of the GPL. The "either version 3 of the License, or (at your option) any later version." part was famously removed in the Linux kernel.

This clause is a bit dangerous -- if a bad actor gets control of the FSF and manages to release an official GPL version that is completely bonkers, all current GPL-or-later software can be distributed under that license.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

This has nothing to do with copyleft outbound licensing.

If you have BSD-style outbound licensing and you assume that all inbound copyright is transferred to you, you will wake up in court after you try to change the outbound license conditions of someone else's copyrighted code.

The correct answer is that for any project in which there is no inbound contribution agreement in place, you would have to contact all contributors and seek their permission to relicense.

Inbound and outbound licensing are orthogonal.

Reply on news.ycombinator.com