Why Linus loves the GPL
Linus Torvalds has never been one to mince words when it comes to Linux, or anything else for that matter. At a keynote conversation at LinuxCon he expressed his appreciation for the GPL and how it helped Linux avoid fragmentation.
Swapnil Bhartiya reports for CIO:
“I used to be worried about fragmentation, and I used to think that it was inevitable at some point,” said Torvalds. “Everyone was looking at the history of Linux and comparing it with UNIX. People would say that it’s going to fail because it’s going to fragment. That’s what happened before, so why even bother?”
What made the difference was the license. “FSF [Free Software Foundation] and I don’t have a loving relationship, but I love GPL v2,” said Torvalds. “I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint.”
That doesn’t mean Linux is immune to fragmentation. Torvalds’s greatest fear was that fragmentation would happen due to different markets. In the early days SGI was pushing Linux into 1,000 core machines, and Linux was not ready. SGI wanted to talk to Torvalds about how to manage that. “I said you should do your own big iron version of Linux and sell it as SGI Linux,” he said. “They did to some degree, but they kept moving things back.”
GNU GPLv2 allowed merging things back. “We ended up just improving to the point where our limits from the standard kernel went away and let the SGI people push their code to us, so that they had less headaches with all the changes they did,” Torvalds said. “That experience just convinced me that, even if you have completely disparate machines and target markets, we really can have a single image from the source code standpoint.”
More at CIO
The CIO article spawned a large and passionate thread in the Linux subreddit:
Loves_Portishead: “The biggest problem, today, for most people with the GPL is lack of meaning what “derivative” or “related” means in terms of modern scripting languages with dynamic imports.
My pet open source project, Capistrano was GPL (well, AGLP) licensed, and we had SO MANY complaints of people saying “I can’t use this to deploy my companies site, our back end is proprietary and a viral GPL is incompatible” so, we undertook the insane effort of contacting nearly 400 contributors, from more than 7 years of logs, and re-wrote the parts we couldn’t get a CLA signed for, now we are MIT licensed and the complaints have stopped, without any measurable difference in contributions.
We need someone to fund a legal analysis of how GPL and it’s versions, variants and derivatives affect modern code (linking to libraries was permissable in one of the GPL versions, but my company has a lawyer who reckons that the linking exception doesn’t cover Ruby, Python, etc, since they are not linked in the original sense of the word when the GPL was written.”
Tscs37: “The story gets worse if you write in statically linked language like Go.
Licensing a Go project under the LGPL is basically the same as GPL since the legal status of linking seems to be unresolved in regards to that.”
Ameobea: “Is there a site somewhere that walks you through picking a license for your work that fits your personal goals for it? I feel like that’s gotta be a thing that exists.”
Bwinterton: “http://choosealicense.com”
Klathmon: “Personally I use https://tldrlegal.com
It’s got a set of check boxes you can check off to get a list of licenses, and it does a good job of spelling out each point along with providing the full text.”
Sideeffect: “Probably the best source: How to choose a license for your own work”
Computesomething: “My own code license preferences is basically as follows, permissive licensing for component/library/framework type code, copyleft for end user facing ‘finished product’ style projects.
I don’t see permissive licensing being about code you don’t care about, as Linus puts it, but rather code for which there is little to no reason for someone to do a proprietary fork, basically ‘building block code’ or projects where the being open aspect is a critical component of it’s useability.
For ‘finished products’ that is usually a different matter, here there are often incentives to keep your enhancements as a competitive edge when offering it to end users, leading to proprietary forks and subsequent duplication of effort in order to add those proprietary features to the open version (while any open features can just be picked up by the proprietary version) .
In short, I think these license approaches serve different scenarios (of which there are indeed many), and dismissing either of them out of hand is a mistake.”
Wat94: “I don’t know about libraries, since they could be considered end products in themselves (if you consider a developer as and end user). In the end, you can just dynaminally link them and preserve the differences in license.
I do agree about frameworks though since both original and derived code end up mixed. Like game engines/frameworks. I know that Blender has an amazing game engine, but no one uses it commercially because of GPL problems, which is a shame. In those cases, a less restrictive license would be much less of an headache.”
Antynythr: “I used FreeBSD for a few years and the way the BSD license was explained to me is that it’s great for code that you want to get to as many systems as possible (like protocols such as TCP/IP).”
PoetheProgrammer: “Yeah, and GPL is good for building a single, solid project. In regards to the TCP protocol iirc both Apple and MS stole the BSD code in the 90’s, or well they didn’t steal it because BSD doesn’t force you to merge code back.”
More at Reddit
DistroWatch reviews Korora 24
Korora 24 is a desktop distribution based on Fedora. Korora provides multimedia support, along with a big selection of software. A writer at DistroWatch recently did a review of Korora 24 and came away with a positive impression of the distribution.
Jesse Smith reports for DistroWatch:
I find it difficult to talk about Korora without comparing the distribution to its parent, Fedora. Modern versions of Fedora tend to be relatively minimal for a desktop distribution. With Fedora’s Workstation edition, we are given the desktop, some essentials and adding the specific tools we want is left to the user. This often involves tracking down third-party software repositories and spending a few minutes to a few hours installing the applications we plan to use. Fedora errs on the side of caution when it comes to software licensing and is careful not to package non-free or patent encumbered software. This limits multimedia support on Fedora.
Korora essentially takes Fedora Workstation and tries to set it up with the media support, applications and third-party repositories people are likely to want. This makes Korora a larger download (2.0GB vs 1.4GB for Fedora), but it means we have many of the applications we will probably want immediately following the installation. We also have lots of neatly organized configuration tools by default with Korora and that is a feature I appreciate. Personally, I like Korora’s approach to including more software. Even without the extra software installed for us, I think Korora would be worth the extra download size just for having several third-party repositories configured for us.
Apart from the default software and repositories, Korora stays very close to its parent. At its heart Korora is still Fedora, so almost all of the differences boil down to what is set up for us out of the box.
Looking at Korora by itself, ignoring its parentage for a moment, I think the distribution is a fairly solid desktop operating system. Korora ships with fairly modern packages and users have access to a lot of software through Korora’s many default repositories. The system was responsive and I like Korora’s default theme. The MATE edition is relatively light on memory and the distribution worked well with my hardware. I have said before one of Korora’s few weaknesses is package management. Yum Extender is not a bad software front-end, but it is a bit slow and it had trouble installing the first wave of upgrades post-installation. These problems can be worked around by using the command line DNF package manager. I did run into a few glitches while using Korora, but nothing that consistently gave me trouble, so all-in-all, I was happy with my experiences this week.
More at DistroWatch
Games that never made it to SteamOS and Linux
Linux gamers have generally enjoyed a larger selection of games than ever before in recent years. But not all games that were promised have actually made it to Linux. A writer at PC World notes that certain games were supposed to appear on SteamOS and Linux but never became available for gamers.
Chris Hoffman reports for PC World:
Linux gamers shouldn’t buy games before they’re actually released for Linux or SteamOS. Lots of games—including big-name, AAA games—have gotten a wave of good press by announcing forthcoming support for Linux and SteamOS, which then never materialized.
There are lots of great games you can play on Steam Machines and Linux. That’s why it’s so disappointing when developers cancel announced ports or, worse yet, go silent and stop talking about them.
The Witcher 3: Wild Hunt, which Valve announced was “Coming to SteamOS” with a huge banner on the Steam store, was perhaps the biggest tease of all. That banner was taken down just a few hours later, and Valve never said anything further on the matter. CD PROJEKT RED, The Witcher 3’s developer, has refused to comment on Linux and SteamOS ports….
