Linus' opinion always was: "I give you source code, you give me your changes back, we're even."[1] That's his summary of GPLv2 and I think such an attitude is reasonable, and it might have certainly aided the Linux kernel development over time (almost sure of it).
He disliked the GPLv3 exactly because of that. Because in his opinion it's (paraphrased) "I give you the source code, and now I dictate to you how you are allowed to use it." (see same link).
Whether a BSD/MIT license hurts or helps a project is pure speculation. More permissive licenses might make code reuse more attractive, and be considered "more free" regarding code reuse. As to what code contributions you miss out on? Hard to judge. There definitely are companies building products utilizing FreeBSD / OpenBSD without committing all their changes back (or none to begin with).
Pick the right license for your project. You don't care and are happy if someone uses it? Use a permissive license (MIT/ISC). You want to develop the product, improve on it, and want the changes back? Use something like GPLv2. You deeply care about your code running on open devices? Use GPLv3.
There's no "one obvious right way" as far as I am concerned.
[1] https://youtu.be/5PmHRSeA2c8?t=2840 (from there to 56:51 it's about open source licenses)
That's not correct, you just have to make it available IF you redistribute the code. That's why you will never see a Google Data-center Linux-Kernel.
The latter occurs decently often in the Linux Kernel world, and if there isn't much desire for the changes they can technically exist but never get merged.
Whereas there are other drivers where the only one that cares about them is the company that uses them, but their developers have worked to get it actually upstreamed and help maintain it.
While the GPL doesn't require upstreaming, it does require that derivative works that are distributed to users must make sources available. If those sources are available, then users or project maintainers can choose to upstream those changes if they want to.
Apple, Sony, Nintendo etc don't make those source changes available despite distributing derivative works to users, so users and project maintainers can't upstream changes even if they wanted to.
https://www.techrepublic.com/article/what-is-microsoft-doing...
Oh yeah and SUSE and SCO is another story..like written in you article...
https://www.zdnet.com/article/linus-torvalds-isnt-worried-ab...
This is wrong. https://en.cppreference.com/w/cpp/compiler_support
Then you'll see where people are wondering.
Want to use modules on clang? Wait at least another year more.
No wonder that Red-Hat is hiring for clang devs, alongside the contributions they already do for GCC.
This seems wrong. Clang+LLVM has supported C++ modules for a while.
Proper ISO C++20 modules are yet to be supported.
From wikipedia:
The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages. LLVM was released under the University of Illinois/NCSA Open Source License, a permissive free software licence. In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems. LLVM is an integral part of Apple's latest development tools for macOS and iOS.
Apple chose to develop a new compiler front end from scratch, supporting C, Objective-C and C++. This "clang" project was open-sourced in July 2007.
Apple is perfectly willing to maintain, say, Swift and LLVM as Free projects; but they also have a proprietary fork with extra bits exclusive to their own hardware. For example, their proprietary GPU drivers compile shaders with it. LLVM being permissively licensed and owned by them means they have no reason to release those bits.
This is not a hypothetical problem; it causes real harm to downstream users of LLVM. Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork.
Had Apple stuck with GCC they wouldn't have the legal ability to do this. Even if they had used GPL on LLVM, that license alone means that any contributions they take would also bind Apple to the same license. That's why people are extremely apprehensive about CLAs, because they're basically one-sided. The project vendor is free to sell exceptions or maintain proprietary forks, but you still have to comply with GPL.
IIRC, the bitcode format isn't proprietary—it's part of the open-source LLVM. The only issue is that it's not a stable format, so they need to use Apple's LLVM version and not an earlier or later open-source one.
This variant wasn't and will never be upstreamed.
They could still do as they like, as it’s theirs. Do they accept significant code from the community?
This is why I find the “use agpl” claims about projects run by a company disingenuous- they’re using the licence restriction to prevent competition while they have the freedom to offer “enterprise” editions however they wish.
Companies that want to release software as GPL but also sell exceptions or make forks either cannot accept third-party contributions (as then they'd be bound by the contributor's derivative copyright interest in the code) or have to require contributors sign CLAs.
Projects with distributed copyright interest and a copyleft license governing all of that, like the Linux kernel, practically cannot relicense or sell exceptions. That's the power of the GPL: everyone has to contribute on a level playing field.
Because if they don’t, the gpl wouldn’t help.
But regardless of that - I think this is the perfect example of the copyleft crowd not understanding the concept of compromise.
Apple creates something, releases it as open source but also maintains some private extensions, and the response is: well why didn’t you give it all to us?
Yes, they do. LLVM has a large number of non-Apple contributors.
Apple don't own it. They piggyback off a lot of other people's work in LLVM.
They tried. rms lost the email.
I'm not sure I follow. Apple's LLVM fork could open source and Rust would still have to support two LLVMs if the WatchOS code wasn't upstreamed. Apple has no responsibility to upstream code on the GPL, nor do the LLVM maintainers. Given that Apple's bitcode would be proprietary / undocumented (GPL doesn't require you to document your code), it would take a dedicated individual to make sure the two projects are in sync. If Apple isn't doing that now, I'm not convinced they would do it under GPL.
The GPL would legally require Apple to publish source code for all LLVM forks they make, if they accepted third-party contributions under GPL terms. It doesn't require them to upstream it anywhere, you just have to let someone else do it.
To my eyes, the number of open source drivers (near zero) available for Apple hardware, developed to run on their BSD-licensed kernel, pretty much provides all the evidence I need.
No, a BSD Linux would have long since disappeared behind the curtain of some tech giant or another, just like Mach did into NeXT/Apple.
Assuming a BSD-licensed Linux is a fairly small step away from assuming that Linux didn't exist given the existence of various BSD Unix flavors. And most people I know feel fairly strongly that, in the absence of Linux, BSD Unix would have come to the forefront.
For anyone interested, here's a debate between Bryan Cantrill and Steven J. Vaughan-Nichols I recorded last year on the topic "If Linux didn't exist, would we have had to invent it?"
I was porting software between Windows NT/2000, HP-UX, Solaris and Aix.
The Red-Hat Linux and FreeBSD boxes we had on the office were used for sharing mp3s, quake server, and replication of our CVS server.
And in the absence of Linux entirely, most people I know consider that one of the BSDs would have been rallied around because there was just too much market demand for an open source *nix operating system.
Also all new POSIX FOSS OS for IoT are MIT/Apache license based, just give them a couple of years and see which one board makers will be picking.
People considered the GPLv3 excessive. Now we see tivoization everywhere, and people cries because corporations are soooo evil. Well, maybe you should not use licences that let them do that. People who think the FSF is too idealistic are missing the point - the FSF is terribly realistic, it's the ones who don't care about software freedom who end up learning the hard way why the FSF exists.
But that's a separate fight than the original GPL fight, and not necessarily one that really should be fought with the same fervor.
I know how I'd answer your question.
FreeBSD back then did not want to install on my PC. First problem was that I had an IDE CD-ROM and they only supported SCSI CD-ROM.
Second problem was that it would not install in the unpartitioned space on my DOS/Windows SCSI hard disk.
Linux supported IDE CD-ROM and could install on the same disk as DOS/Windows.
Result: I installed Linux, and have used Linux ever since then when I need a free Unix-like system.
According to their forums, there was no IDE support because nobody would seriously have IDE on a server. At the time you could make a reasonable case for that for hard disks, but not for CD-ROM (especially since IDE CD-ROMs were around $100 and SCSI CD-ROMs were around $400).
The disk sharing limit was because they didn't think you could reliable infer the cylinder/head/sector (CHS) to logical black address (LBA) mapping that the other operating system(s) on the disk used. (The standard PC partition map at the time specified everything using CHS addressing, but disk interfaced had moved on the LBA addressing. Someone had to make up a pretend geometry for the disk, and then everyone had to consistently use that mapping to convert between CHS and LBA).
In theory, you probably could find a legal partition setup with free space that was unsafe for another OS to use due to ambiguity of the mapping, but in practice that did not happen.
[1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
Linux went beyond "could install on the same disk as DOS/Windows". Linux could install on the same filesystem as DOS/Windows. No need to repartition, no need for unpartitioned space. If you later decided Linux was not to your liking, you could simply erase your Linux directory.
Result: I installed Linux on my C: partition, choosing a distribution which came with UMSDOS support. Some time later, I noticed that I rarely booted into DOS/Windows anymore, so I moved everything from the D: partition to the C: partition, erased the D: partition, and reinstalled Linux on that free space (using ext2 instead of UMSDOS). I have used Linux ever since then.
In fact,I deeply believe had Microsoft been more serious about POSIX support on Windows NT and Linux wouldn't even had a chance.
Fortunately for Linux, Windows NT/POSIX was only for fulfil a checkbox on government contracts.
Some moved from weak licenses to AGPL. Some, like MongoDB, to closed source.
Based on this evidence, it's very likely that Linux has been protected by GPL.