[HN Gopher] In the long run, GPL code becomes irrelevant (2015)
___________________________________________________________________
In the long run, GPL code becomes irrelevant (2015)
Author : Expurple
Score : 35 points
Date : 2025-07-18 15:34 UTC (7 hours ago)
(HTM) web link (josephg.com)
(TXT) w3m dump (josephg.com)
| NewsaHackO wrote:
| >But think of the multi-trillion dollar companies!!
|
| If companies want to use manpower to reimplement GPL code, then
| fine. It's always funny how accommodating people are for these
| companies.
| Expurple wrote:
| The point of the article is that:
|
| 1. In most areas, they eventually will!
|
| 2. If there is a permissively-licensed project in that area, at
| least there's a decent chance that the "reimplementation" will
| be a fork of that project. At that fork has a decent chance of
| staying open or even being merged back into the upstream. That
| benefits the community more than a proprietary from-scratch
| rewrite (which would follow from a GPL-only open-source scene)
| lc9er wrote:
| So if we're nice to the billionaires, they may return that
| kindness with table scraps - if we're lucky? Sounds like the
| tech version of trickle-down economics.
| rglullis wrote:
| Yeah, I don't get that argument. "Apple is funding LLVM,
| therefore it is getting better than GCC!". They are only
| funding it because it advances their goals. The moment they
| get what they want they will drop it or look for ways to
| keep the advantage all to themselves.
| Expurple wrote:
| The same could be said about non-corporate contributions.
| "People only contribute as long as they have a personal
| itch to scratch. The moment they get what they want,
| you're on your own again".
|
| That's always been the deal. Open source is not a
| guarantee of free support forever! It's a guarantee that
| you can always fork and keep using the project (or even
| developing it further)
| lanstin wrote:
| It's just the academic method of sharing your work so the
| collective knowledge and state of the art increases
| monotonically. People seem to like to productive it, but
| even just publishing your source code so I or my llm can
| read it and modify it is useful. Very useful.
| rglullis wrote:
| I'm less concerned about "free support" and more about
| "commons-oriented R&D".
|
| There are some projects/people that I donate a small
| monthly amount. I don't do it because I'm expecting a
| specific feature to be developed, but simply because I
| think it's important to have support developers and let
| them work on something without being concerned about how
| to make a living out of their work.
| Expurple wrote:
| Indeed, that's a very important thing to foster! In fact,
| I published a post about this just two days ago:
| https://home.expurple.me/posts/non-profit-foss-solves-
| the-co...
| umanwizard wrote:
| Everyone only does anything if it advances their goals.
| Luckily Apple's goals w.r.t. LLVM are the same as
| everyone else's: have a high-quality compiler backend.
| rglullis wrote:
| Beware of sweeping generalizations. _Most people_ only do
| things when it advances it goals, but there certainly are
| people that do things simply because they think is the
| right thing to do.
| Expurple wrote:
| "Doing the right thing" (whatever that means for a person
| specifically) can be considered a goal too. Goals don't
| have to be selfish.
| rglullis wrote:
| A goal implies a clear objective. "Doing the right thing"
| is a guiding principle.
| Expurple wrote:
| "Following my inner guiding principles without
| compromising" seems clear enough. I don't think that you
| have to fully verbalize and rationalize your principles
| in order to commit to a clear goal of following them. You
| clearly feel when you do the wrong thing.
| Expurple wrote:
| Yes, but what's the better alternative? The article makes
| the point that you're not even getting table scraps back
| into your GPL project. In most cases, the companies prefer
| a proprietary rewrite. Now you're just stuck with a less-
| developed project, while the world around you uses more-
| developed proprietary alternatives and pushes you to do the
| same. But I guess, that somehow makes you feel better
| because you don't let the corporations "feed off your work"
| and instead just waste everyone's time on infinite
| rewrites?
| elsjaako wrote:
| I don't see why a company that refuses to add to a GPL
| project has a "decent change" of releasing their code under a
| more permissive license.
|
| If you're going to talk about theoretical behavior from big
| companies, you can make stories any way you want.
|
| Let's say a big company selling computers wants to include a
| PCB editing software by default. If KiCAD was Apache licensed
| they may be tempted to make a special version for their
| customers, as a unique selling point. But it's GPL, so they
| have to choose between rewriting completely (a huge process),
| or just publishing the changes and being happy to include a
| good program.
|
| Or a company makes modifications to a GPL program for
| internal use, and decides they want to share it with
| partners/customers later.
|
| I have no reason to think these stories are more or less
| likely than the story of a company completely rejecting the
| GPL option but still deciding to upstream their changes.
| m4rtink wrote:
| Didn't Sony gobble up a whole bunch of stuff from FReeBSD
| for the last few Playstation release without hardly
| contributing anything back at all ? IIRC the might have
| sent some patches to improve SMP or sponsored a conference.
|
| Same with Microsoft and the Windows TCP stack lifted from
| BSD as well.
|
| Compare with GPL licensed projects, like the Linux Kernel &
| its license making many projects possible, like the OpenWRT
| project for example.
| phkahler wrote:
| Yeah I see a lot of corporate backing of Linux (GPL) and
| a bit of proprietarization of non GPL OSS. Meanwhile my
| employer also uses git and gcc, which are both GPL.
|
| Companies that _use_ software like it Free. Companies
| that _develop_ software like it permissive. There are
| more users than developers, especially for large more
| important programs.
| umanwizard wrote:
| > I don't see why a company that refuses to add to a GPL
| project has a "decent change" of releasing their code under
| a more permissive license.
|
| It's simple in my experience.
|
| Many big companies have some set "A" of code that they want
| to keep private, and some set "B" that they don't care
| about keeping private.
|
| Lawyers are worried that at some point someone will
| accidentally include GPL code in something from "A" and
| force it to be made public. So they ban GPL entirely. They
| could in theory just ban GPL code from "A" and allow it in
| "B", but they can't trust that among thousands of employees
| none will make a mistake, so they just ban the GPL
| entirely.
| Expurple wrote:
| > I don't see why a company that refuses to add to a GPL
| project has a "decent change" of releasing their code under
| a more permissive license.
|
| Because upstreaming a patch once is cheaper than
| maintaining your own proprietary fork forever. It
| externalizes the effort of maintaining it in the future.
| That's the point that the article makes. And it's true in
| my experience. My employer allows and encourages me to
| contribute back to our dependencies. Those aren't the core
| of our business and our competitive advantage
| throw_m239339 wrote:
| Some people always forget that GPL is about the end user's
| rights, not developer's rights. If a fortune 500 re-implements
| some GPL library to make proprietary, then by all means. It
| changes nothing for the GPL code, it's still GPL and its
| license should guaranty user's rights.
| Expurple wrote:
| But a proprietary fork doesn't change anything for
| permissively-licenced projects either! The open original is
| still available, you can still use it and fork it. If it's a
| popular project, a community-maintained fork will always
| happen.
|
| As a user, permissive licences give me _enough_ freedom.
| bombcar wrote:
| It may be true, but the GPL is uniquely positioned to create a
| floor that ratchets upwards, whereas the other licenses are
| susceptible to being consumed and extended.
| conartist6 wrote:
| I thought the author made the case that because of complexity
| economics the ratchet still works either way, and in fact that
| in 2025 GPL is actually _a less-strong ratchet_ compared to
| Apache and MIT. If GPL was the stronger Ratchet you wouldn 't
| ever expect to see an existential risk to a GPL project posed
| by an Apache one right?
| Expurple wrote:
| True, but the article makes a point that it's very hard and
| unlikely to maintain technological superiority over a
| coproration that's determined enough. A corporation simply has
| much more resources. See also:
| https://hypercritical.co/2013/04/12/code-hard-or-go-home
| ranger_danger wrote:
| > maintain technological superiority
|
| Is this ever an actual goal for most GPL projects? Usually
| the ones I talk to are not even interested in gaining more
| users.
| Expurple wrote:
| From a developer/business point of view, there's no reason
| to use a more restrictive GPL dependency if it's not
| clearly "superior" to a permissively-licensed one.
|
| The article makes a case that this will eventually push GPL
| out of the mainstream. No one will use GPL because they
| "have to" (which is the whole premise of copyleft!). It
| will only be used by enthusiasts
| ranger_danger wrote:
| I think those same people I mentioned would argue that
| being mainstream is also not a project goal, nor is
| utilization by corporations at all.
|
| I have to admit I think a lot of people with this sort of
| "death to capitalism" mindset simply won't get anywhere,
| because they literally don't want to. I guess that means
| they may eventually fade into obscurity.
|
| But the majority of project leaders I have talked to all
| seem to follow this mindset... they're not interested in
| making money, and "this is not a popularity contest."
|
| Yet when a fork inevitably emerges, they go nuclear.
| Reminds me of a quote I saw one time... "they don't want
| open source, they want to be the ONLY source."
| phkahler wrote:
| But software developed by enthusiasts might be better
| than software designed by managers and hoards of
| beginners using AI.
| Expurple wrote:
| Software developed by enthusiasts that also receive
| patches from corporations (that can use the software
| thanks to a permissive licence) might be even better
| singpolyma3 wrote:
| If the business wants to develop non open source
| software, then having them not use the GPLd project and
| thus profit off the free labour of others is a wonderful
| outcome.
| Expurple wrote:
| Your argument is in terms of "fairness". But most users
| don't care about fairness. They care about better
| software. I'll use a permissively-licensed project if
| it's better. Most people will use a proprietary project
| if it's better.
|
| The article makes a point that permissively-licenced
| projects have the best survival characteristics, and
| that's why most (quality) software will eventually be
| permissively-licensed, while GPL will fade into obscurity
| and will be used only by enthusiasts why care about
| fairness more than they care about the actual quality of
| the software that they use.
| axus wrote:
| I'd say no, crushing / surpassing the competition is not a
| goal for non-commercial software and it doesn't have to be.
|
| The thesis is that "GPL code becomes irrelevant", and they
| are probably right about GCC. It doesn't mean GCC goes
| away, just that it will become irrelevant to more people.
| Sun Studio and Borland C++ are even more irrelevant, not
| sure where that fits in the conversation. Is MS Visual
| Studio becoming irrelevant?
| leidenfrost wrote:
| While it's not the explicit goal, it was because of
| technological superiority that most of us got into free
| software in the first place. There was a time where Linux
| worked great while Windows 98/XP struggled to maintain in
| its own feet without crashing down (yes, even XP)
|
| While there's nothing wrong with purely enthusiast
| projects, they never got the amount of traction practical
| FOSS projects get. How many users does SerenityOS have,
| compared to Linux?
|
| I invite people to ask themselves, do we really want a
| "pure hobbyist Linux OS"? How many modern feature are we
| willing to surrender for it?
| phkahler wrote:
| >> technological superiority
|
| Haha. I work on Solvespace which is technically inferior to
| FreeCAD, which is also inferior to the big commercial
| offerings. We shall have our MVP in a few more years! Most
| our contributors would not be working on it under an MIT
| license. I certainly would not.
| Expurple wrote:
| Most users and contributors put the functionality above
| copyleft. You are a minority. The article doesn't imply
| that you don't exist. It implies that copyleft projects
| such as yours will be largely pushed out of the mainstream.
| And that it will happen even faster when a project is
| clearly inferior and can't offer anything that's not
| offered by a permissive project that can be used anywhere
| without legal headaches. Such permissive projects will
| always spead and develop faster, all other things being
| equal
| mouse_ wrote:
| > The flaw is that in the long run, it keeps getting easier to
| write software. And people love reinventing the wheel.
|
| See: Bram's Law
|
| https://files.catbox.moe/qi5ha9.png
| djmips wrote:
| The most annoying part about reinventing the wheel might be
| renaming the wheel.
| conartist6 wrote:
| Great writeup! I couldn't agree more.
|
| I've been thinking about this a lot recently, because GPL was
| meant to ensure that vendors couldn't take OSS, turn it into
| closed source, and use it to extinguish the OSS.
|
| As JS-writing eng I live in an MIT-native offshoot of the OSS
| world and for us the ratchet that ensures we always get more and
| more free software is basically the fact that when your product
| is a script run in a scripting engine you can't ever truly hide
| anything.
|
| Since we have an alternate ratchet that has proven that it works
| to increase the amount and quality of OSS (over a 20-year time
| period), the GPL does seem as you say: a relic of times when we
| it seemed like software might only be a hobby.
|
| I'm writing a VCS kernel, basically, and its cost me the last 5
| years of my life. My code is MIT. Do I have to think about the
| dangers of embrace-extend-extinguish? Yeah, but having the best
| product is a very strong defense, and building the widest
| coalition of supporters you can is how you get there.
| conartist6 wrote:
| To be more clear: my strategy is to eliminate the room that
| could be used to undercut me with more virulent technological
| or techno-social solutions.
|
| GPL would not be eliminating the room to undercut me with a
| slightly more viral clone of my product, but rather creating
| more room to undercut me. This is a real problem for a piece of
| software the value of which is in simplicity not complexity!
| konstantinua00 wrote:
| using BSD/MIT licences is like betting against black swan event
|
| sure, "contributing is cheaper than maintaining a fork" is true
| most of the time - but the moment new Microsoft comes in with
| "embrace, extend, extinguish" (or just copy and change), you're
| doomed
|
| and heck, we had that exact thing happen last autumn, iirc -
| making big news on this website
| elsjaako wrote:
| Can you clarify what happened last autumn? I'm not sure I
| recall.
| Qem wrote:
| Probably this: https://news.ycombinator.com/item?id=43587420
| phkahler wrote:
| That would be one example. What about Redis pulling a
| license change, and the whole WordPress battle for control?
|
| If it ain't GPL and it IS popular, I think those kinds of
| things are more likely to happen than not.
| Qem wrote:
| Stallman is a real visionary warning us about those risks
| since de 80s.
| Expurple wrote:
| That's true. But at the same time, the risk is kinda
| overblown. You can still use the last open version of
| Redis. There's even an open, community-maintained fork
| that you don't have to maintain yourself.
|
| Even GPL can't force a company to maintain and keep
| developing an open version when the company _doesn 't
| want_ to. Even if Redis was GPL (no CLA), they could
| still abandon it and write a compatible clone from
| scratch. AI makes it even easier to do
| Expurple wrote:
| Redis has an open fork. Seems "free" enough to me.
| Companies are not obligated to keep developing the open
| version forever, anyway. If Redis was GPL, they could've
| just abandon it and write a compatible clone from
| scratch. Nowadays, with AI, that even easier to do
| Expurple wrote:
| > you're doomed
|
| You're making a big stretch here. Sure, you can be left in the
| dust behind their proprietary fork, that's true:
| https://hypercritical.co/2013/04/12/code-hard-or-go-home
|
| But your habitual workflow isn't "doomed". You can always fork
| and keep using the same open version of the project that you've
| always used. If the project is popular enough, there's usually
| a community that keeps maintaining that fork.
|
| _That 's_ the deal that you get. Free software was never about
| "free upgrades forever". It's about the freedom to fork.
| phkahler wrote:
| >> Free software was never about "free upgrades forever".
| It's about the freedom to fork.
|
| I never noticed the word "fork" in the GPL. You may want to
| reread it, as I think you missed the point.
| Expurple wrote:
| Are you seriously trying to imply that the GPL isn't
| largely about granting you the freedom to fork? Sure, it's
| _also_ about forcing the copyleft responsibility on you.
| But come on... That 's not even relevant if you don't fork
| or otherwise depend on the project in the first place
| benlivengood wrote:
| In the very long run I'd hope we get sane intellectual property
| law: Software and logic circuitry is mathematics and should be
| unpatentable and trade secret is about the only protection for
| software/firmware/hardware; copyright terms shortened to the
| actual window of profitability (5-10 years) and only applying to
| "business logic". Nothing else makes much sense in the modern
| world; standards and interoperability benefit everyone to such an
| extent and change happens so rapidly that the majority of
| existing IP protection duration only harms historians.
| Expurple wrote:
| Yeah, copyleft has always been just a hack to cope with the
| current legal framework
| eddythompson80 wrote:
| > and only applying to "business logic"
|
| One person's business is another's platform.
| benlivengood wrote:
| That's why I used the scare quotes; I don't have a hard and
| fast rule here for what's legitimate market-making software
| value and what's just rent-seeking.
|
| I think that much of the core features in Desktop Photoshop-
| style products or video games probably requires legitimate
| short copyright, for example. I don't think copyrighting a
| plugin interface or header files or hardware drivers makes
| any sense, unless there's significant creative work like e.g.
| the portions of GPU drivers that trade off appearance and
| speed in novel ways.
| dafelst wrote:
| To me the larger question is whether or not GPLv2 achieves the
| goal of forcing big companies to contribute back to a project
| better than a more permissable license does.
|
| As stated in the article, Linux is the notable success story, but
| anecdotally it seems that the majority of projects with large
| company contributions are licensed with BSD/Apache/MIT but with
| contributor agreement attached.
|
| I wonder if anyone has compiled any data on whether GPLv2 does
| actually encourage contributions more than the more permissive
| alternatives.
|
| GPLv3 isn't even worth mentioning in this context, great concept,
| abject failure to thrive IMO.
| SAI_Peregrinus wrote:
| Ignores the MPL as usual. IMO the MPL is better than
| BSD/MIT/Apache since it prevents your code getting closed, and
| better than GPL by not forcing others to open their code.
| Expurple wrote:
| Indeed, MPL/LGPL are often a better tradeoff than GPL.
|
| But, in theory and according to the article, they should
| experience same effect. Just slower. When a (law-abiding)
| company finally has a strong reason to make some modification
| and keep it private, a proprietary replacement is coming.
| (Sometimes, as a "thin" fork of a permissive project, which
| then gets an engagement boost, reinforcing the point of the
| article)
| yalok wrote:
| Just anecdotally, but this aligns with my observations on the
| trend/growth of successful useful open source projects that go
| with permissive BSD-like license. ~20 years ago there were way
| less of those than now.
|
| And as a SW developer doing client side/apps as well, using
| GPL/LGPL is a total pain and basically cost prohibitive, unless I
| work on my personal small project where I don't care about having
| to/risking to open source the rest of the code and getting
| sued/cloned...
|
| Real life example from ~2010 - we ended up including an LGPL
| library in our mobile app code, and published/upstreamed all the
| modifications we did to that code (mostly ARM optimizations).
| Once the app became popular, our competitors came to us demanding
| the source code of our app - just because iOS didn't support
| dynamic libraries (so we had to statically link it), and giving
| them the object code to relink it wasn't enough for them (which
| would satisfy the spirit of LGPL), because they really wanted to
| see how we hacked around iOS camera input APIs...
| tines wrote:
| > giving them the object code to relink it wasn't enough for
| them (which would satisfy the spirit of LGPL)
|
| So they can take a hike?
| joshuaissac wrote:
| > giving them the object code to relink it wasn't enough for
| them (which would satisfy the spirit of LGPL)
|
| Doesn't that also satisfy the letter of the LGPL v2?
|
| > Accompany the work with the complete corresponding machine-
| readable source code for the Library [...] and, if the work is
| an executable linked with the Library, with the complete
| machine-readable "work that uses the Library", as object code
| and/or source code, so that the user can modify the Library and
| then relink to produce a modified executable containing the
| modified Library
| mananaysiempre wrote:
| Deliberately so, moreover, because distributing object files
| for relinking used to be common[1].
|
| [1] https://lock.cmpxchg8b.com/linux123.html
| znort_ wrote:
| > just because iOS didn't support dynamic libraries (so we had
| to statically link it)
|
| if you develop closed software for a walled garden then relying
| on gpl is still possible but a rather contradictory philosophy.
| i guess the alternative would have been developing all that
| from scratch, or getting it from elsewhere, likely paying for
| it, which would have made those costs even more prohibitive ...
| otoh i really don't understand those prohibitive costs because
| supplying the object code was all you needed. what were those?
| lawyers?
| joe_the_user wrote:
| Yeah, you're saying that BSD code, which you can get for free
| and give nothing, is the most convenient thing for you in
| helping you create closed source commercial programs. Well
| sure.
|
| I'd mention for a commercial library creator, say QT, the GPL
| can be quite convenient because the commercial clients they
| have can't just take their stuff for free and use it but
| instead can use the GPL to sample and then come for a
| commercial license when they're going to use it that way.
|
| That is to say, just about every license that is used today
| serves a particular purpose for vendors and thus none of the
| licenses are likely to go away as long as we have different
| vendors with different aims.
| jeroenhd wrote:
| > using GPL/LGPL is a total pain and basically cost prohibitive
|
| It's not, if you can comply with the license.
|
| If you want to take advantage of free (L)GPL code in statically
| linked binaries without providing the source code to your
| customers, then yes, that is a problem. Although with LGPL the
| linkable binaries should probably be enough.
| ndiddy wrote:
| I agree that permissively licensed projects are more successful
| if you define "successful" as "having the most number of users
| possible". Of course, this "success" often results in the
| unpaid volunteer maintainers being inundated by bug reports and
| feature requests from employees of major corporations, so
| there's drawbacks to that approach.
| uludag wrote:
| > With enough time, any sufficiently large company can implement
| their own version of any software that anyone else has written.
| They usually won't write their own version if a high quality
| opensource version exists with a permissible license.
|
| Is this a true assertion? If you define sufficiently large
| company to be Google, Microsoft, Amazon, etc. then sure, of
| course they can. That's an extremely high bar though and I would
| bet that even then, these companies would have to pick and choose
| their battles.
| Expurple wrote:
| Rewriting "any software" is an extremely high bar to begin
| with. I think, we can agree that smaller utilities and
| libraries can be rewritten by anyone.
|
| Another comment [1] even references the "Bram's Law". It
| basically says that any piece of software that's easy to
| rewrite _will_ be rewritten countless times (and most rewrites
| are going to be bad)
|
| [1] https://news.ycombinator.com/item?id=44606219
| jcranmer wrote:
| One of the interesting things about the experience of LLVM and
| Clang isn't that it's killing off gcc--a decade after this was
| written, gcc is still the compiler of choice for most Linux
| distrubtions--but that it's killing off EDG, the C++ frontend
| that all proprietary C++ compilers used to use. Killing off
| proprietary software because the open source stuff is so much
| better is the vision of Stallman, and it's telling that a
| permissive license has been much more effective than a copyleft
| license in doing so.
| andrepd wrote:
| That's completely orthogonal to the choice of license, but
| rather to the architecture of both projects.
| larsiusprime wrote:
| I can think of at least a few counterexamples. The logic behind
| the hypothesis is decent and tells a plausible story, but I'd
| like to see a more robust analysis; has anyone done one since the
| article was first posted 10 years ago?
|
| Noteable counterxamples (excluding e.g. Linux):
|
| - Git (GPLv2)
|
| - Blender (GPLv2 & 3, from the looks of it)
|
| - Krita (GPLv3)
|
| - MySQL (GPLv2) -- still seems very popular in 2025
|
| - QGIS (GPLv2)
| mananaysiempre wrote:
| Notably, libgit2[1] is GPLv2 with a full linking exception,
| while e.g. go-git[2] is Apache2.
|
| [1] https://github.com/libgit2/libgit2
|
| [2] https://github.com/go-git/go-git
| throw_m239339 wrote:
| Blender used to be proprietary,the community had to raise money
| to buy the source code to make it free software. What a crazy
| success story for opensource.
| boje wrote:
| Don't forget Qt (though I think that's more a corporation
| wanting to create an incentive to make commercial users pay for
| a license)
| dzaima wrote:
| Git - jj[1] uses gitoxide for its git interop/backend (git
| being the backend of jj you're expected to use), both
| Apache/MIT; it functioned so cleanly I assumed it was invoking
| git directly, but apparently it's all custom!
|
| For new things I'd guess PostgreSQL vs MySQL is probably on the
| same order as llvm vs gcc; probably with PostgreSQL being
| better off than llvm even.
|
| [1]: https://github.com/jj-vcs/jj/ (started by a Googler as a
| hobby project, now their full-time job at Google, so kinda fits
| into the "big orgs will replace things with permissive-licensed
| versions" narrative)
| steveklabnik wrote:
| jj does shell out to git for network operations these days,
| but the majority of it is gitoxide, that's right.
| dzaima wrote:
| Ah, that appears true. I just tested some commit creation &
| state inspection commands, didn't bother with network
| stuff.
| steveklabnik wrote:
| It's a recent change, there were just too many folks who
| had network requirements that it couldn't do, so it's
| easier to just piggyback on top of git, which supports
| all that stuff.
| PaulHoule wrote:
| I always use git as a binary and don't have any interest in
| forking it.
|
| Most of the new databases of last 15 years have some kind of
| restrictive license that aims to stop AWS from selling a
| managed version of it that also limits what I can do it. So
| they are dead to me. Postgres is growing not just because it is
| a good database which is taking ideas from document databases,
| but because you can build on top of Postgres and feel confident
| that you can commercialize _or_ open source your work and
| people will be able to use it.
| Guid_NewGuid wrote:
| I think people who prefer GPL and I hope for the same outcomes
| but we have a different (irreconcilable?) philosophical approach
| to getting there.
|
| In my view code (and all knowledge) wants to be free and a
| commons of knowledge enriches the whole world. I am opposed to
| most forms of copyright, patents and intellectual 'property'.
| Aside: My compromise position to this maximalist view is that I'd
| accept a 5 year copyright term with an exponentially increasing
| renewal fee.
|
| For me MIT/BSD/Apache is a way to provide code with minimal
| encumbrances under the current dominant legal system. GPL is an
| attempt to free knowledge that relies on the legal system and the
| threat of men with guns coming to force you to comply. However
| noble the intentions at the end of the day it is reliant on state
| force and reduces freedom, it is very good at providing fees for
| lawyers.
|
| Corporations can't embrace-extend-extinguish open source. This is
| because the source is always available. Sure they can use that
| knowledge to build a new, more popular, thing, but the existing
| source never goes away. It represents an un-enclosable commons.
| bji9jhff wrote:
| > Corporations can't embrace-extend-extinguish open source.
| This is because the source is always available. Sure they can
| use that knowledge to build a new, more popular, thing, but the
| existing source never goes away. It represents an un-enclosable
| commons.
|
| Some counter-examples:
|
| * git is now mostly github
|
| * khtml is now mostly chrome
|
| * linux is now more android and chromeos than linux. Anyhow,
| the plain kernel is deeply corporate.
|
| You can still fork those project. But it would be mostly
| meaningless to do so.
| Guid_NewGuid wrote:
| But this doesn't really contradict the idea, in my view. Our
| existing property framework is built around physical goods
| that experience scarcity. The cost of code duplication is
| zero and it is (barring catastrophe) indestructible. Today
| you can browse the git codebase in the same way as 2 decades
| prior or hence.
|
| All the knowledge in those codebases is preserved for all
| time, freely available to anyone. They have been built upon
| in ways that don't necessarily give back but that wasn't a
| destructive event.
|
| Aside: Though if I remember correctly git and Linux are GPL
| so they create categories of thought-crime under copyleft if
| a judge holds your code to be too influenced by them. How
| influenced is too much? You better have enough money for
| lawyers to find out.
| umanwizard wrote:
| > code (and all knowledge) wants to be free
|
| What does this sentence actually mean? Every time I've heard of
| it it is just stated as an obvious fact with no explanation, or
| it seems to just mean "I want knowledge to be free".
| Guid_NewGuid wrote:
| I had prefixed that with "in my view" but in a purely literal
| sense you're right. Code and knowledge are inanimate objects,
| they don't 'want' anything. The statement is influenced by my
| belief, it is merely a common turn of phrase.
|
| To expand a bit more, code is freely, instantly, trivially
| duplicated, shared and remixed[1]. Much like knowledge there
| is no scarcity for these artifacts without legally mandated,
| police enforced, artificial scarcity. If the full source code
| for anything (Windows 11, EPIC Systems, whatever) was leaked
| tomorrow that would be a non-destructive event for both the
| code and knowledge involved. People work around this with
| trade secrets and intellectual property law but the
| 'entropic' norm is for these things to become more available,
| not less.
|
| [1]: Since we're being literal there is of course some energy
| and time cost to the listed actions.
| umanwizard wrote:
| Some situation being the "entropic norm" that things tend
| to without intervention is not a good reason to prefer it.
| If we allowed everything that costs nonzero effort for the
| state to prohibit, we wouldn't have a civilization at all
| -- the ultimate "entropic norm" is pure anarchy.
|
| So rather than arguing from these philosophical principles
| I think it makes more sense to answer a pragmatic and very
| concrete question: is the world would be better off, or
| worse, for having intellectual property protections? I
| think it's clearly better because the existence of these
| protections encourages people to spend time and effort
| making creative works (including software). That said; I
| think software patents are counter-productive, as are
| extremely long copyright protections for software. But I
| think that for pragmatic reasons, not abstract ones that
| seem to fall apart when you examine them closely.
| phkahler wrote:
| All large FLOSS programs are GPL licensed.
|
| Even with all the Rustaceans rewriting in Rust while abandoning
| the GPL, their flagship - Servo - is GPL licensed.
|
| There is an aversion to CLAs among those donating their time, and
| with that an aversion to permissive licenses.
|
| Im sure both will be around for a long time, but in the very long
| term GPL wins.
| nicoburns wrote:
| Servo is MPL not GPL licensed.
|
| And even even that's a bit of a problem for the Servo project,
| as it makes it hard to move code between Servo crates and other
| Rust ecosystem crates (which are typically MIT/Apache2.0),
| which means that Servo is it's own "island" somewhat
| disconnected from the rest of the Rust ecosystem.
|
| (there's nothing inherently wrong with the MPL, but it being a
| different and incompatible license to the rest of the ecosystem
| does cause problems)
| Expurple wrote:
| Most other "flagships" of the Rust ecosystem (including rustc
| itself and ripgrep) are permissively-licensed, and still
| haven't been "hijacked" by a proprietary fork. Or by a copyleft
| fork, for that matter. Permissive licenses simply have better
| survival characteristics in the long run
| umanwizard wrote:
| Factually not true.
|
| Clang/LLVM: permissive
|
| Rustc: permissive
|
| Firefox: MPL
|
| Chromium: permissive
|
| Postgres: permissive
|
| LibreOffice: MPL
|
| CPython: permissive
|
| and so on...
| ltbarcly3 wrote:
| The fact that very large corporations are willing to spend tens
| and hundreds of millions of dollars to replicate software is
| exactly why the GPL is not irrelevant.
|
| What makes the GPL irrelevant is AI. AI in it's current
| incarnation is basically a magic copyright remover. It can
| memorize all the patterns, tricks, algorithms, and architecture
| of open source software and implement it again. In a few years
| you won't need git because you will just have an AI stamp out a
| git compatible tool if you need one.
|
| So if you care about Freedom, we need to move the battle from
| making sure you can get a copy of the source code to git, to
| making sure you can get a copy of the weights of the AI you are
| using to create software on demand.
| Expurple wrote:
| > The fact that very large corporations are willing to spend
| tens and hundreds of millions of dollars to replicate software
| is exactly why the GPL is not irrelevant.
|
| No, it's the opposite. The premise of copyleft is forcing the
| dependents to contribute back to the community. If the
| corporations are writing proprietary replacements instead of
| contributing, copyleft has failed to deliver on its premise.
|
| _In practice_ , permissively-licensed projects get more
| contributions back and benefit the community more. Simple as
| that.
| ltbarcly3 wrote:
| We have no data on how much has not been contributed back due
| to corporations forking code or just copy pasting it into
| other projects. For all you know permissive licenses have
| dramatically reduced contributions back.
|
| We only know when they contribute, we have no data on when
| they don't. Stories like LLVM are good evidence for what you
| are saying, but the linux kernel is good evidence against it.
| Dozens of companies are forced to work together for the
| common good at a scale and level of resources that is
| unprecedented. Without the GPL this simply wouldn't (actually
| from an economic / game theory standpoint it couldn't)
| happen.
| Expurple wrote:
| It's true that we don't have any definitive data on this.
|
| But I buy the article's argument that upstreaming a patch
| once is simply cheaper than maintaining your own
| proprietary fork forever. It externalizes the efforts of
| maintaining it in the future. This means that public,
| community-maintained, permissively-licenced projects are a
| good deal for companies, and should win from the economic /
| game theory POV
| ltbarcly3 wrote:
| If this is correct then the lgpl would be ideal?
|
| Also, it depends how much value-add they see their
| modifications having. For small tweaks and bug fixes
| they'll contribute it. If they invest a lot of money into
| something, they'll be loath to hand that value over to
| their competitors. There is some tipping point where the
| competitive value (or more realistically the jealous urge
| not to share) of their efforts exceeds the utility of
| easy tracking with upstream changes.
| Expurple wrote:
| Ideal for whom?
|
| It's still not ideal for downstream proprietary
| developers. The requirement to provide some means to
| relink the project is extra headache that can be avoided
| by using permissive dependencies, reinforcing the point
| of the article.
|
| Also, in theory, I can imagine a situation where a
| proprierary developer strongly needs to make a change,
| _and_ for some reason is strongly against open-sourcing
| it, _and_ is strongly law-abiding. And thus, a
| proprietary rewrite is born. Sometimes, instead of a
| complete rewrite, that 's going to be a fork of a
| permissive project, boosting its usage and reinforcing
| the point of the article.
|
| For library authors, LGPL/MPL is often a good tradeoff,
| indeed. You still get all the modifications back, while
| also having more users then you would have with GPL.
| Although, as seen in this thread, enabling proprieraty
| dependents is actually a downside for some authors, due
| to their beliefs.
|
| To me, it looks like LGPL/MPL become irrelevant in the
| "longer" run too.
|
| ---
|
| I agree with you regarding the "tipping point". There's
| nothing we can do about this. In a similar vein, when
| considering a massive investment into a GPL project, they
| are going to conclude that they are better off invesing a
| similar amount into a proprietary rewrite and keeping the
| added value to themselves.
| munificent wrote:
| This article is a decade old. I wonder if the author still agrees
| with it given how the software and corporate landscape has
| changed over the past ten years.
|
| While I have always used maximally permissive licenses on my own
| open source software, I've been rethinking that stance in the
| past couple of years. I'm not sure where I stand now, but I don't
| fully agree with this post.
|
| In particular, perhaps my number one fear about the world at
| large is that the untethered effects of economies of scale are
| clearly leading to a net transfer of power into the hands of
| fewer and fewer corporate leaders.
|
| Permissive licenses are arguably agnostic to that effect: anyone
| can use the software, corporation or not. But given that large
| corporations already have significant economies of scale, the
| emergent effect is that a corporation can extract more value out
| of a piece of open source software than you or I can. If your
| goal is to discourage a handful of oligarchs eating the world, a
| permissive license may be opposed to that.
|
| It's sort of like breeding fish and dropping them in a lake.
| Sure, anyone can then grab their rod and reel and catch a few, so
| you aren't privileging the commercial fisheries industry by doing
| so. But once the trawler shows up, they're going to harvest a
| hell of a lot more fish than the dude with a bamboo rod.
|
| You may be thinking this analogy doesn't work because software
| isn't like fish. Copying a piece of software doesn't _remove_ a
| fish from the lake for others to catch. But think about this at
| one level of abstraction higher.
|
| Copying software accomplishes nothing. It's just bits sitting on
| a disk. It's software being _used by humans_ that matters. When a
| corporation takes a piece of open source software and puts it in
| front of users, time a user spends using that corporation 's code
| is time _not spent doing anything else._
|
| While software itself isn't a consumptive good, _human attention
| is_.
|
| Notice how all of the biggest, fastest growing corporations
| understand this. Attention is the ultimate economic commodity.
| Any company who can mine it effectively wins and any company that
| fails loses. This is why in the past decade we've seen seemingly
| weird business moves like Apple producing movies, NVIDIA doing
| game streaming, Amazon shipping games, Walmart selling video
| streaming, etc.
|
| We are shambling towards a post-material world where the most
| valuable good, the thing that _produces_ the most value, is human
| attention. And, unfortunately, a few people figured this out
| sooner than the rest of us and a gobbling up all of that mental
| real estate and leaving nothing for anyone else.
| maxhille wrote:
| BSD & Co are open source for developers
|
| GPL & Co are open source for users
| Expurple wrote:
| The point of the article is that BSD & Co have better survival
| characteristics, eventually attracting more developers,
| producing higher-quality software, and making the users switch
| to that.
|
| In the long run, even from the user's perspective, GPL & Co is
| only for enthusiasts who don't prioritise the actual quality of
| the software that they use.
|
| As a user, I value my freedom, but BSD & Co gives me _enough_
| freedom. The article assumes that it 's the best tradeoff for
| most users, and I agree with that
| singpolyma3 wrote:
| This whole argument hinges on the statement that the GPL "does
| nothing for users" but is "annoying for developers". I dispute
| both of these claims.
|
| GPL is all about doing something for users. It is users who are
| able to request source code. My entire network setup is based on
| the fact that I can customize my router which I can only do
| because users were able to request the source for the router in
| order to customize it.
|
| When it comes to "annoying for developers" we need to be clear.
| The GPL is annoying for developers of software that is _not_ open
| source. It annoys them because it says they must either take the
| open source deal or else rewrite it themselves. Apple has
| famously used a lot of time and money to rewrite GPLd thengs.
| This is the goal.
|
| OTOH open source developers need not be annoyed by any GPL
| dependency since they can always use it without any trouble to
| themselves.
| joe_the_user wrote:
| This,
|
| Moreover, a company can release a GPL'd version of their
| software and also offer a commercial license for their software
| (see Qt etc). So someone who's charging for their software can
| use it if they themselves pay. Some commercial vendors might
| annoyed by even this. But it would seem they "doth protest too
| much".
| aleph_minus_one wrote:
| > The GPL is annoying for developers of software that is not
| open source.
|
| It is also annoying for developers of open-source software that
| is not GPL-licensed.
| singpolyma3 wrote:
| It doesn't need to be, since they can still use it and keep
| their license the same etc.
| Expurple wrote:
| Compared to permissive licences (from the user's POV), GPL is
| merery a guarantee that a proprietary fork won't left you
| behind in the dust overnight. That's a rather strong guarantee
| that most people (including myself) don't need. I'm fine with a
| "plain" guarantee to fork the last free version. In exchange, I
| usually get better, well-supported software with more corporate
| contributions.
|
| > Apple has famously used a lot of time and money to rewrite
| GPLd thengs. This is the goal.
|
| As an aside, that's a terrible goal. Rewriting the same
| projects over and over is a waste of human potential. We could
| be solving unsolved problems and _actually_ making the world
| better, instead of pursuing this weird and misguided notion of
| "fairness"
| singpolyma3 wrote:
| It's not about fairness. It's about making bad actors like
| Apple pay to do their own bad work. If they chose to make
| open source software and actually make the world better we
| wouldn't even be having this discussion.
| Expurple wrote:
| Do you consider open-sourcing the software a necessary
| precondition for making the world better?
|
| In other words, can a company make the world better by
| making proprietary software? In my opinion, that's
| obviously true. (Although I too dislike Apple specifically)
|
| Your approach forces _every_ company to redo the work, even
| the "good" ones. In fact, that probably makes the
| situation worse, because it raises the barrier to entry and
| forces companies to choose agressive and hostile business
| models in order to get that investment back. If a new "More
| Ethical Apple" could be started instantly with no software
| investment, we would have one, the users would be able to
| switch, and would directly benefit from this
| wooptoo wrote:
| This article is already largely irrelevant. The GPL (and the
| FSF), whether you like it or not, always has been a political
| movement. The aim of the movement is to expand the pool of
| free/libre software and to disallow commercial entities from
| gaining an unfair advantage without contributing back. With the
| GPLv2 they already have, as it permits them to run the software
| in the cloud, with their proprietary additions, without
| contributing back. AGPLv3 closes that loophole that's why it's
| even less popular.
|
| You can license your software as you wish, but in the long run
| the GPL has ensured that contributions reach back upstream for
| the common good, rather than for profit. The GPL gives
| protections for the people/end consumers, much like labour laws
| do in your own country. The GPL ensures that your contributions
| are respected, available to all, and not abused for profit (not
| always true, but tribunals have enforced the license terms
| before). The GPL has the effect of doing this globally while
| allowing contributions back from a global audience. It's genius
| and the companies absolutely hate it.
| Expurple wrote:
| The article makes the point that, _in practice_ , permissively-
| licenced projects see _more_ contributions back. Copyleft
| projects are being rewritten as proprietary instead (with a few
| exceptions like Linux, which are too big to fail). The end
| result may be even worse for the user, if the proprietary
| alternative ends up being the most developed one, grows an
| ecosystem and a network effect, and eventually everyone is
| forced to use that. There 's plenty of examples.
|
| It's not about "fairness". It's about reality and survival
| characteristics.
|
| As a user, I care about my freedom too. But permissively-
| licenced projects give me _enough_ freedom to choose them over
| copyleft projects that are even slightly worse in quality
| rpdillon wrote:
| You've been very diligent in replying to the detractors in
| this thread, but I have yet to see any compelling examples.
|
| You say that there are plenty of examples of copyleft
| projects being overtaken by proprietary versions that then
| create network effects that end up being worse for the end
| user because the original project was copyleft. You further
| assert that if the original project had been permissively
| licensed, this wouldn't have happened.
|
| I'm unaware of this ever happening. Can you list a few of the
| examples you had in mind?
| phendrenad2 wrote:
| I think this is largely an illusion. Most open-source software
| isn't that successful, so it might seem like the choice of
| license didn't really matter for their success. But you'll notice
| that all of the big, successful open-source projects are either
| GPL, or can't be GPL because of the GPLs murky legality around
| linking (the article mostly hinges on such a case - LLVM).
|
| The author talks about GPL projects feeding back on themselves to
| create technological dominance. But it's much more than that. GPL
| encourages organizational dominance, too. It starts with watch
| dogs looking out for GPL violations. And it ends with a big
| nonprofit foundation providing training and paying developer's
| salaries. Why did Linux blast past BSD? The popular story is that
| some company was trying to claim ownership over BSD. But the same
| thing happened to Linux a decade or so later with SCO. I think
| the license created a no-win situation for anyone who wanted to
| create their own Unix-based OS. If it wasn't Linux-compatible, it
| wasn't valuable. And nobody could keep up with Linux's rapid pace
| of development. So everyone gave up and started contributing to
| Linux, causing the pace of development to increase even more.
| Now, Linux has what, a million commits per year? Something insane
| like that. Try achieving that with a BSD license.
| mdasen wrote:
| I think that the SCO threat to Linux also came at a time when
| Linux was pretty immune from such a threat. If it's the
| early-90s and there's two options in their infancy and one had
| AT&T (one of the 5 largest companies) threatening it, you'll go
| with the other. In 1993, you're not using BSD or Linux and
| making a choice between them. The legal threat weighs heavy
| there.
|
| When SCO sued IBM, people were already using Linux including
| one of the biggest and most trusted names in computing (at the
| time): IBM. Migrating away from something is a hard choice.
| Likewise, Linux had IBM's army of lawyers defending it (yes,
| BSD was defended by UC Berkeley, but the school could have
| easily folded over a project that wasn't part of the school's
| core mission). SCO also wasn't much of a threat - they were a
| dying company trying to win a case against the biggest names in
| the industry.
|
| It's a lot easier to spread FUD against something no one is
| currently using that has a viable alternative. In 1993, Linux
| and BSD may have been equal, but AT&T's legal threat carried
| weight. People choosing one or the other weren't already using
| one. By 2003, 25% of the internet was powered by Linux. People
| were already using it and weren't going to be scared away by
| the claims of a dying corporation while powerful companies were
| defending Linux.
|
| You say yourself that if something wasn't Linux compatible, it
| wasn't valuable and so everyone had to be chasing and
| reimplementing Linux compatibility. But if BSD had been
| established for a decade and Linux was chasing BSD
| compatibility in 2003 and then SCO sued BSD, BSD would still
| have maintained dominance.
|
| _When_ a company claimed ownership matters. _Which_ company
| claimed ownership matters. "How big" the OS was when the
| challenge came matters.
|
| Frankly, reset Linux adoption to 0. Have everyone use BSD for
| 2-4 years. Then reintroduce Linux. You won't end up with Linux
| dominance. You'll end up with BSD dominance. Linux had a multi-
| year head start. As you note, once you become the dominant
| target, everyone else is chasing you. If BSD had a multi-year
| head start, Linux would have been chasing BSD and the roles
| would be swapped.
| AnimalMuppet wrote:
| SCO was suing on two grounds. First was the claim that they
| were the corporate heirs of the AT&T copyrights, and they
| claimed that Linux infringed on them. Second was from a joint
| development agreement with IBM - they claimed that code from
| that had been contributed to Linux by IBM, and that IBM
| didn't have the right because it was half SCO's code (or
| rather, Novell's code that SCO inherited).
|
| That second claim could not have happened until IBM was
| contributing to Linux. That part of the lawsuit could not
| have happened in 1993. (The first part was similar to the BSD
| lawsuit.)
| Expurple wrote:
| > all of the big, successful open-source projects are either
| GPL, or can't be GPL because of the GPLs murky legality around
| linking (the article mostly hinges on such a case - LLVM).
|
| Another comment trivially points out that this isn't true:
| https://news.ycombinator.com/item?id=44607038
| camgunz wrote:
| This article doesn't reckon with cloud providers (etc) eating
| your project. (2015) indeed.
___________________________________________________________________
(page generated 2025-07-18 23:01 UTC)