new | show | ask | jobs Github

the_duke 6 days ago

We are also entering the age of "hey AI, take this repo, reimplement the same functionality".

Now, no LLM is currently anywhere near doing that for ElasticSearch.

But for a project with 4845 lines of Python code? (as per tokei)

Definitely doable, with a bit of handholding and manual fixing.

Would that be a derivative work? Maybe, but that would be a hard legal battle.

▲

noinsight 6 days ago | parent | next [-]

> We are also entering the age of "hey AI, take this repo, reimplement the same functionality".

Wouldn't you do this just against the/an API documentation? Interesting thought.

▲

gkbrk 6 days ago | parent | prev [-]

> Now, no LLM is currently anywhere near doing that for ElasticSearch.

You could probably feed all of ElasticSearch into an LLM and ask it to "reimplement it" successfully. But why would you even bother? There's already an existing open-source alternative called OpenSearch [1].

[1]: https://github.com/opensearch-project/opensearch

▲

sarlalian 6 days ago | parent [-]

His point was that we are quickly entering the land of “Source Available” not really being a shield if someone’s willing to spend some time in claude code.

	▲	SpaceNugget 5 days ago \| parent [-]
		If you viewed the source and reproduced a software project you don't have a license to redistribute, that's cut and dry copyright violation. If the code looks similar enough you are toast. That's why there's the concept of a "clean room" reimplementation. The same is true if you feed the source into the context of an LLM and asked it to reproduce it. You have done nothing but introduce the possibility of transcription bugs.