> But, what do you think happens when you write (input) data to memory and then read (output) it from memory? I'll help you: it starts with "I" and ends with "O"!
That's.. that's not what people mean when they talk about I/O in this context. But I think you know that, you're just grasping at straws to win an argument.
And the bad boys and girls can still hack CRA and if they defraud you using the data they stole is CRA still liable in spite of your paper-based filing?
You will have to prove a lot of "facts" to win that lawsuit. Especially since your social number(s), email, phone, whatsapp, etc are all public info already.
Recall a few years ago an uneducated hacker ("script kiddie") got part way into a CRA website and they took the whole website down for a week. (The attacker was caught, and prosecuted iirc.)
Generally the CRA will only email a notice that there is a new message waiting for you on their site; you have to log in to their site to access the message. As far as security practices go, I won't complain about that.
Yeah, thats why I had email in quotes. Could have been more clear I guess. Still a problem that you need to accept their TOS to see if they decided you owe money.
No, you don't have to have any electronic account with the CRA, you can file by paper, and they write you back by paper, and you can pay by cheque, or get your refund by cheque.
Asyncio is for cooperative multitasking. I/O is the most common use case but it's not the only one. They're using the event loop to schedule their GUI tasks.
Textual is a framework for building desktop apps.
I assume the message queues are in-memory structures used to pass messages between tasks, hence no I/O.
This is really fairly standard stuff.
I understand you may not be familiar with GUI software and/or the Python ecosystem but jumping straight to condescension when you don't understand something is not really a good attitude.
Clicking five semi-random links on the first page of pubmed is not a comprehensive review of the literature.
If you search homeopathy on Cochrane, who are somewhat the gold standard for reviews of medical evidence, 6 out of 6 that I checked concluded there's not enough evidence to say it works (there are more but I got bored and didn't check them all).
> People can dismiss the science, but that doesn't seem very rational to me.
On the contrary, homeopathy is like a low-level skill check for rationality. If you can be convinced homeopathy is real by a questionable grab-bag of studies, you can be convinced of anything.
There are also studies and meta-analyses showing parapsychic phenomena are real.
It's not that difficult to produce positive studies if you're motivated enough.
It's not just a case of "mechanism of action is unknown", it's that given the nature of homeopathic remedies, any possible (non-placebo) mechanism of action for it goes against our current understanding of physics and chemistry.
And any suggested mechanism for how water with not a single molecule of active ingredient is effective would additionally have to explain why it only works if it's packaged and sold at your local drugstore. Tap water should be high-strength homeopathic medicine for everything. After all I'm sure people have dumped homeopathic ingredients down the sink at some point. Water is cycled so most water should have most homeopathic properties already by now.
The justification usually given for AGPL is to prevent other companies from running paid SaaS without sharing their modifications. The actual terms is that any user who interacts with the software over the network must be able to download the sources. It doesn't say anything about whether the service is paid or free.
I think the argument of FOSS people who don't like it would be something like, as a user, just running the software on my machine can potentially create a legal obligation to set up source distribution, if, like, I forgot to block a port.
> just running the software on my machine can potentially create a legal obligation
Not true: only if you made local modifications.
> I forgot to block a port
Also not true. You have plenty of time to close that port.
"""your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice."""
If you expose services on the Internet by mistake you are going to have 1000x bigger problems than the risk of being sued successfully for a honest mistake.
Ah, I was unaware that it applied regardless of it being a paid service or not. I imagine that would be somewhat analogous to distributing binaries of modified GPL software for free without providing the sources.
In any case, does the AGPL requirement to provide sources apply even if you are running an unmodified version? In other words, would merely pointing to the original repository not be enough?
Regarding the risk of accidental legal obligations, I suppose it depends on the details and technical wording of the licence.
If the requirement broadly covers any use of the software on the machine (e.g. some backend service that happens to help your public webserver to stay online) I can see the discomfort, especially if one must explicitly provide or link to unmodified sources too.
On the other hand though, if the requirement is limited to actual provision of the software's functionality to 3rd parties, I would argue that if someone accidentally provides it due to forgetting to block a port then they have much bigger problems than the AGPL.
if you get notified of a security breach caused by your own incopetence, you secure it. which would effectively be the highest harm apgl can inflict on you already: stop hosting the service. which was your point all along.
i think pointing to an upstream repo is probably enough in most cases provided you can link to the right version. but what do you do if the upstream repo disappears?
for a popular program that's not very likely, but lost source code is the bane of software development, so hacing your own version available would be better, at least as a backup
Personally, I am much more wary of the definition of "interaction" than of unwillingly distribute the software. The later one is a fault of the person accessing my computer against my will, not mine. But I have no idea how far "interaction" can be stretched-up, is using your software equivalent to signing some NDA? Hell if I know.
That said, FOSS authors normally aren't the kind of people that pushes to those crazy maximalist interpretations of documents. So if any risk exists, it's not large.
1) RoboVM had to use the GPL license because they used other people's GPL code - which they presumably pulled out / rewrote themselves in their new closed-source version
or
2) the author mistakenly believes that RoboVM is bound to the terms of the GPL license, or forced to offer new GPL licenses, on code they own 100%, just because they have offered GPL licenses to other people in the past
3) They released a binary and included the GPL license as part of the binary release licenses thus committing to the GPL in that release while not making the code available.
If they owned 100% of the copyright, then it still wouldn't matter. The GPL gives additional permissions, along with some restrictions / obligations, to Licensees. As copyright holder you are not a Licensee.
You do not need to grant yourself a license to distribute your own works. You always had that right.
Besides, who would sue you? The only person who has standing is the copyright holder. You're gonna sue yourself because you failed to honor the terms of a license, which was granted from yourself to yourself?
I don't think most Java and C# software is desktop apps? Surely in most cases it's the locale selected for the server or VM, which should be consistent?
(I'm not saying it's good coding practice, mind you, but it probably ends up accidentally working in a lot of cases.)
You write like you can know how and where the code will get executed in the future. :) Do you think that the authors of Windows 95 ever imagined the system would one day get ported to an obscure subset of a functional scripting language (Asm.js variety of JavaScript), and get booted in a hyper-text browser running on a PDA device with internet connection (web browser on a smartphone)? Yet - here we are: https://win95.ajf.me/
> I'm not saying it's good coding practice, mind you, but it probably ends up accidentally working in most cases
Fully agree. It's still bad practice and I high-five every linter that automatically flags it.
That's.. that's not what people mean when they talk about I/O in this context. But I think you know that, you're just grasping at straws to win an argument.