Wordpress 1,000% (probably coupled with WooCommerce but there are probably some other options)
I honestly don’t even know off the top of my head why you would use anything else (aside from some vague elitism connected to the large ecosystem of commercial crap which has tainted by association the open source core of it) – it combines FOSS + easy + powerful + popular. You will have to tiptoe around some amount of crapware in order to keep it pure OSS though.
Depending on the nature of the changes, it might be more advantageous to tell them that it’s easier (i.e. cheaper) to contribute changes upstream, rather than maintaining them separately forever. Also, the good will and reputation boost involved can be significant.
Don’t say it if it isn’t true or anything, but in a lot of cases it’s true.
I think mostly they prefer for people to just fix their delivery to comply with the license, as opposed to causing antagonism towards the community by going straight to a lawsuit. But yes, there are definitely teeth to it if some company for whatever reason doesn’t want to fix their infringement.
Yeah, 100%. At this point the resources invested in MacOS / iOS have probably exceeded even the decades of work they were able to leverage by starting with FreeBSD / NeXT / Mach / whatever else.
(Edit: Actually, not 100% true. Macs are still very BSD-like under the hood; I actually really like development on Macs because I can basically treat them as BSD systems with unusual package management and a fancy GUI. For that reason they’re far preferable for me over Windows or pre-OSX Macs. But yes, your point is well taken that iOS development at this point has far eclipsed anything they started out from in terms of LOC and time spent.)
There’s a list of open source Android distributions. Although not very good, they are viable.
Yeah, I get that. This is why I’m not fully in agreement with Perens that this is an urgent problem.
How are phones free-software-hostile?
Because the whole idea of the GPL was to usher in a future that was like the environment RMS grew up in, where you always had the source code to all your stuff and you could examine or modify or build on it. Linux machines are in actual practice that way, which is super cool. Android phones are basically not, from the viewpoint of almost any mortal human. I think the argument is that the efforts that the manufacturers make to close off modifications to the phones, and then put software on them that’s sometimes hostile to the best interests of the phone owner, means they shouldn’t be able to use all this GPL-licensed software for free in order to build the phones they’re selling.
This to me is a good question. The lack of something concrete that sounds like “yes, that would definitely work” is something that makes me have reservations about this whole thesis… but that said I think it has some merit.
Mysql and Qt already have a pretty solid model, where there’s a GPL-enabled alternative that the community can use, or you can pay a fee to use the commercial version. You could scale that up to something where if you want to pay a certain fee, you can use lots of currently-GPL software (maybe any that’s been assigned to the FSF or something with the FSF shepherding the whole thing). Then, we can stop the sort of benign neglect of companies that are sloppy with their licensing of uboot or Busybox, and just tell them to start paying the fee if they don’t feel like dotting all their "i"s as far as licensing, and then use the fees to fund development of open source software that’s needed but doesn’t have a lot of motivated developers working on it.
I’m not as convinced that it’s necessary as Perens is. Like I think he overblows by quite a lot the impact of RHEL skirting their licensing, because in his mind RHEL is such a big part of the computing world when in reality it’s not. But it sounds like he’s describing real problems and the solutions make some version of good sense to me.
Violating the (spirit of) the license (without violating the letter, because of loopholes in the license) is exactly what Perens is talking about.
He’s not “complaining he isn’t getting paid.” I think it’s pretty rare that the people working on open source software are actually hurting for money or anything. He’s complaining that the actual practice of how the software is being used, RHEL and Android on phones and etc, isn’t doing well at reflecting the vision of the computing world the GPL was supposed to create. Then, as one possible solution, he’s proposing to kill two birds with one stone with a new license where the companies that are skirting the license right now can have to fund the development of particular types of open source software that need to get done anyway but is lacking right now (because of lack of profit motive).
You might or might not agree with his thesis; as much as I think it’s interesting and insightful I have some reservations about it. I just thought you were misunderstanding his whole argument as being in terms of money, that’s all.
Hm, interesting stuff. Yeah, maybe it’s more common than I was aware of – that’s still a little weird to me, because there are entities like FSF that are so happy to go to bat for people legally if they do want to make it a legal issue.
Maybe it’s made a little more complex because a lot of authors don’t want to “punish” the company involved so much as they just want people to comply with the terms of the license, and a lot of companies aren’t violating the license out of maliciousness but just from lack of knowledge or it just being more difficult than it sounds to keep your ducks in a row with source availability.
FWIW, I know Android phones generally have something buried in the settings where it explains what the licensing is for the code on the phone and with a theoretical offer for the source if you want it. That seems like what the Youtube talk is about; just creating the technical tools so that people can be in compliance without it being a pain in the butt that costs your engineers time and costs you money to do which companies are going to be tempted to avoid. But yeah, maybe people are getting sloppy about it in a way I wasn’t aware of; that’s sad to me if so.
The entire linked article is talking about “open source” in terms of the GPL specifically.
On what is your doubt based? Like what devices do you have that you think are violators? Like I say I imagine that careless violations aren’t, like, un-heard of, but correcting them once things are explained is almost always the response. I mean, correcting the violation is usually free and easy. I’m not real familiar with the SFC, but I know they’re actively suing Visio right now, and I know the FSF is happy to bring cases to trial if it comes to that (they kind of like doing it it seems like).
They were selling TVs with GPL-licensed software inside without complying with the terms of the GPL. When challenged, their defense was some version of “But it’s completely free for anyone to use!”
They didn’t have to give up every one of their TVs of any model, just the infringing models (the ones that used Busybox without complying with the GPL).
Generally speaking I agree; I like how Perens is thinking about it.
I do think it’s pretty well established that the GPL “has teeth” though. The FSF has a list of enforcement cases against fairly large defendants; it looks like their record is 2 for 2 in the US. I think it rarely comes up, just because complying with the terms of the license is so no-brainer-ly easier than trying to make the legal argument that you can use someone else’s stuff for free while thumbing your nose at the terms and conditions they want you to abide by in order to do that.
I think most of the “big company ignores the GPL” things you hear about are either things like RHEL, where they’re carefully skirting the line in a clearly bad-faith way that has some decent chance in court for some particular reason, or else someone breaking the GPL and then their legal department looking at it for 2 seconds and telling them to stop doing that. The cases where someone with anything to lose actually doubles down and says “fuck you” are rare I think for pretty obvious reasons.
(Also, I just learned this today: When Best Buy did this in 2009, the judge eventually made them give the plaintiffs the TVs as part of the damages when it was all done. That’s the funniest thing I’ve heard all week.)
This is a common misconception. A couple times, it’s even gone to court. Both Cisco and Best Buy had to pay nontrivial amounts of money, and in the case of Best Buy, it hilariously had to give to the plaintiffs its inventory of TVs which contained software copyrighted and GPL-licensed by the plaintiffs.
GPL licensed does not in any world mean “completely free for anyone to use”. For end-users, it does. For companies that want to resell the GPL-licensed software, it means, you can do it for free if you comply with the terms of the license, and if you don’t, then you can’t. There’s not a monetary exchange, but there are licensing terms you need to comply with which were apparently important enough to the people that wrote the software for them to apply that particular license instead of some other one.
If you disagree, that’s completely fine, but that doesn’t mean you can all of a sudden resell their software and use their work for free, even if there are other people (in compliance with the license) who can.
Can you elaborate on this?
I think we’re saying the same thing; maybe I worded it confusingly. BSD is supposed to allow proprietary-ization, and GPL is supposed to prevent it. Apple is within both the letter and spirit of the BSD license with what they’re doing with iOS. Google is technically within the letter of the GPL with how they distribute Android, just as Redhat is technically within it in how they distribute RHEL, and honestly maybe both cases are fine, but it’s far from the intent. The spirit of the GPL is that people who would receive an Android phone would know that the relevant parts of their phone’s software are open source and have a realistic ability to modify them, which I’d argue is true for pretty much 0% of even tech-savvy users today.
If the courts would just back that up, you would be able to recompile all the GPL’d parts of your smartphone’s firmware and run that on your phone.
Firmware? You mean kernel, right? (in addition to whatever low-level userland tools are GPLd, which I’m sure is a bunch.)
I don’t think Google really did anything wrong here. The letter of the law is being upheld pretty well in what they’re doing. I think the issue is the cell phone manufacturers making it de facto impossible to modify your cell phone. I don’t think the GPL actually makes any requirement for modifying the software in-place being a requirement (nor should it IMO), and providing the source code is done carefully in accordance with the license. It’s very different from the “fuck you I take your stuff, sue me hippie” stance that Broadcom took. Broadcom very clearly broke the law.
In my opinion, the issue is that a cell phone is such a free-software-hostile environment that arguably GPL software shouldn’t “be allowed to” come into contact with it in any capacity if the spirit of the GPL were being upheld. IDK how you can write something like that into a license though. And I think that’s what Perens is saying – that we need a new model that comes closer to the spirit in terms of what the actual result is.
(Edit: Actually, maybe making it a realistic possibility to drop in a recompiled replacement should be a part of the GPL. I remember people were talking about this decades ago with signed bootloaders and things, so that a recompiled kernel wouldn’t boot on particular machines unless you broke the DMCA by doing something to your hardware. I said I wouldn’t like any attempt in the license to forbid that, but on reflection, it sounds like maybe a pretty good way to better uphold the spirit of the GPL with particular legal language.)
Did you read the article? This is 100% the opposite of his point. He wants to, among other things, publicly fund development of open source, at the expense of private companies which are currently profiting from it in arguably-abusive fashion.
I wasn’t too psyched about reading this article, but I was surprised at how sensible it is – among a bunch of pretty good points he makes, this is one of them:
Another straw burdening the Open Source camel, Perens writes, “is that Open Source has completely failed to serve the common person. For the most part, if they use us at all they do so through a proprietary software company’s systems, like Apple iOS or Google Android, both of which use Open Source for infrastructure but the apps are mostly proprietary. The common person doesn’t know about Open Source, they don’t know about the freedoms we promote which are increasingly in their interest. Indeed, Open Source is used today to surveil and even oppress them.”
From the end user’s point of view, there is absolutely no open-source-ness to your Android phone. (BSD which iOS is based on was always designed to make this a possibility, but the GPL was not.) They’re using all this software which was supposed to be authored under this theory of GPL, but except for the thinnest thinnest veneer of theoretical source availability, it’s proprietary software at this point.
RMS actually talked about this. He laid out this vision of this bright future where you’d always have access to the source code for all the software on your computer and the rights to take a look at it or build on it or modify it, and some reporter said, well yes but what about all these other urgent problems that are ruining the world with private industry trying to make money at all costs and destroy it all. And RMS said, more or less: Yes. It bothers me a lot. But I don’t really know about that, and I know software, and I felt like in this one specific area I could write a bunch of software and solve this one problem in this one area where I felt like I could make a difference. If other people could get to to work on these other more urgent problems that’d be great, because they also bother me a lot.
Yeah. Seeing the development thought process at work during the engineering of git was really cool. The philosophy was basically, at its core it’s not a version control system. It’s a content-addressable filesystem. That’s what you need in order to build a good distributed version control, so we’ll make two layers and make each one individually very good at what it does. Then in a UI sense, the idea was to give you the tools to be able to do needed operations easily, but still expose the underlying stuff if you need direct access to it. And then to optimize the whole thing to within an inch of its life under the types of workloads it’ll probably be experiencing when being used as version control.
It was also, as far as I’m aware, the first nontrivial use of something like a blockchain. The property where each commit is referred to by its hash, and the hash encompasses the hash of the previous commit, was a necessary step for security and an obvious-in-retrospect way to identify commits in a unique way.
Basically the combination of innovative design with a bunch of core concepts that weren’t really commonly in use at the time, combined with excellent engineering to make it all solid and working well, was pretty mind-blowing to see, and it all came together in just a few weeks and started to get used for real in a big sense. Then, the revolution accomplished, Linus handed git off to someone else and everyone just got back to work on the kernel.
I’m one of those who was unfortunate enough to use SVN.
Same. I guess I’m an old guy, because I literally started with RCS, then the big step up that was CVS, and then used CVS for quite some time while it was the standard. SVN was always ass. I can’t even really put my finger on what was so bad about it; I just remember it being an unpleasant experience, for all it was supposed to “fix” the difficulties with CVS. I much preferred CVS. Perforce was fine, and used basically the exact same model as SVN just with some polish, so I think the issue was the performance and interface.
Also, my god, you gave me flashbacks to the days when a merge conflict would dump the details of the conflict into your source file and you’d have to go in and clean it up manually in the editor. I’d forgotten about that. It wasn’t pleasant.
Git interface really shows the fact that it is created by kernel developers for kernel developers (more on this later).
Yeah, absolutely. I was going to talk about this a little but my thing was already long. The two most notable features of git are its high performance and its incredibly cryptic interface, and knowing the history makes it make a lot of sense why that is.
Mercurial interface, on the other hand is well thought out and easy to figure out. This is surprising because both Git and Mercurial share a similar model of revisions. Mercurial was born a few days after Git. It even stood a chance for winning the race to become the dominant VCS. But Mercurial lost kernel developers’ mindshare due to Python - it simply wasn’t as fast as Git.
Yeah. I was present on the linux-kernel mailing list while all this was going on, purely as a fanboy, and I remember Linus’s fanatical attention to performance as a key consideration at every stage. I actually remember there was some level of skepticism about the philosophy of “just download the whole history from the beginning of time to your local machine if you want to do anything” – like the time and space requirements in order to do that probably wouldn’t be feasible for a massive source tree with a long history. Now that it’s reality, it doesn’t seem weird, but at the time it seemed like a pretty outlandish approach, because with the VCS technologies that existed at the time it would have been murder. But, the kernel developers are not lacking in engineering capabilities, and clean design and several rounds of optimization to figure out clever ways to tighten things up made it work fine, and now it’s normal.
Perhaps this is no more apparent than in the case of quilt. Quilt is a software that is used to manage a ‘stack of patches’. It gives you the ability to absorb changes to source code into a patch and apply or remove a set of patches. This is as close you can get to a VCS without being a VCS. Kernel devs still use quilt sometimes and exchange quilt patch stacks. Git even has a command for importing quilt patch stacks - git-quiltimport. There are even tools that integrate patch stacks into Git - like stgit. If you haven’t tried it yet, you should. It’s hard to predict if you’ll like it. But if you do, it becomes a powerful tool in your arsenal. It’s like rebase on steroids. (aside: This functionality is built into mercurial).
That’s cool. Yeah, I’ll look into it; I have no need of it for any real work I’m doing right now but it sounds like a good tool to be familiar with.
I still remember the days of big changes to the kernel being sent to the mailing list as massive series of organized patchsets (like 20 or more messages with each one having a pretty nontrivial patchset to implement some piece of the change), with each patch set as a conceptually distinct change, so you could review them one at a time and at the end understand the whole huge change from start to finish and apply it to your tree if you wanted to. Stuff like that was why I read the mailing list; I just remember being in awe of the type of engineering chops and the diligence applied to everyone working together that was on display.
I recently got into packaging for Linux. Trust me - there’s nothing as easy or convenient as dealing with patches. It’s closer to plain vanilla files than any VCS ever was.
Agreed. I was a little critical-sounding of diff and patch as a system, but honestly patches are great; there’s a reason they used that system for so long.
As I understand, the biggest problem was that not everyone was given equal access. Most significantly, many developers didn’t have access to the repo metadata. The metadata that was necessary to perform things like blame, bisect or even diffs.
Sounds right. It sounds like your memory on it is better than mine, but I remember there being some sort of “export” where people who didn’t want to use bk could look at the kernel source tree as a linear sequence of commits (i.e. not really making it clear what had happened if someone merged together two sequences of commits that had been developed separately for a while). It wasn’t good enough to do necessary work, more just a stopgap if someone needed to check out the current development head or something, and that’s it.
That sounds accurate. To add more context, it was Andrew Tridgell who ‘reverse engineered’ it. He became the target of Torvald’s ire due to this. He did reveal his ‘reverse engineering’ later. He telnetted into the server and typed ‘help’.
😆
I’ll update my comment to reflect this history, since I didn’t remember this level of detail.
Everything Wordpress is heavily infested with that. However you don’t have to let it impact you – it kind of looks to me like they pressure commercial vendors to put their stuff under the GPL if they’re wanting to offer a free version, so there’s a robust ecosystem of actually-FOSS tooling for it. My experience has been that it’s always worked pretty well in practice; you just have to keep your nope-I’m-not-paying-for-your-paid-version goggles firmly affixed. (Also, side note, GPT does an excellent job of writing little functions.php snippets for you to enable particular custom functionality for your Wordpress install when you need it.)