Out of curiosity, does that mean that GPUs are indeterministic only in their exact execution run-time behavior, or also in the actual output they produce? If the latter, is it something to do with the indeterministic order of floating point operations causing small output differences, or something completely different?
I think the best argument for that might be that some people don't seem to understand what "consciousness" (in the sense that you are talking about) even means, and how it's different from something that can be explained as an emergent phenomenon of known physics. I then sometimes wonder whether those people are not actually conscious, or whether they just don't get it.
Indeed. Nagel famously clarified that "an organism has conscious mental states if and only if there is something that it is like to be that organism." Many found this enlightening. I find it extremely perplexing that this wasn't immediately obvious to everyone. On the other hand, in Tibetan Buddhism there is something called a "pointing-out instruction," where your enlightened nature is pointed out to you. Afterward, you wonder how you could have ever missed it. Perhaps I should treat Nagel's paper as analogous. Like "oh, duh, the lights are on. Thanks for the reminder."
Maybe, but the vast majority of people act, whether they intend to or not, as if consciousness is a social fact. The discrepancy between social facts (especially if they have a plurality of groundings),l and the existence of a scientific fact is fundamentally an interesting phenomenon.
How is the Cybertruck not focused on utility? It has a larger range, larger bed, more torque + HP, a ramp, you can stand on the bed (vault) cover, it can power electric tools, etc. Sure the Lightning can do some of that too but the Cybertruck seems even more useful to me.
It never stops to amaze me how of all places people in here are so blind to it.
Game should recognize game, especially on HN. The way Musk operates and Tesla finances scream that this is not unlike your run of the mill startup whose survival is 50:50...but of course the founder and CEO is doing media blitz after media blitz to promote the company and get a better valuation for the inevitable equity raise.
So far, none of these exist yet in the real world, so we'll see which one actually gets produced and sold first. I wouldn't be surprised if it's around the same time (sometime next year).
That sounds nice in theory, but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore, since realistically they won't be able to or want to switch to the AGPL as well (because of all the pain that would incur on others, in turn). That means that basically the whole free code sharing idea goes out of the window, at least in one direction – Grafana can of course still integrate code from more permissively licensed projects into their codebase.
That's kind of the point. The purpose of MIT/BSD is to enable nonfree derivative works; the purpose of the AGPL is to only allow free derivatives. AGPL maximizes freedom by prohibiting further restriction of it; it's a local maxima of "user freedom" as a function of "developer freedom".
If you want to use AGPL software in your project, you're free to relicense under AGPL.
I agree with the substance of what you said, but I'm going to nitpick a bit of wording: what you call "developer freedom" isn't freedom at all, and is more rightly called power.
That seems like splitting hairs for ideological gain.
You might as well describe freedom of movement as power to take someone else's job in another town, or freedom of speech as power to manipulate masses, or freedom to do an abortion as power over the unborn child. Which way the issues are framed says more about the author than the issue.
Software has leverage (one developer, many users at low marginal cost) built-in, but that doesn't make developing non-(A)GPL or even proprietory software a projection of developer's power. Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
Laws exist ideally to limit freedoms whose exercise comes with externalities that end up reducing the freedom for others. These range from freedoms to cause harm to others (steal, assault, enslave), to freedoms to sell food without disclosing ingredients, to freedoms to run a business without transparently reporting financial information. The idea of greater freedoms depending on lesser restrictions is not novel.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
Copyleft/FLOSS alone is a necessary but insufficient measure; I wrote about other measures in a blog post [0].
TLDR: open platforms/standards-driven and implementation-neutral development, implementation diversity, and simplicity are also necessary. Once all that is accomplished, you have a platform that prevents abuse of power: anyone can use any implementation they want, and implementations are simple enough for community members to fork and maintain. All of this prevents vendors from exerting power over users.
> At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
From the article I linked:
> The key to making money with FLOSS is to make software a commoditized complement of other, more profitable services. [1]
> Examples of such services include selling support, customization, consulting, training, managed hosting, hardware, and certifications. Plenty of companies use this approach instead of building proprietary software: Red Hat, Collabora, System76, Purism, Canonical, SUSE, Hashicorp, Databricks, and Gradle are some names that come to mind.
> Managed hosting isn't a basket worth all your eggs if giants like AWS can do the same at a lower price. Being the developer can give an edge in areas like customization, support, and training; it doesn't offer as obvious an advantage when it comes to hosting.
In other words, developers should be paid for service rather than copies of software. AGPL makes it hard to sell copies of software, but doesn't stop you from offering any number of services. This makes sense, since labor is a scarce resource while copies of software require artificially-imposed scarcity to directly bring revenue.
If developers only get paid for selling auxiliary services, no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
Most consumer software doesn't in fact need any auxiliary services. It just needs work put in to actually build it, and that work needs to be paid for.
Props to Red Hat for earning money from enterprise clients. That model only works if you have enterprise customers.
Props to System 76 for selling computers. That model only works if you're selling hardware.
My software doesn't need any services or hardware or other auxiliary bullshit, and I'm not going to invent the need for said bullshit just to satisfy some ideologues.
You're not entitled to tell me what kind of software to write or how to license it. Don't like it, write your own FLOSS version, and outcompete me. Don't want to, or can't sustain yourself that way? Then don't tell me that I should, or that I can. Words are cheap.
no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
That incentive structure is universal though. A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services. A hospital doesn't charge you for the laundry/cleaning services, it's included in their service bill. If a farmer's combine harvester breaks down, he can't just up the price of his wheat twenty-fold to pay for a new one.
There is a market for selling shrink-wrapped software, see e.g. Microsoft, Nintendo, Apple. Invariably these products are proprietary, because Free Software uses a different paradigm: under the free software/open source model, software is a tool, not a product.
> A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services
Of course. That's not a problem, because the toolset isn't the builder's product. Their customers don't care about the toolset, they actually want the service. Conversely, most consumer software users don't want or need your services, they just need the software.
Moreover, that toolset you mentioned belongs to that builder only. It's not a resource shared by all the builders in the world, unlike open source software.
It's not surprising that people pontificating about the morality of copyleft vs proprietary don't even seem to understand the basic economic effects of shared ownership like the tragedy of the commons.
> freedom of movement as power to take someone else's job in another town
Freedom of movement is the power to exchange goods and services with anyone.
> freedom of speech as power to manipulate masses
Freedom of speech is only a freedom if it is accompanied by a potential hearer's freedom to block speech. Modern platforms do not let you choose what or who you want to hear. Freedom of speech without freedom to choose your censor is anarchy.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
You are ignoring the freedom to modify/fork, plus the requirement of free documentation.
Quite a quantum leap there from proprietary licenses to "modern platforms".
You're free not to use Facebook, Twitter, et al, you know. There are other, open, platforms. And other closed ones that are decent. Use any of them if you want more control over what you read.
Don't fucking shame people for earning money writing good software. Most of us aren't building evil monopolies.
How does freedom for the user-who-is-not-a-developer to change the source work, then? The FSF fundamentally assumes the user is a developer. Hell, look at the vast majority of the GNU software. I wouldn't say it's at all targeted at not-developer users.
Arguing over which one is “freedom” is a petty exercise in trying to claim the moral high ground. Instead, it’s more objective and accurate to say that GPL and BSD represent two different ideologies, and that the AGPL is definitely designed to promulgate the “GPL” ideology, so that it’s inability to be incorporated into BSD-licensed software is a feature and not a bug from the perspective of the people who choose to license their code as AGPL.
I think you misunderstand the GPL ideology (to use your words).
The idealogy is that proprietary software is wrong, bad, unethical. Software freedom should be available to all.
The copyleft terms of the GPL are a tactic a means to defending software freedom. And to that extent, all the incompatibility with other free licenses are indeed a bug a downside, a hampering of freedom in practice. That downside is accepted because of (and only when it is) the judgment that it is a net gain for software freedom anyway because it frustrates the development of non-free software.
There does not exist any ideology that wants incompatibility between free software licenses. It is a price that some feel should be paid sometimes in order to be incompatible with non-free licenses which are the actual problem.
> If you want to use AGPL software in your project, you're free to relicense under AGPL.
And this condition is the reason that the answer will be "no" every time to using copyleft. Why would anyone ever choose a piece of software which, however you want to twist words, is actually less free in the sense of what it permits and will have less adoption as a result?
I run some websites without ads used by thousands of people and I never intend to monetize them, but I would still avoid these projects solely due to their licensing.
"Are copyleft licenses more or less free than permissive licenses?" is a pathological nothingburger of an argument because there is no substantial point of disagreement, except on priors, which are never discussed.
Take slavery, or indentured servitude. Nobody seriously argues (any more) that laws against these practices decrease freedom, although they technically restrict the freedom of would-be slave owners. Likewise, if "proprietary software is evil" is table stakes, then copyleft licenses are more free, period. There is no argument.
So, actually what we disagree on is "how unethical is proprietary licensing?" Arguing that permissive licenses are more free is really arguing that proprietary software isn't that bad.
Without having that argument, the other one just goes round and round I circles, like it always does.
Without cost or encumbrance, just like I would expect for a physical free book. The book would not be free if I paid nothing for it and now the author has the right to sleep on my couch legally.
An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
Against that are more rights for the users of the final code. GPL is predicated on advocating for users' rights over developers. But that comes at the right of developers to re-use as they want.
Which one is more free is very much a matter of perspective. Claims that GPL is a more free license because it is better for users are therefore subjective, or at least subject to a very specific semantic context.
> An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
Right, but if you buy/get a book, you can't even re-publish or re-use the content in the first place.
I'm not comparing the AGPL and the GPL. I'm only talking here about the insinuation that the AGPL is somewhat like a book author requiring readers to let them crash their couches. It's not.
They can, they just don't want to because they want to ensure other people can produce non-free work.
Remove the desire to produce non-free work and you can perfectly legally put copylefted code into weakly-licensed free code. Weak licenses don't forbid this. Copyleft licenses don't forbid this. There's no need for anyone to change the license or copyright to combine weak licenses with copyleft licenses.
Copyleft licenses forbid proprietary code. And proprietary licenses forbid a lot of other things.
AGPL can be combined with GPL and vice versa. GPL does not require open-sourcing if it stays on your computer or the computer of your company and its employees. This makes AGPL a much weaker copyleft when on a server.
I don't understand the distinction you're drawing. It sounds like you're saying that "cannot be combined with code under a different license" is meaningfully different from "can be combined with code under a different license, so long as you immediately relicense that code so it's not under a different license anymore". What am I missing?
Because you're misreading it. It doesn't say you have to relicense the code. It just says (A)GPL terms have to apply to both parts of the code. That's not relicensing. You don't need anyone's permission for weakly-licensed code to do that. Weakly-licensed code already allows it, that's why it's a weak license.
Weakly-licensed code also allows to be covered by a proprietary license. Nobody needs to relicense weakly-licensed code to lock it up in any way and apply further restrictions to it, whether they be "good" restrictions like the (A)GPL, where you forbid further restrictions, or "bad" restrictions like a EULA, where you forbid people to look at your modifications or to do further modifications.
Without a copyright transfer agreement in place, only the original author may relicense the code. The permissively licensed parts of the code will stay permissively licensed, but nevertheless may be distributed in combination with copyleft or proprietary code.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This only says that the product of such a combination must be licensed as AGPL. The MIT/BSD licenses (with or without the attribution clause) specifically allow being included in larger works under any license, even proprietary, so what are you arguing exactly?
I have an MIT-licensed project called A, currently at version A1. You have an AGPL-licensed project called B. I take some code from B and incorporate it into version A2 of project A. I want to distribute A2 to A's community.
I don't have to relicense A1 to do this, but I do have to distribute A2, and all subsequent versions of A, under the AGPL, effectively "changing the license" of my project.
I realize this usage is informal - licenses cover code, not projects - but jrv's point upthread was that projects do not want to change their working license, which led me to read jordigh's response as somehow asserting that the AGPL was not viral. It's a non sequitur otherwise.
> but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore
Doesn't that depend on how they use it? They're only AGPLing their backends. The tools still follow open protocols, so the client libraries can be permissive. I.e. the rest of their project won't be "infected".
I suggest you read more deeply into the legal interpretations; it is not so clear cut as you put it.
A more permissive license is simply incompatible with this project's ideals - they are willing to sacrifice developer convenience for user freedom and prevent corporate theft and bastardization of the codebase into competing products
What I don't like about changes like this is that it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code without forcing that whole project into the AGPL as well. That doesn't only hinder competitors (which seems to be the legitimate goal), but also hinders interoperability and an open ecosystem evolving where people freely exchange bits and pieces of code to make things work together. I know that some parts of the codebases have been exempted from these changes (see https://twitter.com/TwitchiH/status/1384566382180896769), but those are only some, and they may change over time...
IMO, the ideal end-state from a software freedom perspective is that all software becomes AGPL. This change is a step in that direction, not only with the directly affected products, but for the reasons you mentioned, an additional pressure for more things to switch to it. Do you not like that end goal, or do you just think the side effects of the change outweigh the benefits of getting closer to it?
I think it's both a completely unrealistic end goal (we live in the real world), and I also think that the AGPL puts you into a hole where you can never get out of again if you decided that you now need different constraints. So I really much more prefer permissive licenses.
> if you decided that you now need different constraints
and if you own the copyright, you can always relicense it to suit. How _other_ people chooses to use this software is not under your control, even though you're the copyright holder. This is exactly what it means to have freedom.
If this incremental step led to a better world already, I would maybe agree... but I think it makes the whole ecosystem worse and worse, until some far-away tipping point is reached where almost everything is AGPL and can reuse each other again. And even then I'm not sure I'd be happy with the *GPL, as now you can't back out of it again in case you later discovered that it was the wrong decision, without getting the permission by all copyright holders.
Yeah, which is why typically those companies make external contributors sign a CLA that allows for copyright assignment and relicensing. Which is annoying if you contribute to a company-owned project under a permissive license to help make it big and successful, and then they change the license under you. But yeah, then they could switch it around in both directions if they get all the rights signed away to them.
you realize that if you contribute to a company apache project without a CLA, they can change the license out from under you to _any_ license that they want, right?
The way I've understood it is part of the point of CLA's is to allow license changes, and that without them no license changes are possible to community projects. Because all the contributors own the copyright to the code they contributed, which they licensed under the existing license. To change the license you'd need to contact all the contributors and get permission (so okay, not impossible, just infeasible). The CLA is getting that permission in advance, to let some controlling body change copyright later.
I thought the point of CLA's in general is to stop contributors from revoking their license, or claiming the entire program is a collaborative work and that they have joint copyright over all of it. I don't think either has ever happened in open source, but I believe is possible, at least in the US.
It seems you can always just run the AGPL licensed software and as long as you interact with it through the network or the database you won't have to relicense anything.
What you cannot do is:
1. change the AGPL software itself and provide it to end users in any form without providing updated sources
2. make a combined product and not provide sources for all of it under AGPL.
3. Also there is nothing to prevent you from releasing sources of your software dual licensed under both MIT and AGPL.
No, it is the network interaction that is specifically a software release trigger. "Interact" is a term encompassing a broad scope of behaviour -- any network message that causes an API to be called.
1+2 are plain old GPL. 3 is just a basic consequence of owning all the IP, but it isn't possible to release a patch to an AGPL under MIT.
AGPL has massively enhanced virality, which is the entire point.
> AGPL has massively enhanced virality, which is the entire point.
Yep, but AFAIK (not a lawyer I have just spent some time trying to figure this out) it doesn't affect other software over the Internet:
Some examples based on Friendica:
- Chrome won't become AGPL licensed by being used to access Friendica
- MariaDB won't become AGPL licensed by being accessed by Friendica
- any changes you make to Friendica must obviously be AGPL (if you let anybody use it)
- if you want to write an extension for Friendica it needs to be AGPL (but if you want you can also release it under another license)
- if you want to put your or someone elses open source or proprietary code into Friendica you must plan to release that code too under the AGPL (of course you can still release it under another license simultaneously but it must be available as AGPL in addition.)
The difference is that not in what it infects but how it spreads - kind of.
The practical effect is that all modifications to an AGPL code are likely to be encompassed as soon as you use it on the internet.
Obviously it can't change the license of other products, but other products trigger the virality. For example, Apache calls a module which triggers generating a graph from your custom grafana instance. Your custom code is now AGPL.
The ideal end-state is simply software freedom for everyone, no more proprietary software — and also no more malicious actions in the world, world peace, and universal love and compassion.
I do sincerely share these ideals, but which paths get us how far with which real-world trade-offs, that's more complex.
For ideal policy, I like this direction: abolishing copyright and patent law and replacing them with (A) mandatory source-release for all published works that need source in order to practically study and modify and (B) prohibition on DRM or other measures that technically limit freedoms.
Oh, I don't think either is realistic any time soon (long long run, who knows). I'll readily accept that there's a path that takes us slowly in the direction of everything-is-AGPL, namely making more software AGPL. No comparable path exists to slowly progress toward my ideal policy.
Wasn't the end goal of copyleft that all software becomes GPL 3 a few years ago? When will this stop? Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?
> Wasn't the end goal of copyleft that all software becomes GPL 3 a few years ago?
Giving users access to software without distributing it to them is a recent technical innovation. The AGPL exists to give those users the same rights as more conventional software users. The underlying goal - ensuring that all users have the four freedoms - remains the same.
> Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?
The copyleft trick only works that way. The goal is to ensure that all software users have the four freedoms; ideally they would be enshrined into law somehow, but failing that, a license is the best we can do.
Unless you are using your software as a resume and need more Github stars to land you interviews, this is a fine result if it gets you more money. Companies like money more than they like clout - and it won't help them to have a billion users and then be undermined by "AWS Grafana" and slowly go out of business. I much prefer companies choosing the AGPL over going proprietary, using a franken-license or going out of business because Amazon sucked out all the oxygen.
Edit: it just occurred to me that opting for popularity over money is "paying" yourself with exposure.
Why? If your software is already all available under permissive licenses, what does Grafana's new license require of you that you weren't already doing?
Oh nothing for now, and there's likely not going to be a viable alternative around for a while. But long-term, I don't see Grafana as part of the openly sharing ecosystem anymore, as with them being under the AGPL, but most other relevant OSS projects in the space being under permissive licenses, the whole idea of code sharing now goes out of the window (or rather, becomes one-way). I don't like the long-term implications of this for the ecosystem.
Maybe I want to keep my software under a permissive license? AGPL would also infect my code, no? And what if we're talking about proprietary code that doesn't have much to do with Grafana and only uses it for monitoring?
> What I don't like about changes like this is that it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code
They're not making everything AGPL and seem to be aware of the kind of thing you're talking about. From TFA (emphasis mine):
> Going forward, we will be relicensing our core open source projects (Grafana, Grafana Loki, and Grafana Tempo) from the Apache License 2.0 to the Affero General Public License (AGPL) v3. Plugins, agents, and certain libraries will remain Apache-licensed. You can find information in GitHub about what is being relicensed for Grafana, Loki, and Tempo.
>™it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code without forcing that whole project into the AGPL as well.
While the whole project must be available under the AGPL, nothing prevent individual pieces to be under a more permissive but compatible license.
I use it in React by pointing the setup code at a ref of the CodeMirror div container and then I store the CodeMirror View object in another separate ref of the component so I have access to it from other places. Slightly awkward, but seems to work fine.
