Since none of the answers above address the underlying problem you are trying to solve, here's my personal take on this.
First of all let's dissect your described situation:
You work with a team of people that write software who in your assessment are failing at sharing knowledge among themselves.
Furthermore, when they are forced in a formal manner (you set up a meeting) to do so, they behave as if being under scrutiny.
You dislike this situation as you consider it a sign of lack of motivation and proactivity.
Situation 1 is extremely common in all software teams I worked with. Reasons for faulty communication range, in my experience, from people being unable to properly communicate in a formal setting to faulty management or dysfunctional teams.
While a single individual that fails to properly communicate within a team can be trained to do so, conflicts can be managed and management can be replaced or trained to better handle the team's problems, you will need a centralized process for information sharing between teams.
Stuff like Confluence, Microsoft Teams, Skype and Redmine can help you with the administrative part of handling formal inter-team communication. You will still need to create some sort of process to ensure those resources are properly understood and used by the team members and that they understand and commit to the necessity of keeping each other updated. What I mean is you will need to set up a process to teach people in charge of those teams to enforce the use of formal documentation. Even if that formal documentation is just a story in redmine and a post on how it's supposed to work in Confluence and who is responsible for maintaining the code that makes it work.
Secondly, you tried to fix the communication problem by bunching a lot of people in the same room and hoping they start talking work-related stuff to each other when no boss is present. Hate to break it to you, but most software devs are egotistical people, so your meetings will most like turn into an e-peen competition with no real benefit coming out of them other than people will soon learn who the alpha dev around is. And why to avoid him/her.
The fix for this is to adjust your expectations. You want your devs to talk to each other or do you want them to effectively communicate? If the answer is the latter, your approach is clearly not working. Because we're all people, not machines.
Thirdly, you seem to draw the wrong conclusions. If all you did for your teams was to force them to rub shoulders against one another in the same room for several hours, then you went about this the wrong way. It's not a sign of lack of motivation or lack of proactivity if they refuse to do so. It just means you went about solving your teams communication issues the wrong way. By trying to solve all of them at once.
My suggestion is to attempt to understand if and why there are any communication issues inside each of the teams involved then set up a formal process that can be tracked for inter-team information sharing (see point 1). And maybe adjust your expectations a little bit. Not everyone is good at sharing knowledge in a formalized setting, so a bit of leniency towards slow learners might be beneficial at start.