> I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component.
It also aligns with my experience: my company couldn’t find an LZO compression library that wasn’t GPL’d, so the decision was between implementing one in-house or cutting the feature. We ended up restricting use of the feature to in-house use only, but opening up our core source code was never an option.
If there had been a permissive license option available, we would’ve likely donated (as we do to several other dependencies), and would’ve contributed any fixes back (because that’s easier to explain to customers than “here’s our patched version”).
I quite agree here, but to go a step further here:
Lots of people express this fear that BSD-licensing of components will lead to a world where all the big proprietary software just locks everything down. But if you actually work with large software, you end up finding out that it's actually a lot of work to maintain your own fork, and so you start pushing to get more things upstreamed. Because, after all, if your code is private, it's your task to fix it if somebody breaks it, but if it's upstreamed, it's their task to do it.
An interesting datapoint is LLVM/Clang, where, yes, lots of companies have their own proprietary forks of Clang. But for the most part, those companies still upstream gobs of stuff: most of the biggest contributors to the project are the people with the proprietary forks. Furthermore, as I understand it, basically everybody relying on EDG has, or is in the process of, worked to move off of it into Clang. Which, if EDG dies, means that the permissively-license Clang has done more to kill off proprietary compilers than copyleft-licensed GCC has.
The best defense against proprietary software is to make it too expensive for proprietary software to compete, and using a permissive license means you can trick the companies making proprietary software into helping you do that.
It's also an example of the GPL not preventing corporations from building (and releasing under a more permissive license) non-GPL software.
Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend. Sure, they published the source of their GCC modifications under the GPL, but that was nothing compared to the entirely novel backend, which was released under a far more permissive license.
Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
> Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend.
But they didn't! Dragonegg is a GCC plugin, which didn't exist when work started on Clang--GCC plugins date to GCC 4.5, released in 2010, which is the same year that Clang became self-hosting.
The timeline is rather like this: LLVM originally relied on a hacked-up version of gcc 4.2 called llvm-gcc to create LLVM IR from source code. When GCC added support for plugins, there was the attempt to move that frontend to a more reliable framework, and that was Dragonegg. As far as I'm aware, Apple never contributed to the Dragonegg project itself. Dragonegg didn't last that long; by 2014, the project was completely dead. And for most of its life, the biggest interest in Dragonegg was to have some modicum of support for Fortran.
> Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
By the time of that message, RMS's worst nightmare had come true with Dragonegg... only for Dragonegg to have already died due to a lack of demand for it.
You're right, I got Dragonegg mixed up with llvm-gcc. But my point stands – the GPL was completely ineffective at preventing someone from using it to bootstrap a new compiler infrastructure under a more permissive license.
So, the company wants us to trust them - trust that they will not take advantage off the BSDL to do things the GPL would prohibit them from doing. And we're supposed to trust them because doing so means that there would be more "hands on deck" (e.g. working on the now-canonical LZO compression library that everyone uses because it is BSDL).
Sorry, trust has been broken too often in these scenarios, and the benefits of lots more people working on the same library are not entirely clear.
I understand that many companies don't want to be a part of the pool of software licensed under the GPL - that is their right. But don't try to spin this "if only BSDL was the common one, there'd be a much bigger utilization of a different pool of software". That might even be true, but it would come with the caveat that tivoization would always be an option, which for some of us is something more significant.
It's not about trust, it's about the fact that 10% of something, or even the chance of 10% of something, is better than guaranteed 100% of nothing. You're not being taken advantage of if someone uses a BSD license the way it's supposed to be used.
If I put two choices in front of someone, the binary option of copyleft vs proprietary and they'll always go proprietary, or I give them something permissive and there's at least the chance they contribute back, the second option is strictly better. It's sort of the equivalent of having a wealth tax that raises no revenue, I'd rather have you here contribute something than move abroad and get nothing, even if the benefit is more indirect
It's not 100% of nothing. If the choice is proprietary because they legally can't freeload off FOSS due to it being GPL, the company in question still needs to pay a developer to write the alternative. That's still a positive, and nothing lost. Permissive licenses just grant to freedom to freeload, nothing more.
I don’t think it would’ve in our case, at least. I actually quite like our OSS policy: basically, we don’t want to be in the business of maintaining forks, so all changes should try to get upstreamed if at all possible. It‘s good client service as well: when our clients ask about the libraries we use, we’d much rather be able to tell them “the latest public version” than “here’s our fork”.
We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.
If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you. Use it in your proprietary code if you want, no changes no foul. If you make changes you just need to upstream or make the source available.
> If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you.
Read LGPL a little more carefully. LGPL requires you to use it in a particular manner that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library. Even if you make no changes to the library!
> that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library
I had thought that the dynamic linking requirement was the only option according to the licence, but apparently not. According to 6.a. of v2 and 4.d.0. of v3 of the LGPL, it would be enough to give the user access to the source/object code of the main application and the compilation scripts under non-open-source terms, so that they can recompile and statically link it against their own version of the library.
> the GPL has led to fairly noticeable increase in the amount of proprietary software in the world
What he did:
> opening up our core source code was never an option.
It's companies that decide that open sourcing their software is 'never an option'–even the LZO compression part of it–that lead to a 'noticeable increase in the amount of proprietary software in the world'. They are just using the GPL bogeyman as a thin excuse for their own decisions.
His insinuation that if you just MIT your code so that big tech companies can use it, and if they end up needing help with it they might even hire you, seems super sleazy and borderline exploitive especially in the current job market.
Yes there exists now more proprietary software but you wanted to create proprietary software with it anyway so this kind of is what parent was talking about that some people don't want.
Partly related. Would you have paid if the project had offered a paid non GPL licence?
We (engineers) actually wanted to for another GPL’d project! But because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.
We probably would’ve for LZO too; not sure why that fell through.
> because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.
How would the legal argument be any different for MIT/etc. licensed software in that case? Would the lawyers sign off on using MIT-licensed software without a CLA? Wouldn't they make the argument that the provenance of the software and therefore its licensing is not solid? Seems like the only thing that matters is who has the right to offer a license to the software, not what the license is.
They just wanted the CLA to support the (paid) relicensing.
I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.
The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.
I've seen this personally. Google does not allow GPL code to imported into the massive monorepo. If I needed a library and the only good OSS option was GPL, I'd write it from scratch instead. I'd also usually not open source those things if this wasn't part of an already open source project, because it wasn't worth the effort.
I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible.
You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.
That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.
That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same.
If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off.
If you ship a .a then the final link can always make symbols public again.
There's also a sort-of informal "standard library" of C libraries that have super-stable ABI's that we can generally assume are either present on the system or easy to install. Zlib is another one that comes immediately to mind, but there are others as well.
It doesn’t help that they made an absolute ton of them: something like 140,000! That means that they’re not particularly rare, and it holds the price down.
Add in the fact that authenticity is part of the appeal, plus the fairly expensive process to make a decent replica, it’s not shocking that no replicas have emerged, even though cheap-ish CNCs mean it’s probably easier to do than it ever has been.
Ugh what a waste of her talent. I don't know this guy but his YouTube channel is so clickbaity. Every video title has some exaggerated screamy headline. I would never bother even looking at one.
I suspect the Youtube algorithm means you have to use clickbait thumbnails. Nevertheless the quality of his analysis is usually excellent (and so is Kyla Dempsey's).
And yet the quality of that channel is absolutely excellent, and the polar opposite of what the thumbnail clickbait suggests. I'd say it's on the same level of the Admiral Cloudberg blog actually.
And to be clear I completely agree with your reaction to the clickbait. If I didn't already know the channel I would probably avoid the videos too. And I've seen this happen with other channels. It seems to be an unfortunate effect of the current youtube "meta".
Yep. Watched a few videos, was overall impressed. Subscribed. A week later blocked the channel because the value of the videos was less than the annoyance of seeing the thumbnails and titles in my feed. No great loss.
Hm ok, I've never seen it. It has appeared for me before but the clickbaity titles and images put me off. Perhaps it works to game the youtube system but it certainly doesn't to get my interest.
But I don't have much patience for videos anyway. I prefer long reads.
Ah to be honest I really hate watching videos anyway. I prefer the long reads she does. I just don't have the patience for video.
I sometimes use youtube for things where you really need video, like for a review where you have to see the product. But even for things like repair instructions I don't like videos. I much prefer the iFixit writeups.
"Thanks for your patience in waiting for this article! After publishing my piece on EgyptAir 804 in December, I moved half way across the country in a long, messy relocation process fraught with other struggles along the way. But here I am, and here it is. Thank you!"
Ah thanks I didn't see that. Also didn't know she had a podcast as well (I don't listen to podcasts anyway so it wasn't on my radar). I did notice the articles getting longer and better though. Makes sense!
I didn't realise this was her job, I thought it was more of a side thing.
The podcast is super fun! It takes the “Engineering Podcast with Slides” model that WTYP originated, but instead of having one knowledgeable person and two comedians, all 3 know different parts of the industry.
Often used by people who are American (from the Americas) but not from the US. Canada, Mexico, Brazil, Columbia, and the rest of North and South America.
Let's change the name of America to the United States of America and move it from the front of drop down lists to the end.
Many years ago an Australian show famous for comedic Vox Pop street interviews had a hilarious run on "Asking Americans to name a country that started with the letter U".
I mean, sure, but you've also got "United Mexican States" for Mexico and "Republic of China" for Taiwan or even "The United Kingdom of Great Britain and Northern Ireland" for the UK.
Nobody in their right mind calls any of them by their full names. The rules are more-or-less consistent, it's just pedantry to complain about "America."
It's accepted by all on planet Dirt that they live on planet dirt.
Elsewhere, others living on orbiting aggregates with surface soil like to occassionally disambiguate.
Naturally this seems insane to the exceptionalist denizens of Dirt.
Mexico alone is clear, a Mexican is a citizen of the UMS. The UK is equally clear.
Outside of the United States, particlularly with other American, North, South, or Central ESL speakers, it's not so clear.
This is why the practice arose many years past, why the BBC once had clear style guides on not using "American(s)" in any articles until after the full name United States of America had been used to establish context for which Americans wre intended.
> it's just pedantry to complain about "America."
Being clear isn't a complaint. It's taken as such by the small minded with a horizon limited by a halo about their head.
I'm not complaining about clarifying. I'm complaining that the meaning of the word is obvious from context in almost every case and this is a really annoying form of pettiness which is hardly being applied evenly.
I don't think I have EVER seen "American" used to refer to "North and South America" outside of geography. That goes for when I'm outside the US, too. It's certainly not what reasonable people would assume you're talking about.
This discussion is really unproductive, so I guess we'll just have to disagree.
> I don't think I have EVER seen "American" used to refer to "North and South America" outside of geography.
I'll refrain from reproducing the OED 2nd Edition entry for American unless you really want it, there are three uses as a adjective, five as a noun, the Adjective Use 2, variation c is "United States specific", ( 1.a is "Belonging to the continent of America. Also, of or pertaining to its inhabitants." )
So, you know, a few hundred years of printed use, with citations, says that others have seen it used more widely than yourself.
To be fair, that's all an aside to me .. what has caught my eye in the past few months is a few commenters on HN getting quite upset at "USAian, USofAian, etc" variations appearing here. Clearly this is new to some, others have seen such contractions about forums for four decades.
It follows from pre 2000 (ish) BBC and other style guides that eschew using "Americans" to refer to US citizens until after the context has been established, leading to older BBC articles and broadcasts opening stories with "In the United States today .... Americans reported ...".
From that, in (say) forums discussing i18n and|or l10n (the usual contractions for Internationalization and Localization) with Koreans, South Americans, various Commonwealth types etc. USian became a short fast way to specify which group of North Americans reference might be made to.
This seems straightforward, reasonable, non evangelical, and something a majority immediately "got" w/out batting an eye .. certainly causing less fuss than using "i18n" and other contractions.
I have to agree with you that the meaning of "Usian" is obvious from context in almost every case and it is a really annoying form of pettiness that makes a song and dance about it in protest every time it appears.
Calling the USA just America is like if Taiwan called itself just China. Yes it's common within the USA, but for the rest of the people who live in America, it seems strange.
"American" has been used by English speakers to refer to residents of the US for 3 centuries.
To change it now (why? to avoid hurting the feelings of people, most of whom do not even speak or read English?) would be harmful. "Harmful" is a strong word, so I will explain.
I don't hate Russia, but if I did, I would like it if the Russian people somehow stopped being able to continue to use the main word they've been using to refer to themselves for centuries. It would make it slightly harder for Russians to have conversations about themselves as a social and political entity and to understand old books about their ancestors.
Web sites influence human behavior by making some operations slightly more difficult than others. E.g., the "Accept all cookies" button is a prominent color whereas the "Reject all cookies" link is less so. The point is that a "trivial inconvenience" that is encountered often (i.e., whenever anyone tries to start a conversation about Americans) might have a significant effect over future decades in making Americans feels less united with their countrymen and discouraging discussion of American identity (because for example "USian" is more awkward to use in a spoken conversation than "American" is).
> "American" has been used by English speakers to refer to residents of the US for 3 centuries.
Sure, US citizens are, after all, a subset of North Americans and are Americans just as are South and Central Americans.
English speakers in the United Kingdom and elsewhere have indeed written many texts and articles in which they discuss the United States of America, events in the USofA, and then move to talk about Americans .. having established the context of which Americans they refer to.
This was explicit in BBC guidelines and UK newspapers of note until perhaps the 1990s.
> I don't hate Russia, but if I did, I would like it if the Russian people somehow felt unable to continue to use the main word they've been using to refer to themselves for centuries.
It's not clear how this comes into play here. If Russian speaking ethnically Russian non citizens of modern Russia refer to themselves as Russian after their family ties to the former Russian Empire then surely anyone in the Americas can equally be referred to as an American.
> "USian" is more awkward to use in a spoken conversation than "American" is).
I've not heard it used in spoken conversation. In text forums where I've seen it used since the 1980s it's shorthand to contract first saying "United States of America" and then referencing US citizens as Americans.
Doing a bit of digging online, while there is evidence that /some/ people use it, it appears to be very limited. I understand the desire some people have for an unambiguous English term to refer to things from the US separately from those of the Americas in general, and see the value in doing so. Personally, as a native English speaker, I find USAnian to be clunky - maybe someone has thought (or will think) of a term that feels more natural. It feels analogous to the push from (largely English-speaking) activists in the US to use the term "latinx", much of the intended audience doesn't run into issues with the current terminology and aren't looking for a new term, and the term doesn't feel natural to existing speakers.
You can say what you want, whether or not people will understand what you mean or interpret it the way you intended is the more relevant question, in my opinion.
In English, American means from the US, and there's no word to refer to an inhabitants of the Americas (both continents combined). You can say North American or South American if you want, though. Since those are continents.
You won't find "USAnian" in any authoritative published dictionary, not even the OED:
And anyway, official dictionaries are largely historical records, not authoritative sources for living languages. Words mean what people who use them intend them to mean.
By your definition of dictionary. Again, words mean what people who use them intend them to mean. Urban Dictionary and Wiktionary are both dictionaries as far as I'm concerned.
The digressions started with the first mention of the term in question by SSLy, not just the descriptor you mentioned. That user was probably pointlessly baiting, knowing that the nonstandard term would set someone off, which has led to the digressions that followed.
I've been using that term on and off. This was the first time someone came forward saying it's incorrect. I don't disagree with your assessment of my intentions, but it wasn't that usage, it was the politics part.
Exchange trading happens in round lots that are usually 100 shares.
This is pretty much just a legacy thing, but so many technical systems have this assumption built in that while odd-lot trading (trades not in the round lot size) has become a little more common on the exchanges, it’s still treated weirdly by the various systems involved.
But also, it’s better for you as a retail investor, to get them from a middleman, because they will generally give you a better price than the exchange. They will give you a better price because retail traders tend on average to be worse at trading than the overall market. You should take advantage of that, regardless of your actual ability level.
Odd lots don't contribute to the NBBO, and placing an order for an odd lot doesn't have to execute within the NBBO. (People can trade "past" you, I am pretty sure ISO's don't need to clear you, etc). (Note these are rules for market participants, not retail customers). So for a firm trying to argue they provide excellent price improvement and execution efficiency for their customers, they can't "just" send the orders to the lits.
And even if they could "just" do so, internal matching typically provides better price improvement on the NBBO than even the best execution you could get off the lits.
Edit: But yes TBC, you're correct that odd lot trades aren't unusual. But you're seeing trades there by actual market participants, not retail orders. They're not just trying to get those 2 shares, there's a broader strategy and they're aware of all the above nitty gritty.
In example 3, the NBBO for stock ABC is 495--500, but there is also an odd lot offer for 497 on exchange. If a Robinhood customer sends a market buy order, then Citadel is allowed to fill it for 499.999 even though it's better to send to the exchange. (And if they then pick up the odd lot themselves, it's easy arbitrage.)
By the way, while you're correct about some of your claims, odd lot executions definitely have to occur within the NBBO. (How could it be otherwise?) Otherwise, in the example above, Citadel would give an even worse price!
I mostly mean scenarios where your limit order might not be marketable, end up resting on the book, and then get traded "through". I'm speaking from the perspective of an actual direct market participant, where you're not using a market order but are trying to enter a position while adding liquidity/collecting a rebate. (Most exchanges reward participants who have some % of their trades as liquidity-added, with rebate tiers).
Round lots are excluded from the NBBO so that the NBBO can't be as easily influenced by quantities of shares that don't represent any material price signal. 1 share of practically anything but BRK class A represents ~nothing. Less than a round lot on a price level is basically no liquidity available at that level.
There are per ticker rules to allow odd lots on most US markets. AFAIK unless you're trading penny stocks, every stock out there is entitled for odd lots, and most trades are indeed odd lots, that has been the case for 10 years at least.
Even if there wasn't, I guess at least half the trading on stocks is through CFDs and not cash, so lots aren't even a thing for most investors.
The only reason to sell any of your company is to raise money. If you can raise all the money you need from your employees, then you can be employee-owned.
Kaitai is very useful for reverse engineering a binary file that you have some assumptions of. I've used it for save file reverse engineering and then creating a read/write library for it. It should be usable for PDF Metadata.
See also this review/critique from the cURL author, especially if you’re going to implement it yourself. Particularly around certificate handling and URL parsing, there’s a lot of underacknowleded complexity in Gemini.
That's a really well written post. Thank you for sharing it, really makes you think about all the thought that has went into http and how important Chesterton's fence is
Yeah but also all of the legacy baggage that it comes with, y’know?
Like the URL parsing stuff for example. The issue is that they pull in one of these enormous old RFC’s and also say “but UTF-8” without any more explanation.
A better URL might be a good thing — scope it down to what’s in common use, design it tightly for your needs, etc. But if you’re gonna do that, do it! Rather than just pulling in an RFC with decades of baggage and then modifying it ad-hoc.
I actually really like the way git does it, where it reads each of these in order, last one wins.
- Default configuration compiled in
- Global configuration
- Per-user configuration
- Per-project configuration
You can opt-in to however much configuration complexity you need. Just cloning the occasional thing? Don't bother configuring, the global defaults are probably good enough. Simple commits and pushes? Make a user-level dotfile in your $XDG_CONFIG_HOME to set some basic info. Complex per-project aliases? If you want that, go ahead and opt in.
Contrast that with programs that just dump their whole default config into my home dir on first run. Just filling up with nonsense, often no way to tell what I changed or didn’t.
That is good one, I agree. I have seen some odd cases, where the configuration options were hided too well when they were compiled to the binary itself. But that is probably an another issue.
In particular:
> I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component.
It also aligns with my experience: my company couldn’t find an LZO compression library that wasn’t GPL’d, so the decision was between implementing one in-house or cutting the feature. We ended up restricting use of the feature to in-house use only, but opening up our core source code was never an option.
If there had been a permissive license option available, we would’ve likely donated (as we do to several other dependencies), and would’ve contributed any fixes back (because that’s easier to explain to customers than “here’s our patched version”).