3 ms·
I think at this point the vast majority of linux users are indifferent to the difference between copyleft and non-copyleft licenses (and of those that do care,
by rcxdude 3y ago
I think at this point the vast majority of linux users are indifferent to the difference between copyleft and non-copyleft licenses (and of those that do care, they are likely to lean against copyleft). Whether this project actually has enough advantages (and small enough disadvantages: compatibility still seems to be far from complete enough) to be adopted by users or distributions is another matter, though.
- denotational 3y ago> and of those that do care, they are likely to lean against copyleft What is this based on? Asking in good faith.
- rcxdude 3y agoMy impression that the vast majority of linux users who are thinking about code licensing are using it commercially and so copyleft represents an extra burden on them. (also, IMO, copyleft vs non-copyleft doesn't seem to make a huge difference to the outcomes copyleft advocates claim to care about, especially to the average user - most MIT licensed projects still generally receive contributions from people using them commercially, and some GPL projects (linux itself suffering from this greatly) still suffer from being fragmented by proprietary patches and forks, even if the license is being complied with.)
- zelphirkalt 3y agoI would say copyleft licenses can even be better for a business, since they make sure, that competitors cannot grab and run, but need to contribute back. Businesses just need to understand, that copyleft also applies to the competition, when they use copyleft licensed projects.
- cmrdporcupine 3y agoAgreed, and as a friend pointed out to me years ago, there's nothing stopping people who author GPLd code from making it clear that if a corporation wants a different licensing arrangement for something that's under GPL, they're perfectly capable of negotiating that with the author and paying for it. That this doesn't happen often shows the motivation of most companies using open source is ultimately ... just looking for free work.
- insanitybit 3y ago> That this doesn't happen often shows the motivation of most companies using open source is ultimately ... just looking for free work. Entering into contracts is really annoying. Companies don't just hand out checks, they have accountants who ask "what is this for, how is it being spent, how do we pay taxes on it", etc. "Pay this random developer that you have no pre-existing relationship with" is not as trivial as it sounds.
- Someone 3y agoThere’s also “how do we know they’ll be around three years from now for support?”. Working with a company feels more secure in that respect, especially if that company is large and reasonably old. The “this” in “That this doesn't happen often” can also refer to “people who author GPLd code from making it clear that if a corporation wants a different licensing arrangement” not happening very often. Yes, there are projects that explicitly mention it, but I think those are in the minority.
- _flux 3y agoThis can only happen if they are truly making the project only themselves and accepting external contributions only via a CLA—and I expect the mere existence of CLA to reduce the amount of external contributions in itself.
- cmrdporcupine 3y agoYes that's a fair point. If I recall Googlers are just completely forbidden from contributing to projects with a CLA.
- rcxdude 3y agoIt's rare that this weighs heavily compared to the administrative burden of complying with the GPL. Most open-source code (especially things like coreutils) is effectively commons: something which many companies rely on but doesn't represent a competitive edge to them. So there's already a strong incentive to contribute upstream: it's easier than trying to maintain your own fork. A competitor hoarding their own contributions is more likely to be shooting themselves in the foot than giving themselves an edge.
- nindalf 3y ago> most MIT licensed projects still generally receive contributions from people using them commercially I agree. I’d speculate that projects being hosted on GitHub is a big part of that. With the code and discussions around it happening in the open, and the barrier to contribute substantially reduced it’s hard to justify forking it internally and maintaining the fork. The path of least resistance is to clone it from GitHub every time and to contribute changes back, regardless of license. For most projects we don’t need the GPL to compel this behaviour because that’s not what many (but not all) companies are doing in any case. This isn’t a blanket statement though. Obviously the size of the project matters, the scope of the changes made etc. For example phone manufacturers always fork Android and add their changes on top. They only release the code to be compliant with the GPL, and they do so grudgingly. Having Linux licensed under GPL benefits us. But other projects? Doesn’t make a difference. Who is forking (for example) git and making private improvements they don’t contribute back? No one. It would be just as feature filled, useful and successful whether it was MIT or GPL.
- palata 3y ago> most MIT licensed projects still generally receive contributions from people using them commercially My experience working professionally in a permissive open source project is that the vast majority of commercial use is not contributed back (very often it would be very low quality anyway). > some GPL projects (linux itself suffering from this greatly) still suffer from being fragmented by proprietary patches and forks I don't see this as an argument in favour of permissive licences: proprietary patches and forks are also happening with permissive licences.
- palata 3y ago> My impression that the vast majority of linux users who are thinking about code licensing are using it commercially and so copyleft represents an extra burden on them. My impression is that it is like wearing a face mask when you are sick. You should wear a mask to protect the others, but people generally don't give a shit. There is no extra burden in choosing a copyleft license for your project (you still have the copyright, you can do whatever you want with it). What creates extra burden is when you use copyleft dependencies. But that's not your choice. And as a user, I'm pretty sure you are happier if code that you don't own is open source. All devs should push for copyleft licenses because it benefits them as users. But for some reason many are pushing for whatever is best for companies who employ them.
- roenxi 3y agoThe vast majority of Linux users are indifferent to lots of important things, operating systems are complex and there are too many parts to keep abreast of. However, the foundations are largely GPL-licensed because the GPL is superior in the long term. If people want to donate their time to companies then good luck to them, but it is a stupid strategy to donate free time to companies. If a company is paying good money for someone to write BSD-licensed software then sure, but otherwise the developer is playing a mug's game. Not a universal rule, I can see why some crypto or standard reference libraries might want to be BSD licenced. But by and large it is an invitation for parasites to attach.
- cmrdporcupine 3y agoAgree, tho worth pointing out that GPL licensed software is still subject to parasitical behaviour from SaaS companies. While the AGPL can plug that, it is very unpopular.
- KingLancelot 3y ago[dead]
- Snow_Falls 3y agoHell, even library type software could be licensed under "weak" copyleft license such as LGPL.
- palata 3y agoOr worst case even MPLv2!
- rejschaap 3y agoI would expect more permissive licenses in the future. GPL was instrumental in changing the world to an open source mindset. It fixed the problems with software that became obvious in the 90s. The world has evolved and the restriction just feel outdated now.
- pas 3y agoSure, users shouldn't care. The ecosystems ought to serve the users after all, and it should be sustainable, competitive with other ecosystems, etc. But all these instrumental goals are on the developers, and if carefully choosing licenses for each project can help with this, then it makes sense to pay attention to which project has which license. Coreutils? Probably here the importance is to provide the interface the users want. And provide it everywhere thus allowing the ecosystem to grow and be able to move to other platforms even. This might require a BSD-like license. (These tools evolve slowly, and usually doesn't represent some huge know-how that other ecosystems want to lift, here the well-known efficient CLI experience is the value, which might be fair-use copyable, but as we see - for example Apple - doesn't care, and thus basically users are left with worse defaults.) Filesystems? Stability, cross-platform compatibility, but also usually decades of extremely valuable battle-testing culminates in a specific codebase+ecosystem context. It's hard to replicate with simple copying, but of course much easier. In practice with ZFS we see that the licensing incompatibility serves to provide fewer options for users. Drivers? Databases? Kernel? Where does the TiVo problem rears its ugly head? And what does the relative lackluster GPL enforcement track record tells us here? What about the more important problem with non-upstreamed but-shitty-as-fuck Android drivers? Are they good or bad for users? Which ecosystem are they a part of? So, it seems, that even if one cares about licenses the big takeaway is that they matter a lot less than the other things required for a successful source-sharing community-driven project. OSI approved or nor. (For example I have no idea what license Terraform has .. okay, I checked, it's MariaDB BSL, and OpenTF is now MPL2. So I don't think MIT/Apache2 or AGPL3 would have made a difference in Hashicorp's hostile stewardship.)