undefined | Better HN

0 pointstimschmidt1y ago0 comments

Nothing in permissive licenses prevents you from adding a useful feature and licensing the result under the GPL. If your fork is better for users, it'll catch on.

I really appreciate the permissive licensing in the Rust ecosystem as it greatly eases the task of writing code for pay. While the finished product may have a commercial license, I often find bits to improve in the permissively licensed parts and contribute them back upstream. Customers seem perfectly fine with this arrangement. Tough to do the same with the GPL - even LGPL'd libraries complicate contract terms and distribution a little by comparison.

With the huge productivity increase LLMs provide for writing code, it seems to me that we're rapidly entering an era in which libraries and tools for everything are available in every language, and under every license, which seems like a good thing. It is nice not to feel limited by one's language choice or work environment.

I did a fair amount of work on the RepRap project, which is mostly GPL'd, and that worked out OK, but there have definitely been opportunities lost over the last 15 years or so due to license constraints which more permissive licenses would have allowed. Finding a balance which helps developers put food on the table while writing open source code also seems like a good thing.

The GPL is great. I think there are important projects which really benefit from the strong incentive it provides to share. But there's definitely room for more than one way to do things.

Ultimately, Everything Is A Remix (https://www.youtube.com/watch?v=X9RYuvPCQUA)

0 comments

lelanthran1y ago

The thing is, I don't really want to do a clause-by-clause, point/counterpoint "Chapter And Verse Citations" argument.[1]

It's why I focus on the goals - they're clear and well-understood.

And, to be clear, I was mostly on the fence about this (my open-source projects tend to be a mix of BSD/MIT and GPL) since around 1995. For my FLOSS experiments/projects, I'd pick a license based on the goal of the project: Popularity? Maybe BSD. Community? Definitely GPL.

I changed my mind recently (started about a year ago, completely changed about 2 months ago). It's become clear that corporations (not all, just enough) are simply scavenging of the effort of others.

Looking back over history, the BSDs were mined extensively by corporations, who then never gave back.

Compare with Linux, which was adopted extensively by corporations, and forced to give back.

The latter had more valuable progress, faster. The world got better stuff, not (for example) some Apple shareholders.

If the BSD-type licenses really did further progress in the field, we would have seen it by now. What we do see is massive progress, almost all based on Linux, funded by corporations themselves. We see new research and novel ideas coming to Linux first.

My outlook now is: Make your project GPL and keep it that way via copyright assignment using a CLA.

The argument along the lines of "Corporations are hesitant to use GPL stuff" doesn't make sense to me. If some corporate wants to close off their changes to your GPL project, then fine - they can pay you for a license to do that!

The counter-argument that "it's an additional barrier to track every little thing that you use from Open Source" is an argument I reject: that's the cost of doing business. Businesses can complain all they want that the charity they are getting is too costly to manage, but the fact is that it's still less costly than going without.

FWIW, I operate as a business. My code is now either closed source or GPL: no in-between.

[1] Such arguments devolve eventually into a wall of text that few read, and of the few that read, even fewer are convinced.

timschmidtOP1y ago

> Compare with Linux, which was adopted extensively by corporations, and forced to give back.

I don't think Linux's success has as much to do with license as it has to do with Linus Torvalds. Very few developers can work on one project for 30 years straight making respectable engineering decisions for the entire run. And even fewer delegate well. Both of which Linus seems to have managed. If anything, corporations seem to use Linux despite the GPL, because it has collected the best hardware support of any of the Free / Libre OS options.

> We see new research and novel ideas coming to Linux first.

Linux still has no great GPL'd answer to ZFS. Linux adopted the Berkley Packet Filter, which has become infrastructure for an ever increasing number of subsystems in the kernel. Linux's tracing infrastructure is finally about feature parity with Dtrace, though it's still not quite as easy to use. The list goes on. Certainly many great things have been pioneered in Linux as GPL'd code as well, which is great. Your view just seems to be a little biased.

I don't have any problem with your choices about how you license your code. Everyone gets to do what they want. I can only say that the folks I've worked with don't bat an eye at MIT or BSD or Apache licensed dependencies, but know to ask about the GPL and avoid. That's about the extent of it. In my experience they do not even consider licensing under different terms - probably because it's only possible with carefully curated code in which there's only ever been one contributor, or every contributor has signed a CLA allowing the lead developer to relicense.

> Looking back over history

I think one has to be careful about grand narratives. They often leave out crucial details while painting a version of things as we want them to have happened, as opposed to the messy haphazard way things tend to happen. Hindsight is 20:20, but rose colored glasses can still throw it off.

globular-toast1y ago

Linus himself has said licensing Linux under the GPL was one of the best things he did. He's great, but to achieve what Linux is today he'd need to have made himself a couple orders of magnitude bigger. Linus also acknowledges the "genius is one percent inspiration, 99 percent perspiration" thing. And this coming from someone not renowned for being particularly humble.

The folks you've worked with are looking for something they can take without giving back. It's as simple as that really. Either that or they just don't like the GPL for entirely irrational reasons, which is all too common.

GPL is like "you can do whatever you like, except preventing others from doing what they like". Permissive zealots are like "boo! That's restrictive! I should be allowed to do anything I like!" Beats me why any thinking person would want a world like that.

timschmidtOP1y ago

> The folks you've worked with are looking for something they can take without giving back.

I think if you're going to make an accusation like that, the only morally sound way to do it is to that person's face. Since you haven't done that, I'll disregard what you've said. As should others.

> GPL is like

You've mistaken me for someone arguing against the GPL. I love all the GPL'd software I use daily. Especially the ones I wrote.

These days I enjoy working with Rust in part because of the language and community, and in part because I get to choose the terms I license the resulting code under. The folks who write me paychecks appreciate it too.

I wish you luck in your advocacy efforts.

lelanthran1y ago

> If anything, corporations seem to use Linux despite the GPL, because it has collected the best hardware support of any of the Free / Libre OS options.

Well, yes, that's my point: It didn't get the best hardware support by allowing vendors to close of every single driver.[1]

It's collected the best hardware support because those hardware manufacturers who write drivers contributed those drivers back to mainline, hence the reason for Linux's dominance over the competing FLOSS OSes.

Compare to the BSDs, who collected NO hardware support from Apple.

> I can only say that the folks I've worked with don't bat an eye at MIT or BSD or Apache licensed dependencies, but know to ask about the GPL and avoid.

Maybe they ask, and maybe they avoid. My experience with those (very rare) clients who avoid is that they want to take a 99.99% complete solution, add their 0.01% contribution, and lock the resulting product up.

> I think one has to be careful about grand narratives. They often leave out crucial details while painting a version of things as we want them to have happened, as opposed to the messy haphazard way things tend to happen. Hindsight is 20:20, but rose colored glasses can still throw it off.

I agree, but note that I did not come to this opinion quickly nor rashly. It was carefully considered, while taking into account the behaviour of corporations and communities over the history of my involvement as a professional developer (i.e. mid-90s).

IOW, this is not an opinion that I have held for 30 years, it's an opinion that I have formed after watching the industry for 29 years. It'd be quite hard to claim that my opinion is an uninformed or rose-tinted one.

[1] Nvidia shows that, with enough effort, vendors could have closed off the drivers anyway. But there's less friction in simply throwing the driver to the community and letting it get maintained, as opposed to writing shims and binary blobs which the vendor still has to maintain.

timschmidtOP1y ago

My experience is that vendors have written very few of the drivers in the Linux kernel, and that most vendor drivers remain proprietary. Nvidia's being the most visible, Intel Poulsbo's being another despised example, most of Android's drivers are also closed and hiding behind an extensive shim framework, Dell even wrote DKIM to help deal with all of the proprietary vendor drivers for the subset of machines on which they offer Linux.

Linux's wealth of open source drivers seem to come almost exclusively from it's community, instead. Which, but for a Finnish university student, could have just as easily coalesced around FreeBSD.

j / k navigate · click thread line to collapse