Back in the 90s, there was fear about a population bomb. 10 billion people by 2010, mass starvation, etc. We've successfully defused the population bomb since, and now the conversation has flipped. In most developed countries, there's declining birthrates and new concerns over who will support the future economy. The problem now is that these countries do very little to support new families and children. Housing is expensive, childcare costs are crushing, expectations on parents is higher than ever, and there's less community support than ever before. So it's really no wonder why people are choosing to have smaller families or no kids at all.
No; we just have birth control that works. The rest of these are all parts of the puzzle that help people not desire having offspring, but previously there simply wasn't a 99% fool-proof method to do so aside from abstinence or hysterectomy. So; regardless of economic factors, people had kids and dealt with those outcomes.
Is this true for very wealthy people, or only for above average earners?
There are many examples of very wealthy people having lots of children. Children are still a significant investment for high earners, but at a certain wealth level it becomes inconsequential.
Quick google shows some support for this idea:
"There is a new emerging trend where better-off men and women are more likely to have children than less well-off men and women."
ergo, there is probably a level of financial support/wealth at which people start having more children. Or more simply, the point at which the personal benefits outweigh the personal costs.
Mozilla fell into the trap of buying services and focusing all their efforts on integrating them without improving them. Mozilla needs to focus on their browser's UI. Nobody is going to buy into their ecosystem unless the browser is good. Arc Browser is the direction they need to go in. Firefox first got popular because its UI was radically better than anything else out there at the time.
The issue I had was that the book just seemed like a lot of wingeing to me back then.
Later on, and after some therapy, it turns out that I was just going through a lot of abuse at the time and just kinda hid all my feelings. Still do, really. That the characters felt anything was, to old me, just a sign that they weren't working hard enough. 'Like, come on, everyone knows life sucks, right? Just get over Daisy you idiot'. Yeah, no, that's not how people work, it wasn't how I was supposed to work.
I guess that's why it's a classic. You reread it later and see all these tings in you that changed too, but the words just stay the same.
I still maintain that 'Cather in the Rye' is just a rich kid complaining about nothing though. I hated that book and Holden too, seems just overly spoiled to me.
Great comment. I grew up with the "life sucks" and "work harder" mentality. Both of them eat you up inside, and I lost at least a decade to doubling down on them when they didn't work well over time. Sounds like this book will be interesting in more ways than I expected.
> I still maintain that 'Cather in the Rye' is just a rich kid complaining about nothing though
Teenage me loved it. I'm curious what dad me thinks now.
Clearly, the legal team got bad information and made it part of their agreement. Like the article says, not only do tons of Unity assets use LGPL dependencies, but Unity uses LGPL assets themselves. Even shipped games created using Unity use LGPL assets. The intent was probably only to screen out GPL dependencies. For those who don't know, there's a huge difference between the GPL and LGPL. The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
In contrast, the GNU General Public License (GPL) has stricter requirements. If your software incorporates GPL-licensed code, the entire derivative work must also be licensed under the GPL, which includes releasing the source code.
I don't know much about the way unity apps are distributed, but I'd be a little surprised if they are only intended to be distributed in a way that satisfies LGPL.
I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
Legal specifics aside (IANAL after all), my general point is that despite being more flexible than full GPL, LGPL is still pretty restrictive. Proprietary software generally may need to keep things simple or be careful (probably including consulting an attorney with the relevant expertise) to ensure they are compliant.
In that light, I can see why Unity would disallow LGPL software. It's not that it couldn't be done properly, but that it's probably not feasible to do a proper legal review of every asset added to the sure (not for Unity and not for the asset providers).
> require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
I believe the GP is referring to the LGPL requirement that users be able to replace LGPL components with modified versions.
Being able to replace subsystems of a signed application with arbitrary third party code adds complexity and is a security risk, but is a requirement of the LGPL.
I think modernity has complicated things. The proprietary vendor signing all the binary components to prevent tampering is different from the platform package manager and kernel requiring signed packages/pages. If you have the proprietary blob and a bunch of modified third party dynamically loaded components, you (or the platform) can re-generate your own signature over the modified composition to execute it in {context that requires signed code execution for security/integrity}. The LGPL is addressing the former. I don’t see a spirited problem with the latter.
I’m trying to work out if an app was distributed with a service that ran in a separate process, e.g via XPC service on Apple platforms, could LGPL libs be legally statically linked only to the service code, which would be open sourced. The service and main app would not be linked at compile time so LGPL wouldn’t apply to the main app, which could remain closed.
> I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
IIRC, That's a difference between LGPLv2 and LGPLv3 - LGPLv3 has the same anti-tivoization clauses that GPLv3 has - while LGPLv2 does not. So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
VLC is licensed under LGPLv2.1, which is not subject to the tivoization clause.
> So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
Legally that might be true, but that interpretation stands directly opposed to the intention of the license. In that light, it is unambiguously unethical to use that loophole.
Many, many people license under gpl2 only to avoid that tivoization clause. So unless there’s a clear indication on the library’s author wishes wrt tivoization, I don’t think it’s fair to make any ethical assumptions here.
Every thread about software licenses always devolves into a firehose of debate and conflicting beliefs. How, in 2025, are we still in a state where, on HN of all places, nobody has any idea what the specifics of LGPL really means or how it has to be implemented? How is it so convoluted, confusing, and up to interpretation?
There's demonstrably room for innovation here - coming up with some new system that actually makes sense, that people can actually understand. I suppose there's licenses like MIT that fall in that bucket. Everyone is pretty clear about something like the MIT license. But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
> Everyone is pretty clear about something like the MIT license
I don't think this is really true. I think people are often upset or surprised when their MIT-licensed programs are used in ways they don't agree with, or they reuse MIT-licensed programs in ways that violate their license terms (e.g. it takes many companies many, many years to realize they have to actually include a way for users to view copyright notices).
Open source software is built on many different fuzzy notions of community and collaboration, encoded into an imperfect-but-legally-robust set of protocols that try to establish common language for people to build on. These protocols have proven very, very successful in encouraging collaboration and minimizing exploitation, but there's still a regularization/compromise process that's necessary so that everybody has a common ground to work from.
For another perspective, think about them like security software—I personally might not know why TLS uses DH key exchange, or how it works, but if I threw it out in hopes of making thing simpler, things would probably go pretty badly for me when someone else notices.
> But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
What, though? I expect that people with a greater understanding of copyright law and how to write legal documents, have tried and failed. The GPL, LGPL, the Affero variants have specific goals around keeping software open. I don't think writing a license to achieve those goals can be simple or straightforward.
That is legaleze for you, and it not at all surprising that we are still discussing how such a text should be interpreted. Its mostly impossible to create a legal text that has unchanged interpretation for several decades, or centuries for that matter. Just look how courts often discussion the interpretation and enforcement of specific laws, even laws that are older than the judges themselves.
It’s because the genesis of these convoluted license terms is rooted deeply in the archaic copyright law in the US. Until that is fixed, these legal hacks will be necessary.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
Arguably, I do not think that everyone is clear on how MIT works. Huge amounts of software, dare I say most, don't even include a way to view the license, which is a requirement to use MIT.
That Unity itself or Unity-based games use LGPL components doesn't matter. What matters here is what is allowed on the Unity Asset Store. There is nothing requiring Unity to allow everything on their Asset Store that could be linked into a Unity game, and apparently at the time, the Provider agreement simply said: you can't sell LGPL assets on the store.
It isn't surprising or unreasonable that the Store might have additional requirements, and there are plenty of reasons to do so. One is Unity limiting their risks as a distributor of third-party content. Another is that the Unity Asset Store does not require assets sold to be used with Unity, and for some assets it can be allowed depending on the specific asset's license:
On the other hand, not enforcing the LGPL rule evenly against other assets also currently being distributed with LGPL components, on the other hand, is more problematic.
> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met.
It's not that simple. The LGPL says that one must basically be able to make modifications to the opensource library, rebuild the library and be able to reintegrate this new library in the existing application. And you, as a developer using an LGPL library, need to make this "possible". What this practically means, is open to interpretation. This is also why lawyers (and companies) don't like the LGPL, because it contains even more of this "open to interpenetration" text than the GPL.
> What this practically means, is open to interpretation.
Is it? It seems very straightforward to me—just use a DLL. The LGPL even says explicitly that it's fine as long as you use a shared library.
The situation gets trickier for Android or Xbox games I guess. I'm curious how Unity complies with the LGPL provisions there. But for any normal desktop platform this should be trivial to comply with.
EDIT: ah, upthread they mention this is only a provision for the LGPLv3. I would expect that the LGPLv3 is pretty rarely used for this reason.
Afaik not necessarily. You migh make modifications to the LGPL library (such as changing the API) and then use that in your proprietary app.
Although the modified library would still be LGPL, it would be both practically useless to everyone on the street, and unfortunately the (L)GPL doesn't even specify how you must share the source. It's perfectly legal to say 'send us a request and we email you the modified sources'
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
- d) Do one of the following:
-- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
-- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
if your application contains LGPL code then as a user of your application i must be able to make changes to that LGPL code. that means i need either the code of the whole application or at least object files and infrastructure so that i can relink my changed LGPL code to your application.
>at least object files and infrastructure so that i can relink my changed LGPL code to your application.
This part is true but I'd like to emphasize that the infrastructure is on the user to acquire. The distributor of the application is not required to make that infrastructure available.
no, it is. it's explicitly mentioned that the distributor has to provide for instance build instructions.
> The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
> If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
The only thing you don't have to provide is e.g. the platform toolchain, headers, etc. e.g. you don't have to ship Windows.h and cl.exe if you are making a windows app that comes with an LGPL library.
i am not sure about that. isn't it required that i get everything needed to rebuild the application? if it's a standard compiler, sure. but any config files, nonstandard tools to link, say if the non-LGPL part is written in an inhouse language with a non-public compiler and linker, you still need to give me the tools to relink the objects. i mean that's very unlikely to happen, but if it does, those tools need to be shared.
are you sure? how is that supposed to work if i build an application with a compiler that i don't have the source for? even for a pure GPL program that can't be a requirement. LGPL requires object files for the non-LGPL parts to allow relinking, but it requires the source for the tool that does the relinking? that doesn't make much sense to me.
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."
The LGPL refers to the GPL by reference. I don't think the intent is to recursively require the source code of the entire universe. But the definition of "System Libraries" is somewhat vague, and the undefined term "general-purpose tools" is even vaguer. Would, say, MSVC be a "general-purpose tool", even though it arguably isn't a "generally-available free program"? (And which "free" are they using here?) I can see why many legal teams would be wary, at least.
>> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
That requires the library to be dynamically linked. Not sure if that's in play here.
It doesn't strictly require it to be dynamically linked but does place additional requirements on applications which are statically linked to LGPLed libraries.
> If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
this is not an additional requirement, this is another way to apply the core requirement of the LGPL to the static linking case in C, which is: the end-user must be able to patch / replace the LGPL parts of the app.
>If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
And is this easy? I don't know much about how this works, but would it be trivial for unity to distribute a version of unity with statically linked LGPL libraries where you can also easily relink?
It's as easy as building the project in the first place. Anytime you build your application you also build the object files for it as well.
As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.
Of course, those build files won't be stripped, meaning that it would be easier to reverse-engineer them - which might not be something the distributor wants.
As the devil's advocate I'd like to argue that legal is probably more comfortable with Unity's own use of LGPL libraries, because they can ensure that Unity only links dynamically to those libraries. And given how critical these dependencies are to the engine, legal is willing to take the "risk" of allowing LGPL dependencies.
The ban of LGPL in assets on the asset store is probably due to legal being concerned that someone would publish an asset that statically links to an LGPL library and that it would allow anyone to demand the source/object code of any Unity game that uses that asset.
Legal probably sees it as too much effort to vet every asset to see if it links correctly to LGPL libraries and simply instituted a blanket ban to simplify enforcement.
I lost 60 pounds on WeightWatchers back 15 years ago. I signed up again recently but quit after a month after finding better methods and realizing they've lost their way. What made WeightWatchers great back in the day was its no-nonsense approach, great word of mouth, and excellent in-person sessions and resources. You lose weight, and if you achieve your goal you get a lifetime membership.
In the years since, WeightWatchers got caught up with customizable and ever-changing programs that were far too soft and excessively permissive. And they lost sight of why people joined the program. It felt like they wanted to become a lifestyle brand instead of a support group of people focused on achieving a goal.
They also drastically cut down on in-person sessions, and the virtual sessions are a poor replacement. It's a zoom call with a few dozen people and the entire thing feels very phoned in.
And while they were among the first to have a points tracking website (I loved e-tools!), which was excellent in 2009, Weight Watchers never really improved upon the technology and got left behind. Nowadays there's cheaper apps that do the same thing, and more advanced LLM apps where you take pictures of your food or describe it and it figures out the nutrient values.
My advice to post-bankrupcy weight watchers: focus on in-person sessions, and make it more goal and education oriented.
They also rotate their points system making what seem like contradictory choices when the system changes every couple of years. In contrast taking Wegovy simply shut down any desire to snack and drastically reduced the desire for all but the smallest portions. You don't have to think about or apply a system: your body will do it for you.
You still need to establish good habits of eating sensibly and maybe that's the narrow wedge for Weight watchers now, but the blunt instrument is the medicine, not the process. WW needs to go back to teaching people to eat well.
At this point, it's like comparing the iPhone 5s vs the iPhone 6. The upgrades are still noticeable, but it's nowhere the huge jump between GPT 3.5 and GPT 4.
Agentic AI without understanding what it's doing is like owning a warehouse but knowing nothing about manufacturing. Or, managing people but never actually meeting with them. You can use it to generate stuff, but you need to go back and understand in detail what it did and how it works.
reply