Doing charity work does not mean you don't expect to be paid for your regular work. Also, a lot of companies do pay devs to work on open source projects.
Open source isn't charity - just like playing non-professional sports isn't charity: the vast majority of participants see it as a hobby or social activity. A minority get paid, and a minority of the minority "break even", but vast majority are playing in self-organized leagues and pick up games, which are in no shape or form charities (even if the public can watch for free as a side-effect).
I think the next release is gonna give you a lot of flexibility to write your own helpers that can generate the raw fragments you need. Not as good as having the features built in of course, but it'll do in a pinch.
jOOQ and jOOQ-like API's in other languages are the Right Thing in most cases, IMO. I've worked with very abstract ORM's, I've worked with raw SQL, and I've worked with a lot of things somewhere in between and that's my conclusion.
I think that the author has a warped idea of how LLMs work, and that infects its reasoning. Also, I see no mention of the inequality of this new "copyright free code generation" situation it defends; As much as Microsoft thinks all code is ripe for taking, I can't imagine how happy they would be if an anonymous person drops a model trained on all leaked Windows code and the ReactOS people start using it. Or if employees start taking internal code to train models that they then use after their employment ends (since it's not copyright infringement, it should be cool).
I think the author has a much better knowledge of the legal implication of the situations you describe.
These situations might trigger a lot of issues, but none related to copyright. If you work for MS, then move to another company, there is no copyright infringement if you simply generate new code based on whatever you read at MS. There might be some rule regarding non-competitive, etc, but these are not related to copyright.
The very basic question is how the LLM got trained and how it got access to the source. If MS source code would leak, you cannot sue people for reading it.
Having read MS code and starting to generate new code that is heavily inspired - sure, that's not copyright infringement. But, if you had memorized a bunch of code (and this is within human capability; people can recite many works of literature of varying length with total accuracy, given sufficient study) - that would be copyright infringement once the code was a non-trivial amount. The test in copyright is whether the copying is literal, not how the copying was done/did it pass through a human brain.
This scenario rarely comes up because humans are, generally, an awful medium for accurate repetition. However, it's not really been shown than LLMs are not: in fact, CoPilot claims (at least in its Enterprise agreements) to check its output _does not_ parrot existing code identically. The specific commitment they made in their blog post is/was, "We have incorporated filters and other technologies that are designed to reduce the likelihood that Copilots return infringing content". To be clear, they only propose to reduce the possibility, not remove it.
LLMs rely on a form of lossy compression which can sometimes give back verbatim content. I think it's pretty clear and unarguable that this is a copyright infringement.
Author here, sorry about that, I just deployed a fix, should be readable now. If it's not, here's the first few points
- Once you get good at Rust all of these problems will go away
- Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker
- Indirection only solves some problems, and always at the cost of dev ergonomics
- ECS solves the wrong kind problem
- Generalized systems don't lead to fun gameplay
- Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
- Procedural macros are not even "we have reflection at home"
- ...
the list corresponds to the titles of sections in the article.
Awesome! I recently encountered the need of expanding a Spring Boot Admin instance to offer OpenAPI docs for custom Spring Boot Actuator endpoints which are in their own group, hidden from the main API. As SBA requires custom views to be Vue.js components, this will probably fit pretty nicely.
reply