Developers and managers of free/libre/open works are involved with globally-distributed co-authors, co-managers and partner organizations. Several domains of law affect these people in their capacities as individuals, contractors, sub-contractor or employees and their organizations. And there are differences in the semantic meanings to words across languages, cultures and jurisdictions. When working in a distributed project, one needs to pay attention to how formal laws and contracts are codified within different sub-national, pluri-national, and multi-national legal jurisdictions. This is terribly complex.

Most FLOW developers and managers read software licenses. Many of them proceed to read about and discuss the legal foundations of the functional rules and responsibilities that licenses put in place. Developers and managers of FLOW projects typically are not inclined to defer matters of law to "the legal department", if they have access to one. Even when they try, developers and managers can rarely get face-time with, or written assessments from qualified legal counsel, in order to obtain timely guidance prior to making legally significant project decisions. 

Furthermore, when developers and managers do manage to communicate directly with lawyers, only a small proportion of lawyers are directly familiar with technical aspects of software systems. An Explanation of Computation Theory for Lawyers is an excellent primer, but this is probably more than most lawyers have the time or inclination to deal with. On the other hand, it can be difficult for legal counsel to appreciate the depth of knowledge that many developers have about legal concepts, agreements and issues relating to free/libre/open approaches. It is generally more pragmatic for developers and team managers to become functionally conversant in the lawyers' realm, than the other way around. This can lead to tension between those who are formally educated in law, and those who have learned about law informally. Neither finds it easy to have their competencies and ideas challenged.

With that in mind, FLOW developers and managers should generally approach legal counsel with the understanding that they are specialist not only in the concepts and language of law, but in complex legal processes.  Just as in telecom networks, it is important to understand that within and amongst legal jurisdictions there are protocols for the administration of legal matters that structure the creation and dissolution of business relationships. Lawyers cannot be expected to have substantive technical understanding of the system layers, components and patterns that developers are working on. Futhermore given the nature and history of the computing industry, it should not be presumed that any particular lawyer's legal career has provided them the opportunity to gain direct experience with free/libre/open arrangements and solutions. Indeed, for lawyers experienced with retrictive models, several elements they would normally take for granted, such as the need to draft product-specific licences and to put in place escrow agreements with contractors, are neither essential or  relevant under the FLOW model. FLOW developers and managers who are able to explain why this is the case will help legal counsel help their their projects. Effective communication up front will help the process move forwards more quickly and smoothly. 

In an atmosphere of mutual assistance, managers and lawyers can attain the effective identification of constraints and opportunities to guide decisions, manage risk and meet project objectives in a manner that is suited to both the technical and legal contexts. There are many aspect of the FLOW model for legal counsel to like, for example free/libre/open licenses are typically much shorter than restrictive agreements. And the terminology of the main free/libre/open licenses has been peer reviewed by lawyers amongst many jurisdictions. 

With greater familiarity with legal constraints and principles governing their day-to-day work, developers and managers are better able to avoid problems in the first place, and to manage risk responsibly and intelligently:

• To reduce their errors and omissions;
• To understand the risks they are accepting;
• To effectively communicate the technical substance of their work in a manner that is parsed into legal concepts that are meaningful to lawyers; and,
• Generally, to build more effective lines of communication with their corporate or hired legal counsel. 

But how much law should non-lawyers learn? What topics and sources should they pursue, to what level of detail? Is it helpful or confusing for non-laywers to read case law, which tends to be highly adversarial, anecdotal and evolutionary? Or should non-lawyers read only the more stable synopses of legal principles? There are different legitimate opinions about this.

The FLOW Syllabus does include selected case law readings, but the OSI's Management Education Working Group cautions that learning from case law is like analyzing a scene in the middle of a movie, whereas learning from legal principles is like analyzing the thematic message of the whole movie. Both are useful, but case law alone and out-of-context can lead non-specialists in particular to misunderstand the whole picture.