I don't think the final point about programming languages makes much sense.
In the overall software development process, lots of people contribute different things to create the product.
The job of the software developer is to bring the amount of ambiguity in the specification to zero, because computers can only run a program with zero ambiguity.
There have been lots of high level programming languages that abstract away certain things or give the programmer control over those things. The real thing that you want to do is pick a programming language that allows you control over the things you care about. Do you care about when memory is allocated and deallocated? Do you care about how hardware is used (especially GPUs and ML accelerators) or do you want the hardware completely abstracted away? Do you care more about runtime or dev iteration time? Does your program need to exist in a certain tech context?
There's no programming language that will let people who care about different things deal with them or not deal with them.
I can see 3 ways that you can guarantee that the output of a model never violates copyright
1. Models are trained with 100% uncopyrighted or properly licensed input data
2. Every output of the ML model is evaluated to make sure it's not too close to training data
3. Copyright law is changed to have a specific cutout for AI
#1 is the approach taken by Adobe, although it generally is harder or more expensive to do.
#2 destroys most AI business models
#3 has been done in some countries, but seems likely that if done in the US it would still have some limits.
For example, I could train a model on a single image, song, or piece of written text/code. Then I run inference, and get out an exact copy of that image, song, or text. If there are no limits around AI and copyright, then we've got a loophole around all of copyright law. I don't think that the US would be up for devaluing intellectual property like that.
I think the big difference is that it's not a direct replacement - it feeds off of the existing people while making it much harder for them to make a living.
It would be as if instead of cars running on gasoline, they ran on chopped up horseflesh. Not good for the horses, and not sustainable in the long term.
It seems very difficult to ensure that a model will never output any of the copyrighted content that it was trained on. I can only think of three ways, but perhaps there are others
1. Evaluate every output from the model to ensure that none of the outputs are copyrighted
2. Evaluate every input to a model to ensure that the inputs are either not copyrighted or properly licensed
3. Change the definition of copyright so that ML models can do whatever they want
Nobody is doing #1, because that makes the business models not work. Established brands (like Adobe) are doing #2. I get the feeling that there are a lot of ML startups that are hoping that #3 will happen, but it seems unlikely
I would have thought that purpleair was the best-known consumer brand. It looks like this May they introduced API pricing? But honestly, it still seems very reasonable
they also had an internal source control system that they never released, which was a fork of perforce that they had purchased the rights to use and modify. Not sure if that's still in use in any projects.
Exactly, I'm sure you're familiar with the kinds of difficulties and complications that creates. Rather than representing that curve analytically, you have to keep track of the procedural tree that generated it. Then things like offsetting that curve, checking that curve for intersections, etc. are more complicated.
And then you export. Rather than exporting the entire procedural tree (which would require shipping the entire kernel), you approximate the curves with NURBS trimming curves. When you import from another CAD tool you need to deal with edges that only intersect within a given tolerance, and sometimes that tolerance is awful (Catia, I'm looking at you). Operations on toleranced edges are a huge source of complications.
And so on and so on. It would all be so much easier if the NURBS math could be exact
Yeah, on the big kernels the time just getting filleting working robustly can be measured in developer-careers.
The core problem isn't memory safety, it's due to difficulties with the mathematical foundation of NURBS surfaces. For example, the intersection of two NURBS surfaces can't be exactly represented by a NURBS curve.
It reminds me of the Mirror Self-Recognition test. As humans, we know that a mirror is a lifeless piece of reflective metal. All the life in the mirror comes from us.
But some of us fail the test when it comes to LLM - mistaking the distorted reflection of humanity for a separate sentience.