Merging bcachefs

Posted Jun 18, 2023 20:36 UTC (Sun) by developer122 (guest, #152928)
In reply to: Merging bcachefs by ballombe
Parent article: Merging bcachefs

Hard to call it "GPL hostile" when any work from BSD etc can get stolen by linux but never contributed back.

If you want to be rude like that.

to post comments

Merging bcachefs

Posted Jun 18, 2023 20:43 UTC (Sun) by developer122 (guest, #152928) [Link] (29 responses)

I am of course talking about FreeBSD/OpenBSD/OpenSolaris, who all share their ZFS code with linux through OpenZFS.

You could always say "just use linux" but it's a pretty useful feature for a filesystem to be portable across OSs. There are even experimental windows and macOS drivers, if you really, really need to access the data there for some reason.

Merging bcachefs

Posted Jun 18, 2023 22:18 UTC (Sun) by ballombe (subscriber, #9523) [Link]

There is nothing that prevent BSD OS to run a GPL filesystem driver, really.

Merging bcachefs

Posted Jun 18, 2023 23:35 UTC (Sun) by khim (subscriber, #9252) [Link] (27 responses)

You could always say "just use linux" but it's a pretty useful feature for a filesystem to be portable across OSs.

Yet ZFS was made non-portable on-purpose. It's an open question whether ZFS license actually makes it's impossible to merge it into Linux, but it was designed to make that impossible and Linux developers and users generally respect wishes of ZFS principal authors.

FreeBSD/OpenBSD couldn't even claim that license stops bcachefs from being merged, because it's well-known fact that GPL is fully compatible with BSD license.

And they couldn't claim that they only accept filesystems with non-copyleft licenses, because AFAIK none of ZFS versions are released under non-copyleft licenses.

It's really their own decision whether they want to use it or not.

Merging bcachefs

Posted Jun 19, 2023 1:22 UTC (Mon) by developer122 (guest, #152928) [Link] (2 responses)

>Yet ZFS was made non-portable on-purpose. It's an open question whether ZFS license actually makes it's impossible to merge it into Linux, but it was designed to make that impossible and Linux developers and users generally respect wishes of ZFS principal authors.

>And they couldn't claim that they only accept filesystems with non-copyleft licenses, because AFAIK none of ZFS versions are released under non-copyleft licenses.

>It's really their own decision whether they want to use it or not.

This again? You realise this decision was made something like 20 years ago, right?

You might was well get a shovel, because Sun Microsystems has been dead for over a decade. If you have beef with the specific format in which Sun's legal department gave away their entire operating system Free to the world, you better start digging.

The modern steward of OpenZFS isn't Sun and it isn't Oracle. They're an independent project that forked the codebase.

ZFS is in fact very portable, currently actively supported by it's principal authors on three (3) OSs, with two (2) more on the way. All facilitated by the CDDL.

The CDDL is a weak per-file Free Software Copyleft licence, as recognized by the FSF.*

It fits just fine with BSD etc because the CDDL doesn't impose any restrictions on the other files in a codebase, and neither does the BSD licence. Furthermore, the CDDL doesn't impose restrictions on the licence of the resulting binary that gets distributed. Thus, so long as you aren't trying to merge ZFS into the FreeBSD codebase there's no issue, and TBH that would kinda defeat the spirit of sharing the OpenZFS codebase and it's ongoing new feature development across 4 different operating systems. (OpenSolaris (now illumos) doesn't have any problems because of course it's CDDL too.)

Unfortunately, while the CDDL doesn't have *any* problems with the GPL (and both licences carry the same spirit), various analysts believe the reverse isn't true due to subtle incompatibilities between the terms. So ZFS is stuck as a non-GPL kernel module. Sorry.

*https://www.gnu.org/licenses/license-list.en.html#CDDL

Merging bcachefs

Posted Jun 19, 2023 8:07 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

> This again? You realise this decision was made something like 20 years ago, right?

The BSD has used gcc for compiling for 20 years. They are not as hostile to the GPL as you imply.

Merging bcachefs

Posted Jun 19, 2023 10:44 UTC (Mon) by khim (subscriber, #9252) [Link]

The BSD folks hate GPL with passion. They used GCC because it was “the only game in town” and switched to Clang when it became usable. Same thing as Apple or Google.

For some reason BSD folks like when their code is used by SONY or other companies who contribute nothing back, but hate it when their code is used in GPLed projects and demand that GPLed projects would allow them to get stuff and give it to other proprietary companies on a silver plate. But it's unclear why bcachefs developers have to facilitate that.

And as much as I don't like “freedom fighters” who try to kill proprietary software and hurt end user instead I have even less sympathy for people who try to take free software and turn it proprietary.

Proprietary companies have lots of money and lots of developers. Let them write what they want or need themselves if they don't want to play by rules.

Merging bcachefs

Posted Jun 19, 2023 9:41 UTC (Mon) by paulj (subscriber, #341) [Link] (23 responses)

Again... having worked in a team where the senior engineer on it was one of the people involved in the internal "which licence should we use?", and having heard some of his perspective on how those discussions went, and piecing that together with things I've read from authoritative sources (Sun people who were actually there, e.g. Phipps):

1. Sun management wanted GPL. Schwarz was a big fan of the GPL.

2. A *lot* of the influential Sun engineering were _BSD_ people. They hated the GPL. They wanted OpenSolaris to be _BSD_ licensed.

3. BSD was never going to work for the business/management/legal side.

4. So engineering (as represented by a cade of the most senior/influential Solaris engineers) rejected what management wanted (with threats of leaving Sun if Solaris were GPLed); and management rejected what engineering wanted.

My view, based on the above - which is the closest to the facts of the matter available to me - is that management then chose the CDDL as a sort of compromise. A copyleft licence (as management wanted), but which was "It's definitely not the GPL!" so as to get it past the BSD-influenced GPL-hatred in engineering.

Additional factors (which I don't have specific evidence for, and I could not say are facts) may be that legal corporate people tend to view the GPL as problematically worded (IMLE). And also that Sun engineering people perhaps could see the writing on the wall for Sun, and they wanted to 'extract' the Solaris code (which they truly _loved_ and believed was the best Unix) out from Sun and have it available in "open source" form post-Sun, for them to continue to work and build on - and they really wanted it BSD. Given Schwartz and others in management also wanted (at last) to open-source Solaris...

I can't say it for sure, but my own sense is that it was a faction of Sun *engineering* that basically ensured Solaris ended up with this not-GPL-compatible copyleft licence, thwarting Suns' management, for largely irrational reasons related to long-standing BSD-v-GPL tribalism and dislike of GPL. I think they shot themselves in the foot by doing so. I think OpenSolaris would have been a lot more relevant if engineering had gone "Well, we can't get management to agree to BSD; if it has to be copyleft, GPL compatible is best".

But hey.

Merging bcachefs

Posted Jun 19, 2023 9:49 UTC (Mon) by paulj (subscriber, #341) [Link]

Management then had legal /draught/ a suitable copyleft licence.. bit more than choose. There was fairly wide consultation on this internally with Solaris engineering, cause I remember Fred Zlotnick - acting Director of Solaris Engineering then - visiting and making a point of asking me my opinions about the licence Sun were writing and considering for Solaris. Clearly part of deliberate wide internal consultation, given I was just an ordinary MTS/3 then (though, was known for working on external open-source stuff) - didn't usually talk to directors. ;)

Merging bcachefs

Posted Jun 19, 2023 10:56 UTC (Mon) by khim (subscriber, #9252) [Link] (21 responses)

> I can't say it for sure, but my own sense is that it was a faction of Sun *engineering* that basically ensured Solaris ended up with this not-GPL-compatible copyleft licence, thwarting Suns' management, for largely irrational reasons related to long-standing BSD-v-GPL tribalism and dislike of GPL.

That matches what I know about BSD people. I just wanted to point out that what we are discussing here is nothing more than that same long-standing BSD-v-GPL tribalism and dislike of GPL.

Probably wasn't explicit enough.

Licensing doesn't prevent adoption of bcachefs by BSDs. And if OpenSolaris guys wanted it they could have asked for a special exception (easy to grant given how few people contributed to bcachefs so far).

Instead they demand that bcachefs developers should drop GPL and make it easily available for Apple, SONY, Microsoft or any other proprietary OS to “embrace and extinguish”. Why should they do so?

Merging bcachefs

Posted Jun 19, 2023 13:46 UTC (Mon) by Wol (subscriber, #4433) [Link] (20 responses)

> Instead they demand that bcachefs developers should drop GPL and make it easily available for Apple, SONY, Microsoft or any other proprietary OS to “embrace and extinguish”. Why should they do so?

Because they want to make money off other peoples' work?

I don't take sides in the GPL/BSD wars (my favourite system, Scarlet, the *practical* difference is bugger-all ...), but it is, as always, down to your definition of "freedom".

The BSD licence protects the SOFTWARE ENGINEER guys, the GPL protects the END USER guys.

Cheers,
Wol

Merging bcachefs

Posted Jun 19, 2023 14:55 UTC (Mon) by paulj (subscriber, #341) [Link] (13 responses)

My own view, based on my /feelings/ of having been in Sun and - as a GPL guy (was hired for my work on GPL software) - trying to understand why much of Sun engineering had a _deep_ *hatred* of the GPL, and a favourable view of the BSD licence, is that they view it as a freedom thing.

I could never get a cogent argument as to how the BSD licence protected software freedom better than the GPL. So ultimately, the only cogent argument that *I* can construct (as said GPL guy), in the context of the engineers I knew, is that they want the code they write for an employer to be BSDed so that - if they ever leave, or the company goes under or gets bought - these engineers have the 'freedom' to continue to use the code they are familiar with at their next employer, regardless of their next employers' attitude to open-sourcing their software.

My main evidence for this is that the push to open-source Solaris (which needed a) engineering approval, and b) significant engineering led due diligence, and a little bit of code cleanup) only really came about when Sun had sunk into deep trouble, and the future didn't look great.

As you say, to protect the engineers. Specifically, ability to keep using code they've written for one employer at the next.

Merging bcachefs

Posted Jun 19, 2023 16:44 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (12 responses)

> As you say, to protect the engineers. Specifically, ability to keep using code they've written for one employer at the next.

Worth noting other projects like Samba have managed to solve this problem by having contributors negotiate an agreement to retain the copyrights as described in

https://www.samba.org/samba/devel/copyright-policy.html

Distributing the copyright like this prevents a single entity from unilaterally changing the license and contributors can carry on their work regardless of their commercial employment.

Merging bcachefs

Posted Jun 19, 2023 17:20 UTC (Mon) by khim (subscriber, #9252) [Link] (11 responses)

> Worth noting other projects like Samba have managed to solve this problem by having contributors negotiate an agreement to retain the copyrights

This haven't solved the problem at all. Samba is not in the Android phones because of GPLv3 and it's very inconvenient to transfer files from/to Android phone because of that. BSD license would have solved that problem.

And yes, it explains why people who work for some company which is just about ready to “go under” may prefer BSD. But it doesn't explain why they would go as far as to demand that someone else have to go from GPL to BSD for their sake.

It's not their code, what right have they to demand that someone else have to provide it for them even if they want to go work for someone who would close it up and do that classic “embrace, extends, extinguish” trick?

It's one thing to fight for your own code, it's entirely other to demand that someone else have to give their code for your to misappropriate.

Merging bcachefs

Posted Jun 19, 2023 19:32 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

>This haven't solved the problem at all. Samba is not in the Android phones because of GPLv3 and it's very inconvenient to transfer files from/to Android phone because of that. BSD license would have solved that problem.

This is a different issue. The problem I was responding to, was specifically about engineers ability to continue working on the code regardless of their employer. Samba developers demonstrably have that in practice.

Merging bcachefs

Posted Jun 19, 2023 20:46 UTC (Mon) by khim (subscriber, #9252) [Link] (8 responses)

> Samba developers demonstrably have that in practice.

How can they do that?

> The problem I was responding to, was specifically about engineers ability to continue working on the code regardless of their employer.

Obviously they want to use it for their work, not just as a hobby. For hobby you don't need much thought about licensing. But for work… you need to clear licensing issues.

And GPL, very often, is rejected by employers thus engineers lose the ability to use their own code if it's released under GPL.

You may argue it's not rational and they should have thought about that when they wrote code for their current employer… but I can understand their reasoning: they have already sunk tons of effort into that code, they want to continue to use it with a new employer when they change workplace… GPL doesn't give that to them.

But that's for their own code. Which they wrote. And want to use in a new place.

GPL gives you the different way of using your own code: not for the new employer, but for yourself, personally — when someone else improves it.

That's also valuable ability and one which some people prefer.

That's why I say that I can understand people who release code under BSD or Apache license (heck, I did that for that exact same reason). But demanding that someone else have to give up their own wishes and put their desires ahed of their own… sorry, guys, that goes beyond what I'm ready to accept.

Merging bcachefs

Posted Jun 19, 2023 21:18 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> How can they do that?

I already explained this. They do that by retaining copyrights. Affiliations are listed in https://www.samba.org/samba/team/. All these organizations are fine with GPLv3 obviously.

Merging bcachefs

Posted Jun 20, 2023 10:01 UTC (Tue) by paulj (subscriber, #341) [Link]

They /prefer/ contributing developers to retain copyright personally. However that is simply not an option for the vast majority of salaried engineers. Hence why the Samba contribution processes you've pointed to also have a path for corporate owned contributions.

Merging bcachefs

Posted Jun 20, 2023 13:38 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

> All these organizations are fine with GPLv3 obviously.

Let me see. Facebook. No. Apple. Never. Amazon. Not there. Netflix. Of course not. Google. Obviously no.

Sorry, but that's failure in my book. It puts you into a stark bind: either you avoid most desirable (and most lucrative!) employers or you can use the code you wrote. Otherwise someone else would be able to use and not you.

I can see why these people would hate GPL: it's, quite literally, forces them to choose between their own code and “dream job”.

Not good, not good at all.

Now, for other people who already made that decision and are not interested in joining FAANG-style companies… for these GPL is desirable and trade-offs are fine.

Merging bcachefs

Posted Jun 20, 2023 14:17 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Sorry, but that's failure in my book.

That's fine, do you have any evidence that it is failure in the book of Samba developers? Because that's the only part that matters to this discussion.

Merging bcachefs

Posted Jun 20, 2023 18:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> That's fine, do you have any evidence that it is failure in the book of Samba developers?

There's a presentation from one of the Samba developers about how GPLv3 failed to bring better compliance and is not helping at all.

Merging bcachefs

Posted Jun 20, 2023 20:50 UTC (Tue) by khim (subscriber, #9252) [Link]

> Because that's the only part that matters to this discussion.

Wow. Just… wow. have you already forgotten that it was you who joined discussion about Sun engineers and promised some mythical solution to their worries.

And now you turn around and say that what they think is irrelevant and only ones who support FSFs jihad matter?

I'm starting to understand why people may dislike GPL. Once upon time FSF did a lot help people dealing with their practical issues: GNU software for Solaris and, later, Linux, then CygWin and many such things helped to solve many practical problems.

But with friends like these… who proclaim opinions of other people just don't matter if they refuse to join their holy jihad… who needs enemies?

And not everyone is wise enough, like Linus, and can separate GPLv2 (really superb hack on top of copyright system) from people who invented that hack (and then eventually ruined GPL with introduction of GPLv3) and who are, today, more of bane then an asset.

Merging bcachefs

Posted Jun 22, 2023 8:04 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

> Sorry, but that's failure in my book. It puts you into a stark bind: either you avoid most desirable (and most lucrative!) employers or you can use the code you wrote.

Once upon a time listing all the companies that made and sold BSD-based appliances was a who’s who of the industry.

Once upon a time Java was the future and the whole big data stack was built on Open Source (*not* Free Software) Java bits (Hadoop, etc). Now Python (definitely not Free-Software hostile) stole the big data show.

All those ecosystems have dramatically shrunk, the companies that remain mostly release Linux and Free-Software based products.

Open Source (as opposed to Free software) is a dead end that gets repeatedly estinguished by the greed of companies that insist on it. So maybe it pays more short term. Long term it condemns its participants to the anguish of being replaced by something else whose proponents share more with one another.

The corporations themselves do not care overmuch one way or another. Change of tech, change of techies. The only ones fooling themselves OSS vs Free Software matters for business are those techies. In the end money talks (Google’s awowed distaste for the GPL won’t make it dump Linux in GCP or Android as long as it makes them money; Microsoft has seen the *lucrative* side of cancerous GPLed Linux a long time ago).

Merging bcachefs

Posted Jun 22, 2023 20:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Now Python (definitely not Free-Software hostile) stole the big data show.

Uh... Whut? Python is quite explicitly OpenSource, not Free Software. It has a permissive license, and there's nary a GPL-ed package in sight. All the recent AI work is built on permissively licensed packages.

> Open Source (as opposed to Free software) is a dead end that gets repeatedly estinguished by the greed of companies that insist on it. So maybe it pays more short term.

What you're saying is completely false. It's Open Source that wins long-term because it's a superior development model. Proprietary forks (and models like "open core") can exist for a while, but they eventually either become obsolete and die off, or get integrated into the open code.

This is doubly so when the software gets complicated. You can't really develop a meaningful proprietary fork of Kubernetes, simply because your "secret sauce" changes will likely be insignificant compared to the overall functionality. And if they are significant, you'll have to keep up with the firehose of new functionality that is released for each new official version.

And finally, Open Source allows companies to collaborate on non-core functionality. My previous company worked in the solar industry, and we as hell wouldn't release our proprietary simulation algorithms, but we contributed quite a few patches to miscellaneous projects (because why not?).

To paraphrase an old Soviet joke, the goal of FSF is to make sure that there's no proprietary software, the goal of Open Source is to make all software open sourced.

Merging bcachefs

Posted Jun 20, 2023 9:56 UTC (Tue) by paulj (subscriber, #341) [Link]

Their new employer might not want to allow GPL code in their products - or at least, strongly discourage incorporating any /further/ GPL code into their products. You can see this with Google and Android, and others.

Merging bcachefs

Posted Jun 19, 2023 17:10 UTC (Mon) by khim (subscriber, #9252) [Link] (5 responses)

> The BSD licence protects the SOFTWARE ENGINEER guys, the GPL protects the END USER guys.

Isn't it the other way around? GPL ensures that software engineer may tinker with the code, BSD doesn't have such guarantees. GPL ensures that if someone would use your code they couldn't take it and kick out the actual author using patents, BSD doesn't have such guarantees.

On the other hand GPL makes it inconvenient to use your code which means it may not be available as widely which makes it less convenient for non-developers… and non-developers wouldn't care about source code availability since end users wouldn't know what to do with it, anyway.

I can easily understand people who are using BSD or Apache license to ensure that more people would benefit from their code even if they may lose the ability to use it freely… but to demand that someone else have to do that… that goes beyond hubris.

Merging bcachefs

Posted Jun 19, 2023 17:18 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

I look at it as the Software Engineer can take any BSD code, and doesn't have to worry about pretty much anything.

It is possible to be in breach of the licence, but it's rather hard ... although AT&T did manage it.

The GPL on the other hand - if I as an end user decide to use a GPL program, I am entitled to the source code and have the right to maintain it myself. I may not be able to, for all sorts of reasons, but nobody can come up to me and say "you can't do that".

So software engineers are free to do what matters to them with BSD code (modify it, sell product), end users are free to do what matters to them with GPL code (run it, fix problems).

(And if, as an END USER, you only use Open Source code, then you don't notice any practical difference between the two.)

Cheers,
Wol

Merging bcachefs

Posted Jun 19, 2023 17:31 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

I think we have wildly different ideas about who “end users” are.

In today's world if you can fix your program you are an engineer, not end user.

The majority of end users don't have skills needed to fix anything.

So you are talking about engineers in both cases. Just BSD protects engineer from their own management and GPL protects engineer from management of other companies.

Frankly, I'm not sure I like BSD at all after that explanation.

Sometimes engineers are forced to work for companies known by their toxic culture, but the proper solution in that case is to leave them when possible, not trick them into adopting BSD to salvage that piece of code you worked on.

And while the desire to use BSD to salvage your own code may be justified, but to demand that others would give up their code for you to misappropriate just because you dislike that GPL puts you in the conflict with managers just makes no sense at all.

It's their code, what right do you have to demand that they would surrender it to your managers (and unreasonable, FOSS-hostile managers at that) just to make your life a tiny bit easier?

Merging bcachefs

Posted Jun 19, 2023 22:08 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> In today's world if you can fix your program you are an engineer, not end user.

They're not exclusive. True, PEOPLE end users are rarely engineers, but company end users can employ engineers. And it's difficult to be an engineer without being an end user too. You personally, do you work on all the software you use? I doubt it. For MOST of the software you use, you are an END USER. How many people USE gcc? How many people HACK on gcc? If you use but don't hack, you are an END USER.

> The majority of end users don't have skills needed to fix anything.

But that's not what the GPL is about. They have the RIGHT to fix it, they have the SOURCE to fix it, and they have the TOOLS to fix it. The fact that they don't personally have a clue HOW to fix it is their problem, and it is IN THEIR POWER to solve.

Whereas the thing with BSD is that, if you spot a nifty hack in someone else's code, you can just lift and use it without worrying. Both licences have their place. They target different problems, and provide different solutions. BSD is especially good for sample code or code in standards documents.

The problem with the FSF and the GPL is that some software costs a lot of money to maintain, with legal issues etc etc. If you insist on GPL, this sort of software will never get written. That's why I have a problem with the FSF - they think I should not have the freedom to buy a commercial product!

Personally, I'd like to see a license that's a sort of half-way house along the lines of "if you use my code in your product, you have to provide your customer with your source and build system". Give customers the GPL freedoms to study the source and fix their own problems, but still protect the supplier's source code as trade secret or whatever. The freedom to share may be nice, but freedoms often conflict. And if you IMPOSE YOUR CHOICE of freedoms on me, you are making me your slave! Americans seem to have difficulty grasping the fact that other people value different freedoms than they do. Even Sun engineers prefering BSD! and refusing to allow other people to choose GPL!

Cheers,
Wol

Merging bcachefs

Posted Jun 20, 2023 22:34 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

> If you use but don't hack, you are an END USER.

Yes, and I'm acting like end user, too.

> You personally, do you work on all the software you use?

No, but all the software that I'm just using is a black box to me. Modern software is just too complex to try to change it.

In theory I can get source for gcc or rust compiler or rust analyzer and change something there. In practice it's just too time consuming to contemplate.

In an era where most software was simple and had lots of bugs changing something into it made sense.

But then… “Worse Is Better” won.

As Tony Hoare once wrote: There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.

And today's software have no obvious bugs in it and as a result it's so incredibly complex that fixing remaining non-obvious bugs quickly becomes full-time job.

> They have the RIGHT to fix it, they have the SOURCE to fix it, and they have the TOOLS to fix it.

And all that doesn't matter because they don't want to fix it. Including me, for aforementioned reasons. That's why GPL is much less valuable for me today… even if I can understand people who are using it.

> Americans seem to have difficulty grasping the fact that other people value different freedoms than they do. Even Sun engineers prefering BSD! and refusing to allow other people to choose GPL!

Yup. That's the country where congressman say, literally, the following: If China behaves as aggressively as Russia, then we will deprive them of their main trading partner in the face of the EU. Europe will impose crushing sanctions. Note that no one plans to deprive US of anything and they plan to make someone else to do the work for them.

How is that any different from Sun engineer's position?

Merging bcachefs

Posted Jun 28, 2023 6:16 UTC (Wed) by timofonic (guest, #165836) [Link]

Why so much offtopic? Sincerely. I would prefer more direct discussion about Bcachefs. Despite the nice threading, it's noisy and a wasted effort.

Merging bcachefs

Posted Jun 19, 2023 12:37 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> Hard to call it "GPL hostile" when any work from BSD etc can get stolen by linux but never contributed back.
> If you want to be rude like that.

Let's stick to facts even if one wants to be rude. Nothing has been "stolen" by anyone because no free and open source license requires anyone to contribute anything back, especially permissive BSD licenses. The strong copyleft licenses can only mandate the changes be made public under the same license.

Merging bcachefs

Posted Jun 20, 2023 14:00 UTC (Tue) by Baughn (subscriber, #124425) [Link]

The whole point of BSD / MIT licenses is, you're saying you're okay with people taking your stuff and giving nothing back. If you don't want that to happen, put it in the license! Which, um, that's what the GPL license *does*.

I simply don't understand people who license their work BSD, and then go "No, we meant for you to act as though it's GPL!"