kyaghmour

"interacting with it remotely through a computer network" isn't "distributing", it's hosting. Companies providing software under Affero licenses love to play with words. That's fine. It remains a bad license for users. I choose not to use any software licensed under its terms.

Have you actually read the Affero license?

From section 13: "Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

Your statement is incorrect: "You can even have and keep changes (unpublished) for you entire organization without having to contribute back. It is when you distribute it back to public that you have to license the changes under the same license."

Even *HOSTING* a private instance puts you under Affero. Even if the instance isn't public, if you so much as have a contractor remotely accessing an internal deployment of a customized Affero-licensed software then they can ask for this customization.

https://www.gnu.org/licenses/agpl-3.0.en.html

Here's from Leantime's own FAQ (https://leantime.io/pricing/): "We are GPL-2 and require code updates to be submitted back to the core code. We offer Enterprise licenses if you’d like to modify the code to use for company use."

Call it what makes you warm and fuzzy.

Here's from Leantime's own FAQ (https://leantime.io/pricing/): "We are GPL-2 and require code updates to be submitted back to the core code. We offer Enterprise licenses if you’d like to modify the code to use for company use."

The pattern is effectively always the same. Many companies use this license to offer a free version while offering a "way out" by providing an "enterprise license". They get you hooked because it's open source. But as soon as you want to customize and keep the changes, they want to charge you.

It's a matter of personal choice. I choose NOT to use any Affero licensed software if I can help it.

Affero is effectively bait-and-switch.

Google's moat is its data set. Imagine training an generative AI LLM on the entire set of YouTube training videos. No one else has this.

Google's moat is its data set. Imagine training an generative AI LLM on the entire set of YouTube training videos. No one else has this.

Who's next?

Warren Buffet on derivatives: "financial weapons of mass destruction."

Thanks for this. I'll take a look.

I can't find the article anymore (and I've looked for it several times in the past) but someone was making the point that open source was essentially an economic phenomenon. Insofar as distribution costs went to zero with the advent of mass-access to the internet then it was inevitable that people would start sharing software. Obviously this takes nothing away from all those early contributors, but it is food for thought.

Mind you while Linux was taking off the BSDs were apparently busy in lawsuits. So, while the zeroing of distribution costs should've benefited them, it seems Linux was at the right place at the right time, minus the baggage.

Some friends told me they ran into Andrew Tannenbaum at Embedded World a few years ago and asked him if he still believed that Minix was better than Linux. Apparently he said yes.

DISCLAIMER: 2nd hand story.

Have a look at "Investing in Stocks, How to Win Big! Strategizing, Positioning, and Leveraging for Success" by Kishore Mishra. It's self-pub on Amazon. The title is truly horrendous, the text would benefit from an editor, the layout would benefit from professional typesetting, etc. But it's written by an EE. I started reading it a while ago and liked how he approached the explanation from the ground up. It spoke to my engineering mind. Unfortunately I had to set it aside and it's been on my shelf for a while. But I'm thinking of picking it up again.

I had discovered this author by reading another book he wrote entitled "Advanced Chip Design, Practical Examples in Verilog". Also self-pub and also suffering from lots of self-pub issues. But the essentials were more-or-less there.

Oshpark for ASICs

I've successfully used SH3D to create plans for a 14'x24' workshop that a contractor then used to build it. A year later I used it to remodel 2 bedrooms with some funky closet arrangement and again gave the plans to a contractor to do the work.

It's got its quirks, but it's good enough to get a good idea of what things would look like. Most irritating is when its 3D viewer fails because of some random error as a separate window and has to be closed and reopened. Then again this was an older version. Maybe things got better since.

NFT to the rescue? :P

I've found that I can more easily get myself to get things done when I project myself into the future and remember the satisfaction of having done it. The projected nostalgia of a job well done turns out to be a powerful motivator for me.

Kieslowski's "thou shall not kill" and "thou shall have no other god" from Decalogue remain some of the most haunting films I've seen.

Sorry, you lost me at #2. How does the public receive a raise here?

How long would it take for "ChatGPT farms" to crop up and try to influence the results? How much harder will it be to "clean" the results from any learned data set?

Interesting. You have a reference? Been listening to his music for ~40 years and this is the first I hear that.

Thx for this!

Wow. Thx for this. Greatly appreciated.

I'm aware that the parent article doesn't refer to diabetes. I never said it did. As a general comment regarding this disease I shared what my current state of mind on this was. Is there a link between diabetes and the mechanism explored in the parent, maybe? I don't know. But maybe, just maybe, if enough paths are explored we'll eventually find the right one. Diabetes seems to be an interesting one for me ... but I'm by no means an expert. Just an interested observer that is doing a genuine effort to understand.

As someone who has a close relative diagnosed with this disease, I'm always on the lookout for new information. So this is interesting.

One area I'm particularly interested in is the correlation to diabetes. It's a factor that I found being mentioned here and there in some references. In the immediate case that interests me, there's a 20+ year history of type 2 diabetes and a recent scan showed severe bilateral hypocampal atrophy. When googling for a link between the two I found this: "Lower insulin secretion was significantly associated with HPGA (hippocampal and parahippocampal gyrus atrophy) in patients with type 2 diabetes mellitus. The results of this study support the hypothesis that insulin‐signaling abnormalities are involved in the pathophysiology of Alzheimer’s disease." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8504906/

Yet, the mechanism of this, if indeed there's causality (not just correlation) does not seem to be known.

I proposed something like that a few years back: https://lwn.net/Articles/780365/

There is something to this idea ... using git as a distributed (micro-)blogging/publishing system.

ARM is likely well geared for managing and collecting royalties from chip vendors (hundreds?). It seems to me that setting up an organization to collect from actual device manufacturers (~10^6-10^7 or more?) is a completely different scalability scope and, therefore, a completely different business. Maybe this is rather a targeted game of chicken tailor made against a specific licensee?

Also, re RISC-V. I'm all for that. But an ISA does not make a chip. There is far more to what ARM offers than just its ISA: production-grade cores and surrounding blocks on bleeding edge nodes, etc. They could, theoretically, start selling a RISC-V fetch and decode unit (think of it as a Unix API on top of Windows) and still come out on top.

There is nothing precluding ARM from providing a RISC-V fetch and decode unit as an option with their IP. Like having a POSIX compatibility layer or Linux subsystem in Windows. There is a lot AXI-based IP blocks out there, even in the RISC-V ecosystem. Having a RISC-V from ARM would make the switch more or less painless and the ability to benefit from known-to-be-good IP.

I'd conjecture that there are likely already toy projects at ARM to do just that, if nothing else as POCs by individual engineers eager to show colleagues how easily this could be done.

Now, whether strategically ARM would do this is another question. I suspect they'd hold off as long as it was realistically possible. But the deal is that an ISA is only one part of a huge stack of IP. And in that arena, ARM has a huge lead, especially considering that the granularity of the increment in terms of potential open source contributions is gated by huge costs that individuals can rarely take on on their own and lots of often arcane domain-specific knowledge.

I attended Josh's talk earlier this week at LPC. As I told Josh yesterday in the hallway track, I've been attending Linux conferences for 20+ years and often times some topics keep coming back and you can see the specialization. But in this case, I was completely blown away. This is a totally new approach to an old problem. I mean, fork() was invented in the '70's and aside from threads and clone(), in Linux, there really hasn't been any innovation in this space over the years. I look forward to seeing what else gets io_uring'ed following this model.

Success... in "business" is what this article covers. By no means the sole measure of "success".