... I'm not sure if I follow your train of thought @Fred Amaral
<[email protected]> ... are we for licenses or against... or sometimes yes
when convenient and not when inconvenient? Concerning inevitability: there
nothing inevitable about it, just a couple of examples:

   - Klarna:
   
https://www.forbes.com/sites/quickerbettertech/2025/05/18/business-tech-news-klarna-reverses-on-ai-says-customers-like-talking-to-people/
   - Microsoft:
   
https://finance.yahoo.com/sectors/technology/articles/microsoft-cut-engineers-off-ai-093500532.html?guccounter=1&guce_referrer=aHR0cHM6Ly9zZWFyY2guYnJhdmUuY29tLw&guce_referrer_sig=AQAAAC-CVBtokD1ka9SceOJU0K-2dR_3o9GYc2Lr8VV25nLzF9RXF4k-8QLBY_f3bbhgfMg7yXEPqK1lyF3E3C2pT_Fh_gsUbzypqFCK5l0HkE5pyxkART6QSGBzx2lS3EEBKzwnc425MgKoPxwYu2CYGl0my9jtrFf6gRU78A6ndj_t
   - Amazon:
   
https://www.livemint.com/companies/news/amazon-tells-staff-to-stop-using-ai-just-to-use-ai-after-shutting-down-its-token-leaderboard-11780098151409.html
   - Uber:
   
https://www.washingtontimes.com/news/2026/jun/3/uber-capping-internal-use-ai-coding-software-blowing-budget/
   - Google: https://www.engadget.com/2225849/google-shuts-down-alphafold/
   and
   
https://www.semafor.com/article/08/27/2026/alphabet-stock-sheds-700b-as-ai-bills-climb
   - ... in general:
   
https://medium.com/@avigoldfinger/55-of-ceos-who-fired-people-because-of-ai-already-regret-it-d54487e3cbe3
   - depending on your region:
   https://tokenstead.ai/guides/eu-ai-act-first-enforcement-security-rfis

... but then you have also:

   - Google (this time on the other side of the fence):
   
https://www.gulte.com/trends/395721/brace-for-ai-or-leave-google-tells-employees
   - Linux:
   
https://arstechnica.com/ai/2026/07/linus-torvalds-to-critics-of-ai-coding-in-linux-fork-it-or-just-walk-away

Just to say that there is variability... these things are not set in stone
like the 10 commandments... which one of those scenarios will win in the
end? I don't know, maybe common sense prevails and the two biggest
providers will just run out of money, but I'm as good as the next person
with predictions (read: I'm bad at it). Just to say: claiming inevitability
is as wrong as my capability to predict the future.

Maybe a suggestion: can we lay the inevitability argument to rest... at
least in this thread? Don't think it helps too much finding some common
ground (it kinda suggests that all is done). In a couple of years we will
all know if this was inevitable or not, right now this is just everyone
guessing.

So... what are the concrete rules...?


On Tue, Sep 1, 2026 at 8:35 PM Fred Amaral <[email protected]> wrote:

> thanks, alek. my point will always be: these LLMs ARE TRAINED on private
> data. there is no single one that has not broken out to media regarding
> that. however, the capacity of someone claiming propriety over a snippet of
> code within an open source codebase is clearly zero. snippets of code are
> not a codebase. it does not carry a stamp.
> i dont like to mention (cause seems to be an argument of authority), but
> the last messages from linus paint very well the scenario: it is inevitable.
>
> disclaimer: i'm biased, since i invest a lot on hardware to run LLMs on my
> own. my take is more to try to show that it's not a discussion about
> opening the can. it's already opened.
>
>
> On Tue, Sep 1, 2026 at 1:28 PM Aleksandar Vidakovic <
> [email protected]> wrote:
>
>> @Fred Amaral <[email protected]> the difference is that when you copy
>> and paste it's YOUR (the human's) choice and responsibility. If your
>> argument is that you can copy and paste while ignoring the rules then this
>> is certainly true, but even if no one knows then YOU still know that
>> something was not right; if no one detects you then congratulations, but if
>> someone does then you are the last to hold the bag.
>>
>> When you delegate all this to a machine then you are in a whole different
>> space: when you copy and paste you know what's going on, when an LLM does
>> this for you (and it does... however indirectly) then you don't know if
>> something wrong happened (was the LLM trained with GPL licensed data?), but
>> it doesn't exempt you either (see Adam's proposed policy point no. 2); so
>> how can you be accountable if you don't know how the results were put
>> together? OpenAI isn't (or doesn't want to be, see disclaimer). Try to open
>> 2 separate prompts and enter the same (non-trivial) text... is the result
>> reproducible? Claiming to not know doesn't make this problem go away
>> suddenly.
>>
>> On Tue, Sep 1, 2026 at 7:08 PM Fred Amaral via dev <
>> [email protected]> wrote:
>>
>>> in the old world, was taking a snippet from elsewhere a copyright
>>> infringement? (really a question, dont know).
>>>
>>> On Tue, Sep 1, 2026 at 12:56 PM Aleksandar Vidakovic <
>>> [email protected]> wrote:
>>>
>>>> ... this sounds like there is a standard... there is not. This is
>>>> already hard to achieve with classic development... there are a ton of
>>>> different approaches and (actual) standards (development on embedded
>>>> components in the automotive industry and similar)... to really make an
>>>> informed decision here we would need to make sure that two people that run
>>>> the same tool setup create the same results... I'd say: impossible, but
>>>> happy to change my mind if you point to an example where this ever happened
>>>> with AI tools.
>>>>
>>>> On Tue, Sep 1, 2026 at 6:17 PM Prashant Rahulkar <
>>>> [email protected]> wrote:
>>>>
>>>>> I think we should adopt the best industry framework to integrate with
>>>>> the Development agent.
>>>>>
>>>>> Thanks,
>>>>> Prashant Rahulkar.
>>>>>
>>>>> On Tue, 1 Sept 2026 at 17:10, Ádám Sághy <[email protected]> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>>
>>>>>> My two cents:
>>>>>>
>>>>>>
>>>>>> Since AI is already being used, having rules and a playbook would be
>>>>>> beneficial to avoid any misunderstandings.
>>>>>>
>>>>>>
>>>>>> Considering its widespread adoption across various fields such as
>>>>>> development, debugging, testing, brainstorming, and PR reviewing, we 
>>>>>> don’t
>>>>>> need to debate whether the Apache or Fineract community wants it. It’s
>>>>>> already in use, and contributors will continue to use it (*I don’t
>>>>>> believe there’s a way to prevent it, nor should it be!*). Let’s
>>>>>> focus on determining appropriate boundaries and its intended use.
>>>>>>
>>>>>>
>>>>>> Disclaimer: I am not up to date with latest “recommendations” of
>>>>>> Apache on this topic.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adam Saghy
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 1, 2026, at 8:53 AM, Sujan <[email protected]> wrote:
>>>>>>
>>>>>> Hi Aman,
>>>>>>
>>>>>> +1 to having some clear boundaries around AI-assisted development.
>>>>>>
>>>>>> I think there are valid positives and negatives here. AI can
>>>>>> definitely help with productivity, debugging, and refactoring, but
>>>>>> contributors should still understand and take ownership of the changes 
>>>>>> they
>>>>>> submit. If PRs become mostly AI-generated, it also makes them much harder
>>>>>> to review effectively.
>>>>>>
>>>>>> I think a lightweight, project-specific policy would be a good middle
>>>>>> ground rather than completely discouraging AI or allowing unrestricted 
>>>>>> use.
>>>>>>
>>>>>> On Tue, 1 Sept, 2026, 11:42 VICTOR MANUEL ROMERO RODRIGUEZ, <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Aman,
>>>>>>>
>>>>>>> Thank you for starting this important topic.
>>>>>>>
>>>>>>> *+1 to starting a dedicated discussion and adopting a lightweight,
>>>>>>> project-specific AI policy.*
>>>>>>>
>>>>>>> I support the direction because AI-assisted development is already
>>>>>>> happening (it is very noticeable this year before the GSOC and  the
>>>>>>> increasing numbers of PRs submitted and merged) and clear, practical
>>>>>>> guidelines (for developers and reviewers) will help us benefit from it
>>>>>>> without creating problems for maintainers or the project’s legal 
>>>>>>> posture.
>>>>>>> An optional disclosure approach plus a short *AI_POLICY.md*
>>>>>>> inspired by Apache Fory’s is a sensible starting point. It can be 
>>>>>>> adapted
>>>>>>> for Apache Fineract rather than copying it wholesale.
>>>>>>>
>>>>>>> To address the concerns raised earlier (including those from Aleks)
>>>>>>> I think is good to stay aligned with the ASF Generative Tooling Guidance
>>>>>>> https://www.apache.org/legal/generative-tooling.html
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Victor Romero
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El lun, 31 ago 2026 a las 23:44, Aman Mittal (<
>>>>>>> [email protected]>) escribió:
>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> I want to revive the discussion based on
>>>>>>>> https://lists.apache.org/thread/xxoqt3jn8trhwo1lnxjy46r1dkolfg1h
>>>>>>>>
>>>>>>>> and Concerns raised by Aleks in
>>>>>>>> https://lists.apache.org/thread/oq25gyjsx0wry4jf58odds9z92pfx6bj
>>>>>>>>
>>>>>>>> Regarding the usage and guidelines of AI, I think we need to
>>>>>>>> discuss AI-assisted development a bit more, so I'm creating this 
>>>>>>>> dedicated
>>>>>>>> thread on the dev list.
>>>>>>>>
>>>>>>>> As per my understanding, using AI is fine if contributors
>>>>>>>> understand their work and can explain their reasoning for each line.
>>>>>>>>
>>>>>>>> So, I'm thinking we can start with an optional disclosure policy on
>>>>>>>> that.
>>>>>>>> I think we can add a AI_POLICY.md for each repo. One policy we can
>>>>>>>> take inspiration from is
>>>>>>>> https://github.com/apache/fory/blob/main/AI_POLICY.md
>>>>>>>> While we do not need to copy it entirely, we can take inspiration
>>>>>>>> from it and modify it for FINERACT and all the repos based on community
>>>>>>>> feedback.
>>>>>>>>
>>>>>>>> I suggest that it should include Commonly used AI setups that
>>>>>>>> contributors did not declare in an AI usage disclosure.
>>>>>>>>
>>>>>>>> What does the community think about this?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Aman
>>>>>>>>
>>>>>>>>
>>>>>>

Reply via email to