1. 12
  1.  

  2. 9

    A less publicized and unintended use of the GPL is that it is very favorable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior.

    That’s quite a claim. Is there evidence to back it up?

    I’ll admit I focused much of my reading on the GPL Advantages and Disadvantages, and BSD Advantages sections. (Because if it wasn’t clear this article is biased, the BSD section title doesn’t announce Disadvantages). I personally find some of the disadvantages listed for GPL to be advantages, and the potential for abuse by corporations of the BSD to be downplayed.

    1. 9

      I expected the article to be biased as it’s on the FreeBSD site. Also, I found it odd that this bit:

      In contrast, those who expect primarily to use a system rather than program it, or expect others to evolve the code, or who do not expect to make a living from their work associated with the system (such as government employees), find the GPL attractive, because it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially “burying” or orphaning the software.

      was listed under the BSD Advantages section. This is an advantage of the GPL—allowing users to obtain the source code so they can continue to use and improve it even if it’s orphaned.

      1. 5

        Note that the title is why you should use the BSDL for your project, so advantages that are only advantages to consumers of your code who don’t contribute anything don’t count. That said, I don’t really like this article. My main reasons for preferring permissive licenses pretty simple:

        • I want to be able to get contributions from as many people as possible. In my experience, a copyleft license puts off more contributors than a BSD license. I’ve worked with companies that have paid for someone to rewrite LGPL’d libraries that they were using internally (not even distributing) and then open source them rather than have to properly understand what the LGPL does and doesn’t let them do.
        • If I get external contributors and I want to reuse their code in another project (personal or for work) I don’t need to think about it.
        • I know some fantastic IP lawyers and I’m happy to talk to them but getting a straight answer from them about a point of law is almost impossible and I really, really don’t want anything I do to be gated on this. Even the LGPL is quite fun here because it tries to encode the C compilation and linkage model in legalese. If I take an LGPL’d library (e.g. GNUstep Base) and dynamically link it with my application, which provides a category that replaces one of the undocumented internal methods on a core class (such that any user who replaces their version of the shared library will keep using my version), am I violating the LGPL? How does LGPL work with header-only C++ libraries?
        • More philosophically, I don’t believe that the GPL works well from a psychological perspective. Folks who have been forced to release code by the GPL are never enthusiastic participants in a Free Software ecosystem. The GPL encourages people to come up with exciting work arounds, which then lead to more complicated versions of the license to try to close the loopholes (see: nVidia Linux drivers, for example). I’d rather that people who want to just consume BSDL code do so and go away: they can deal with all of the problems of merge conflicts and upstream implementing incompatible versions of their features and then decide to participate in the ecosystem because they see concrete benefits. This process often takes 10+ years but at the end the companies that have learned this lesson are great to work with.

        Most copyleft licenses don’t protect against the threat models I care about for Free Software because they’re entrenched in the COTS model. The GPL didn’t prevent Google from having a private fork of Linux with their own filesystem drivers and not sharing the changes. AGPLv3 might, but it’s not entirely clear to me that it actually works in practice (and it definitely does put off a lot of potential contributors). I might put up with some of the other disadvantages if they actually helped me address this (I might not - it actually doesn’t bother me if other people make something better out of my code, it’s just a bit rude if they don’t share it with me).

        1. 2

          I’ve worked with companies that have paid for someone to rewrite LGPL’d libraries that they were using internally (not even distributing) and then open source them rather than have to properly understand what the LGPL does and doesn’t let them do.

          What I’m getting out of this is LGPL code creates paying jobs :)

          1. 1

            I’d rather that people who want to just consume BSDL code do so and go away

            In case you care about community around a software product (not everybody does): That only works if they can’t make their variant the dominant version and make everybody else “go away”, too. A BSDL Linux (without the USL lawsuits in recent memory that plagued everything *BSD) managed by IBM (if they’re smart, hiding behind a trade org like Linux Foundation, and inviting their UNIX buddies) that offers extra features could have blown apart the “upstream” BSDL Linux variant.

            So what we have now is a similarly managed but still fully open Linux.

            What the “have to come up with exciting workarounds” strategy offers is that it always keeps troublemakers at least a bit off-balance: Their IP lawyers are just as unwilling to give a definite rule to go by as yours are.

            1. 6

              So what we have now is a similarly managed but still fully open Linux.

              Do we? I suppose that’s mostly true for the kernel, but the dominant flavour of Linux today is Android and it is very difficult to take a particular vendor’s Android and make it work. If you remove all of the non-Free Google bits from Android, you end up with a system that can’t even run all of the things in F-Droid due to their dependencies on Google Play Services and you’ll quite often see drivers with a vaguely open shim that don’t work with new kernels or 100% proprietary drivers on the Android HAL infrastructure.

              IBM is now the owner of Red Hat and controls systemd and glibc and has exerted a lot of pressure on the rest of the ecosystem to make it hard to run desktop Linux software without building dependencies on IBM-controlled technologies. They’ve done exactly what you suggest: put things in the Linux Foundation, invited a bunch of other companies.

              Neither Google nor IBM needs a proprietary fork to exert control over their ecosystems, even if they were to start with something BSDL’d they probably wouldn’t do more than they’re doing now.

              1. 1

                Neither Google nor IBM needs a proprietary fork to exert control over their ecosystems, even if they were to start with something BSDL’d they probably wouldn’t do more than they’re doing now.

                I disagree, but then Fuchsia is BSDL (with userland BSDL or Apache-L which is mostly the same, just in many more words), so I guess we’ll see.

                1. 1

                  I suppose that’s mostly true for the kernel

                  That’s barely true for the kernel, too. In 10+ years of working on embedded Linux gadgets of various kinds I have never, not even once, used, or seen, a device using anything near a vanilla upstream kernel. I don’t mean developer boards and the like, I mean real-world products. There are some success stories but replicating them is difficult to the point of being impossible unless you’re on really good terms with enough suppliers and service providers (so basically unless you’re either a company the size of nVidia, or a small company whose CTO/CEO/C-whatever used to work for a company the size of nVidia).

                  A good hunk of my job, at various times, consisted in either getting various modules/peripherals/devices/whatever that were supposedly supported upstream to work (which required anything from trivial fixes in upstream drivers to significant rewrites), or getting various manufacturer-supplied drivers to work. The story with the latter being that the device “supported Linux” as in the manufacturer would give you a BSP running on some Frankenstein kernel from four years ago and the driver had to be ported to some other Frankenstein kernel from two years ago.

                  Most of these “local” fixes never make it upstream. Mine certainly didn’t. Mostly for the reasons you’d think they don’t, like bureaucracy or lawyers, both of which are a thing for any open source contributions but are two extremely big things for GPL contributions. Others are kept in house for reasons that have nothing to do with community building, though (e.g. fixes don’t get contributed because upstream is broken enough that being able to get it to work on $hardware brings in a lot of customers by word of mouth).

                  (Edit: I’ve also seen the opposite effect. $company has a “strategic interest” in a particular program or subsystem and it contributes a lot of code. Most of it is garbage, and it gets in because the maintainers doing the reviews also work for $company and upstream eventually just becomes $company’s working tree).

                  Desktops and laptops are a somewhat special case, for a variety of reasons (open standards, widespread availability, inertia, Windows drivers to reverse engineer and so on) but generally speaking, it’s very hard to get the upstream Linux kernel and make it work. Even on platforms that are pretty well-supported – there are plenty of SoC vendors that treat Linux as a first-class citizen and upstream support really is good, but as soon as you hook up a peripheral that you can realistically use for volume production to it, you’re screwed.

                  IMHO the GPL made a lot of sense way back, but like many other things, IP lawyers figured out how to use it for, uh, other purposes, too, not all of them conducive to competitiveness. BSD stood the test of time a little better, if only because it didn’t try to restrict as many things as the GPL did.

                  1. 1

                    it’s very hard to get the upstream Linux kernel and make it work

                    I wonder if that is because embedded Linux is not a priority for Linus. He cares about his desktop and he cares about the servers of those who finance his income (through Linux Foundation).

                    1. 2

                      I can’t speak for Linus but embedded Linux is not just a huge area in and of itself, it’s a huge part of the kernel as well. Until a few years ago, that’s what drove kernel support for ARM and PowerPC, a whole lot of work in the USB subsystem, and an uncanny amount of drivers, to name just a few things.

                      It’s not that embedded Linux isn’t a priority for upstream kernel development, it’s just that upstream kernel development isn’t much of a priority for a lot of hardware vendors. For every vendor like… dunno, Analog Devices, or ARM, there are ten vendors that will just give you a four year-old BSP with kernel 4.2 and if you don’t like it go ahead and port it yourself. You can always go for other vendors, of course, and you’ll often get much better hardware, too, but good luck meeting the budget constraints that consumer devices have today, when they’re supposed to go obsolete in a year or two.

                      1. 2

                        It’s been 0 years since I last bought a device that unironically used 2.6.x.

          2. 4

            I have to admit that I’m personally a bit bothered by the trend lately of projects switching to copyleft and “shared source” type licenses as an anticompetitive tactic. The people who originally started a project and hold the copyright can use these types of licenses — combined with CLA/assignment — to set up a position where they get to do proprietary-style things like a SaaS business with “secret sauce” bits they don’t release, while forbidding any competitor from doing so. I’ve never understood how that promotes “software freedom”, or is supposed to be good for users who get trapped in an effective proprietary monopoly.

            1. 3

              Indeed, whether the FSF intended it to be used as such or not, the largest AGPL users seem to be using it effectively to promote sales of proprietary license exemptions.

              1. 3

                It’s always amused me somewhat that the FSF’s revenue used to be almost entirely from the sale of proprietary software: if you violated the license on an FSF project then they would sell you a retroactive license with an explicit sunset clause (at which point you had to be in compliance).

                The kind of dual-licensing that MySQL and others did always bothered me because it is an explicit statement that the Free Software version is less valuable than the proprietary one: the proprietary one is expensive, the GPL’d one is free. This is the exact opposite of the message that I want to be sending: that the Free Software version is more valuable than the proprietary one.

              2. 1

                I’ve never understood how that promotes “software freedom”, or is supposed to be good for users who get trapped in an effective proprietary monopoly.

                “Shared source” doesn’t claim to be about software freedom.

                As for copyleft, the original sin might have been the FSF establishing the idea of CLAs in the copyleft context. Yeah, they’re all great and will always be splendid stewards (but will they?) but through this they provided a blueprint for open core models.

                In any case, the issue arising out of CLAs is easily fixed: Fork software that requires CLAs (or anything like that) at the earliest opportunity, and move the community to where there is no single arbiter of ownership. Shared source models don’t offer the same opportunity.

              3. 2

                That’s quite a claim. Is there evidence to back it up?

                From a BSD perspective, Linux ate their lunch. That IBM (large company) announced to “spend one billion dollars on Linux” (marketing weapon) back in 2000-or-so, affecting (undercut) various smaller BSD outlets (“software companies”), might be part of that lore.