On 12/04/2026 08:07, jbranso wrote:
April 11, 2026 at 5:38 AM, "Amos Jeffries" wrote:


On 11/04/2026 01:31, jbranso wrote:


I'm assuming that the Hurd's current policy is not to accept AI contributed 
code.
  Opperating under that assumption, I'll add a patch to the wiki documented
  that we are ok with AI to debug the Hurd codebase, but NOT to write code.
  Thanks,
  Joshua

I recall there being issues with peoples patches to some of the Hurd related 
GNU projects not being merged due to copyright assignment issues.

I don't believe that this is an issue.  I have been contributed to the hurd 
wiki for years (without copyright assignment).
When I submitted my first contribution to the Hurd manual, Samuel would not 
merge my patches until I had assigned copyright.

Exactly. You were able to assign **your** copyrights.

IFF the AI is "a legal person/entity", then they/it have to come and assign any permission for Hurd to use their code. Per normal policy the patch is not permitted, yet.


If the AI is "just a tool", then things become a question of who has the copyrights for the generated patch.

I am not sure if the foundational question of whether AI is generating new content, or copying others work has been settled in legal circles. Let alone whether there is a Hurd policy or view about it.



So I'm pretty sure Samuel would catch anyone trying to contribute without 
assignment.


That is not the point.

The point is about what to publish in the wiki about **why** AI patches are rejected.



I'm not sure who is in charge of Hurd legal matters, but it would be worth 
checking with them for anything like the above, to document as relevant for AI 
generated code.

HTH
Amos

I do wonder what the FSF will encourage GNU package maintainers about A.I.  I 
assume that they do not want AI contributions, but I
do not know if they have released an official statement or not.

I know Linus just allowed AI contribution to Linux:  
https://docs.kernel.org/process/coding-assistants.html

Thanks,

Joshua


Thanks for that link. That kernel policy has some interesting implications and foresight in the wording.


HTH
Amos

Reply via email to