Contributors

Re: Guidelines for LLM generated contributions

This an extremely important topic as AI is completely changing software development in a matter of weeks.

Of course we should require human contributors to do their correction job before submitting the PR. They can run the CI in their organization 1st, it's easy. May be we should explain how in the migration wiki or contributing.md ?

I woukd say yes it's also important to tell AI has been used and at the same time I'm sure in just a few months the vast majority of us will be using some AI in their PR or will be left behind. So soon enough then telling your PR is using AI will be the noise and not the signal...

There is a positive side: in less than 1 year (may be just 6 months) I think 50% of the modules will be able to be migrated automatically with AI and meet all checks. The same will also be probably true for OpenUpgrade.

This will allow us to use the bleeding edge Odoo with all the ecosystem and free us for more interesting work than migration. At some point this is our chance for not getting distanced by Odoo Enterprise.

This raises other concerns: what will be a valid contributors.md or authors.md entry? How will the OCA keep being organized as a meritocracy when the contributions made will soon enough mostly translate to the amount of compute used? How long before AI will claim PSCs?

May be we should also have repo to build these AI migration or review bots? I did some tools already and will tell about them soon... Reach me personally meanwhile if you are interested.

I see many people in the OCA in the denial phase who think AI is just a hype and or just for toy code. There is definitely a hype bubble and It is not able to do the hardest code today but it already beats you at the 50% of the easiest code you write and it is not going to stop any time soon...

This is really such an important topic...

And BTW I believe this will bring dystopia and not abundance. But can we even avoid it?

On Thu, Sep 18, 2025, 6:22 AM Graeme Gellatly <notifications@odoo-community.org> wrote:

I actually just completed a course in ai governance and ethics. It was finance focused as requirement for being an accountant, but declaring usage of llm in generating any professional services output is the very bare minimum. Human review was a mandatory part of governance, but honestly there was like 50 things there.

E.g This PR was generated using x llm and reviewed by a human for correctness prior to submission.

Le jeu. 18 sept. 2025, 21:12, Tom Blauwendraat <notifications@odoo-community.org> a écrit :
Thinking a bit out of the box here, but what might perhaps work is if:

- We set up a separate organisation OCA-ai
- This mirrors the full OCA organization as a fork, similar to odoo vs OCB
- If something looks like AI we close and tell contributors to reopen it there (could possibly be automated with the OCA bot if we can recognize something as AI)
- In that organisation we require 100% test coverage and passing tests, as well as the standard migration process having been followed (could be automated)
- If the bot decides there that it is OK, it automatically reopens the PR to the real OCA organization (where we thus only get "prefiltered" PRs)

In the absence of such automation I +1 Stefan's suggestion of adding a guideline

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Raphaël Akretion - 01:36 - 18 Sep 2025

Reference

Guidelines for LLM generated contributions

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

by Stefan Rijnhart - 09:40 - 18 Sep 2025

32 replies 32 replies

RE: Guidelines for LLM generated contributions
Thanks Stuart for the decent & constructive reply.

Copyright is indeed an issue industry wise, as you mentioned, with many lawsuits in place but no clear direction. This is due to how LLM models are trained and how data converted into tokens, relations, and weights and stored into multi-dimensional vector space. Certain paths may represent a piece of copyrighted artifact.

Yes, I do supervise my AI agents very strictly. Vibe coding, or whatever they call it, does not work in writing code for Odoo or any enterprise/ERP level codebase. In such complex codebase best is to treat AI agent as normal employees flow, keeping a human at last step is a must. It is crazy to see an LLM getting lazy like if it is the last hour before weekend, but it happened many times. Since those AI Agents are trained using humans data/traces, it includes good and bad behaviors and it requires some skills similar to managing normal team.

I do respect and admire OCA brand very much and I know code quality is very high in general. It is not easy to get a module into OCA repository. OCA guidelines & policies are really rail guarding the quality and the brand.

I think of LLM-OCA subject as two parts: 1) list of concerns and clarifications that would result into guidelines & policies, 2) AI tools and their usage. Even though there are many AI tools/agents but the ones that can really work in such codebase are very few.

It is my pleasure to be part of it, it is always a joy to contribute.

Sincerely,

Hussain H.

From: Stuart J Mackintosh <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 7:18 PM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

Best wishes,

Stuart.

On 09/10/2025 10:22, Hussain Hammad wrote:

Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects

with PRs for module migrations: https://github.com/OCA/web/issues/3285.

This volume is likely made possible through automation, with an LLM

generating the actual migration code (on top of, hopefully, a more

deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has

reviewed, refined and tested the code generated by an LLM, this should

not be a problem but as a reviewer I'd like to know what I can expect.

Holger Brunn pointed out to me that in other projects, this may be

covered by a demand in the guidelines to disclose LLM usage and its

extend. For an example, see

https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines.

Additionally, I would like to suggest that the basic premise (the

generated code is indeed first self-reviewed, refined and tested) is

also made explicit, and that it is unacceptable to pass on reviewer

comments to the LLM only to copy back the LLM's response (which has

happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to

the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,

Stefan

--

Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam

tel: +31 (0) 6 1447 8606

web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Hussain Hammad - 04:26 - 11 Oct 2025

Re: Guidelines for LLM generated contributions

Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

Best wishes,

Stuart.

On 09/10/2025 10:22, Hussain Hammad wrote:

Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions
...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic
Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:
Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.
On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:
Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik
Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:
Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:
I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:
I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope. Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:
Dear all,
 
at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).
 
Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.
 
I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).
 
Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?
 
Cheers,
Stefan
 
 
 
 
 
-- 
Opener B.V. - Business solutions driven by open source collaboration
 
Stefan Rijnhart - Consultant/developer
 
mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
 
 
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

Open Digital Consulting Co Logo

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

by Stuart J Mackintosh - 06:16 - 9 Oct 2025

1 attachments 1 attachments

RE: Guidelines for LLM generated contributions
Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects

with PRs for module migrations: https://github.com/OCA/web/issues/3285.

This volume is likely made possible through automation, with an LLM

generating the actual migration code (on top of, hopefully, a more

deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has

reviewed, refined and tested the code generated by an LLM, this should

not be a problem but as a reviewer I'd like to know what I can expect.

Holger Brunn pointed out to me that in other projects, this may be

covered by a demand in the guidelines to disclose LLM usage and its

extend. For an example, see

https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines.

Additionally, I would like to suggest that the basic premise (the

generated code is indeed first self-reviewed, refined and tested) is

also made explicit, and that it is unacceptable to pass on reviewer

comments to the LLM only to copy back the LLM's response (which has

happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to

the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,

Stefan

--

Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam

tel: +31 (0) 6 1447 8606

web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Hussain Hammad - 10:21 - 9 Oct 2025

1 attachments 1 attachments

image001.png
Re: Guidelines for LLM generated contributions
...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.
+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.
+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all, at least one contributor is planning again to flood the OCA projects with PRs for module migrations: https://github.com/OCA/web/issues/3285. This volume is likely made possible through automation, with an LLM generating the actual migration code (on top of, hopefully, a more deterministic tool like OCA's odoo-module-migrator). Regardless of the volume and the submitter, if the submitter has reviewed, refined and tested the code generated by an LLM, this should not be a problem but as a reviewer I'd like to know what I can expect. Holger Brunn pointed out to me that in other projects, this may be covered by a demand in the guidelines to disclose LLM usage and its extend. For an example, see https://github.com/ghostty-org/ghostty/pull/8289/files. I would very much like to see such an addition to the OCA guidelines. Additionally, I would like to suggest that the basic premise (the generated code is indeed first self-reviewed, refined and tested) is also made explicit, and that it is unacceptable to pass on reviewer comments to the LLM only to copy back the LLM's response (which has happened to me on one or two occassions). Can I have a temperature check for your support for such an addition to the guidelines? Or do you have other ideas or perspectives on the matter? Cheers, Stefan -- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail:stefan@opener.amsterdam tel: +31 (0) 6 1447 8606 web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER
>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Joël Grand Guillaume - 09:26 - 29 Sep 2025
Re: Guidelines for LLM generated contributions
How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

Good points and well made - yes, this future is coming and OCA and community must be at the front of it.

I feel that a clear OCA position is important as without it, there is risk of collaborators working with different rules and assumptions which ultimately costs time and energy. So this is the opportunity for the community to work out what are the shared rules for this new world. If there is insufficient information owing to the rapidly changing landscape, then soft guidance may be the OCA position for now.

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all, at least one contributor is planning again to flood the OCA projects with PRs for module migrations: https://github.com/OCA/web/issues/3285. This volume is likely made possible through automation, with an LLM generating the actual migration code (on top of, hopefully, a more deterministic tool like OCA's odoo-module-migrator). Regardless of the volume and the submitter, if the submitter has reviewed, refined and tested the code generated by an LLM, this should not be a problem but as a reviewer I'd like to know what I can expect. Holger Brunn pointed out to me that in other projects, this may be covered by a demand in the guidelines to disclose LLM usage and its extend. For an example, see https://github.com/ghostty-org/ghostty/pull/8289/files. I would very much like to see such an addition to the OCA guidelines. Additionally, I would like to suggest that the basic premise (the generated code is indeed first self-reviewed, refined and tested) is also made explicit, and that it is unacceptable to pass on reviewer comments to the LLM only to copy back the LLM's response (which has happened to me on one or two occassions). Can I have a temperature check for your support for such an addition to the guidelines? Or do you have other ideas or perspectives on the matter? Cheers, Stefan -- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail:stefan@opener.amsterdam tel: +31 (0) 6 1447 8606 web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER
>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
by Stuart J Mackintosh - 05:31 - 28 Sep 2025

1 attachments 1 attachments

logo.png

Archives

Contributors

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Reference

Guidelines for LLM generated contributions

RE: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

RE: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Follow us