The mysterious life of Luc Esape, bug fixer extraordinaire. His big secret? He's not human Luc Esape leads a double life. The software engineer on the Spirals research team at the University of Lille in France goes by another name, Repairnator. Repairnator has a superpower, the ability to fix bugs during continuous integration. That's the process by which servers continuously and automatically compile code and …
Never mind that! YouTube is down worldwide and I'm on the dole!
The serious news would be if Facebook when down. Millions of voices screaming in the night and utter chaos as those hapless souls wandered about offering to show total strangers a picture of what they had for lunch or dinner. But cat video fans would be worst... jumping, doing "cute" cat things to show others what their cat does.
Let it fix Win10, expunge all the bugs, & tighten up the code by a couple of gigabytes. Prove the bot more capable than the entire stable of MS coders, release a version of Win10 that *doesn't* suck arse, & the world will shower you in storms of cash in gratitude.
I'll buy you a virtual pint at your favorite cyber cantina, just as long as you promise not to reprogram the POS terminal to play ChipTunes with every transaction. =-)p
It isn't a good question. It is an important question, that needs to be discussed and very clearly answered. But, fortunately, the answer is simple: no one owns it.
Just as no one owns the wild deer who come into my garden and eat my flowers, and no one owns a fish in the middle of the ocean, and no one owns the sound of the bird singing outside my window. And no one owns Shakespeare's Romeo and Juliet either.
It is a fallacy, pushed very very hard by the big copyright owners, that everything has to be "owned" by someone. Things which are in the public domain are not owned by anyone, and things created by machines go straight into the public domain -- essentially the copyright term on them is zero.
Responsibility is harder. In general, the operator of a machine has responsibility for its actions: if I let go of a self-propelled lawnmower and it kills someone it is my responsibility. It is complicated because sometimes responsibility may rest with (or be shared with) the manufacturer or the owner instead of the operator -- sometimes a court will have to decide which.
But, if you operate a bot which has been given check-in rights to a piece of software and it checks in bad code, you will end up with responsibility (maybe shared with whoever created it, depending on things like whether the operator was well-enough informed of the risks, whether the creator misrepresented anything, whether the creator was negligent, etc). However, in this case, the bot is just sending a suggestion to the person who has check-in rights: they have responsibility for the check-in if they approve it, just as they have responsibility if they accept a pull request from anyone else.
The most important thing is: don't fall into the trap of thinking that there is an "owner" for content created by a machine. There isn't -- it is in the public domain.
> and things created by machines go straight into the public domain
That's an interesting take. In the physical world the owner of a machine that makes widgets owns the widgets produced. Why shouldn't code be any different?
Because the "ownership" we are talking about here is copyright. The truth is that nobody owns code as it is infinitely copyable. But, in most cases, somebody owns a copyright on the code. But as copyright is an intellectual property right, it can only arise from human creativity, not from a machine.
Do not forget, you do not violate copyright if you independently come up with exactly the same code as someone else but did not copy theirs. It is not the code which is the property, it is the right to prevent others copying your intellectual creation which is the property.
The most important thing is: don't fall into the trap of thinking that there is an "owner" for content created by a machine. There isn't -- it is in the public domain.
Lego elements are created by machine. They are not "public domain".
This is not true in England & Wales - see Copyright, Designs, and Patents act 1988. Section 9. Subsection 3.
https://www.legislation.gov.uk/ukpga/1988/48/section/9
s(9)(3)In the case of a literary, dramatic, musical or artistic work which is computer-generated, the author shall be taken to be the person by whom the arrangements necessary for the creation of the work are undertaken.
In other words, if I write you a program and that program produces output, the output is copyrightable and the copyright belongs to the person running that program.
"Who accepts responsibility if one of the coders f**ks up a piece of life critical software and someone dies"
Whilst a structural engineer is liable for their designs, a programmer is NOT liable for their code. The law treats code as if it were literature.
A bot created invention might fail the inventiveness or non-obviousness test required for a patent. If a person skilled in the art can come up with it it is deemed obvious and no patent is granted. This person skilled in the art is a legal construct, supposed to know everything but lack inventive capacity. A programme automates and speeds up a predetermined set of rules that form the starting point (allowing for neural nets to be trained). TRIZ is one example of an invention framework.
A bot could still create an invention that could be useful, just like a TRIZ practitioner could and can.
Patent are complex in England & Wales, but copyright is quite straightforward.
Code or patches to code is a literary work, as such the copyright is automatic and vests in the creator.
My studies are rather out of date, but I was taught that software alone is rarely patentable within our legal framework. I think an additional hardware component is typically required, and the combined usage held to be "novel to one skilled in the art" for the grant of patent.
For example, industrial cyclones - prior art, filtering particulate matter with suction - prior art - dyson cyclone - patentable.
There isn't a way to best of my knowledge to make a pure software output say a VHDL chip generated by your bot, into a patentable item, regardless of how novel the output is, it's still a novel, literary work.
> human engineers do not accept contributions from bots as easily as contributions from other humans, even if they are strictly identical.
That is a mighty interesting phenomenon. Probably we are seeing the same pattern in the reactions to self driving cars and their mishaps. Let's not discard that intuition just yet, because there could be some good reasons to apply a double standard here.
- Humans can only foobar one thing at a time. In Goethe's The Sorcerer's Apprentice, problems start after multiplication of the broom. A human programmer cannot be copied and applied to a large set of tasks simultaneously.
- Writing unsecure code is easier than writing secure code. If we train algorithms on our human work, they will be by definition be prone to human errors in security.
- The increased expediency can create more code than any human could ever review. Working code is not always the best code, but the sheer volume of it could quickly make it a much tougher job to accept commits without crossing fingers.
- Algorithms don't mind incessant and perfectionist criticism, they thrive on it. In some ways it is the essence of reinforcement learning.
This sounds like fun, maybe it will finally become safe to write in Visual Basic again?
But joking aside, perhaps we've finally found a use for AI? We can now start employing programmers at $10/hour - no need to worry about the quality of the code, Luc Esape can fix any bugs.
Just on the basis of what I've been working on today, every failed build could be fixed in an obvious way, but quite often just getting a clean build doesn't remove an underlying bug caused by a very human development process. I'm not sure a bot submitting fixes would get me to code working in a way I intended, any faster.
So I guess there are questions about the code quality here: did it produce maintainable, readable code?
It went through a couple of human review processes, so I guess the answer is "yes."
And if the trigger for this is a broken test, then unit and integration tests become even more important to the code creation and maintenance process.
In fact, the existence of a robot "code fixer" suggests that test driven development will become the way we work as coders - with Mr. Esape doing the coding.
If you think this is not going to happen, or that this is a one off: think again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
