8 ms·
Even more critically, dual-license commercial and AGPLv3 to avoid the AWS loophole (hosted services or source modifications without licensing it commercial.) A
by dystnitem4r3 2y ago
Even more critically, dual-license commercial and AGPLv3 to avoid the AWS loophole (hosted services or source modifications without licensing it commercial.)
AGPLv3 is perfect for kernel and userspace tools because, while it doesn't guarantee licensing revenues, as soon as they do anything to modify it they have to release those changes to ANY users of the system, whether downstream distributors or simply users of the network services they provide. Since they have to provide any IP/patents they used to do it under copyleft terms, QNX would get publicly visible benefits, albeit with changes that might not be useful under the commercial license without negotiating a CLA with the modifying party, but under the commercial license you could negotiate terms/a discount to trade their new code for a reduction in their cost of licensing. It's a win/win from either an open source PR or a behind the scenes commercial negotiation point. Obviously your lawyers, bean counters, and C-suite have to get onboard, but if you are serious about growing QNX's marketshare now that Linux is gaining real-time kernel support in mainline, you had better point out to your bosses they need to make the decision quick and stick to it, or there won't be a next time.
Edit: Adjustments made to clarify my position and suggestion.
- winocm 2y agoMy honest opinion is that the prevalence of licenses like GPLv3 and AGPLv3 end up indirectly leading to people recreating the wheel, rather than using the wheel that exists already.
- talldayo 2y agoI think wheel-reinvention is the perfect punishment for people that want to be stingy with their wheel development. Copyleft infringement deserves no more empathy than copyright infringement.
- karmakaze 2y agoWorking as intended. If they don't want to share, then they can't benefit.
- winocm 2y agoIt's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that. It applies to both sides of the argument, with organizations keeping things to themselves or others avoiding codebases for the inverse reason.
- fjkdlsjflkds 2y ago> It's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that. Given that this issue applies to all proprietary/non-opensource software, which is the overwhelming majority of software out there, you can hardly blame GPL3 for this fact of life.
- Brian_K_White 2y agoBut who cares if someone chooses to redo work they didn't have to? I don't care about that at all. Self inflicted wound. They presumably can salve that horrible wound with all the money they get (not make or earn, just get) from their chosen modus operundi.
- 0x0203 2y agoI would argue that in many ways (that vary from project to project) the duplicated efforts are a good thing overall. Now, instead of having one single group or person working on a particular topic, there are many and the knowledge, learning, experience, and expertise that comes from that isn't locked up with only a select few. That can be applied in more areas, used for more things, or carried into other endeavors. It also hedges against all that expertise being lost if the few experts of the original project abandon it for whatever reason. I don't see all the efforts that go into *BSD, Windows, macOS, etc... as being wasted just because Linux is available, nor would I consider the effort to try something completely new in os/kernel design that starts from a clean slate a waste, even if it doesn't end up becoming wildly popular. Not everyone who has the capacity to work on a duplicate effort would be able to contribute to the original, and the original will never be able to perfectly meet the goals/needs of everyone.
- lolinder 2y ago> AGPLv3 is perfect for kernel and userspace tools because, while it doesn't guarantee licensing revenues, as soon as they do anything to modify it they have to release those changes to ANY users of the system, whether downstream distributors or simply users of the network services they provide. This is actually fairly ambiguous in the text. It says "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version". This is fairly straightforward when applied to a database—if you modify an AGPL database and offer it as a hosted version then your users are obviously interacting with it over the network—but much less straightforward when talking about an AGPL program that doesn't intentionally build in network connectivity. The GPL FAQ addresses this provision [0] and it seems to support a more conservative reading. My understanding from the FAQ is that a Program that is not "expressly designed to accept user requests and send responses over a network" derives no benefit from being AGPL vs GPL, even if a web app interacts with that AGPL code over IPC or similar. [0] https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
- jraph 2y agoYep, I think the agplv3 behaves like the gplv3 for programs that are not network services. With the twist that if your non networked, agplv3 program happens to contain code that's interesting to build a network service, this code can only be used under the agplv3 :-)
- lolinder 2y ago> this code can only be used under the agplv3 :-) This code can only be used to make a derived work under the AGPLv3. What constitutes a derived work is still... complicated. I wouldn't risk this in a production setting for a real business just out of caution, but my reading of the license would suggest that you'd be perfectly fine to wrap AGPLv3 code in a web service and then have your own code interact with that web service. Release the wrapper service as AGPL, but then the rest can be proprietary. The main protection that AGPL gives isn't legal, it's that you scare most legal departments away just because it's such a weird license with no established precedent.