When working on a software project as an independent team of freelance developers, is it legally advisable or inadvisable to give a copy of the Project Plan and Systems Design documentation to the stakeholder(s) that details the schematics and inner-workings (not necessarily the hard code) of the created software?

Copyright and Intellectual Property laws in Canada state that developers who create the software acquire automatic copyrights to the software and can prevent others from making or distributing copies but I'm not quite sure if that extends to the stakeholders who the software is developed for.

  • What are you hoping to accomplish by giving this document to them?
    – Erik
    Aug 1 '18 at 5:30
  • Say, in the case of the client wanting to know the project specifications and planning?
    – 5120bee
    Aug 1 '18 at 8:37
  • 3
    I'm voting to close this question as off-topic because it might be a better fit for Law Stack Exchange.
    – Sarov
    Aug 15 '18 at 12:54

Capture Legal Issues, Then Delegate

While your question about copyright is largely off-topic, and can't be properly answered on a site about project management, knowing how to deal with legal issues is certainly a project management topic.

From a project management perspective, making legal decisions is out of scope other than as a tracking item for the project. Typically, legal issues such as contract language, or business questions about property ownership, would be captured in the charter, project plan, or other documents as work items and then delegated to a responsible person for further action.

More broadly, if your company has not defined a standing policy about what documents or deliverables a client should typically receive during an engagement, then business leaders or the legal department should be involved in reviewing anything where there's a potential impact to the company.

Information Controls in Project Management

Disclaimer: Specific legal advice is something you ask a lawyer, not strangers on the Internet.

Copyright, and intellectual property (IP) in general, are complex areas of the law. In Canada, for example, there is a default assignment of moral rights in a work that is separate from economic rights. In contrast, the United States doesn't explicitly provide for moral rights, and many businesses address the economic rights through work-for-hire and non-disclosure agreements.

From a project management perspective, your company should have policies and standards about:

  • employment, contracting, and confidentiality agreements
  • information classification
  • trade secrets
  • company property, including IP

Your job as a project management professional is to include those policies and standards in your project planning, or to refer them back to the business if questions arise during the project. For example, your project controls may include gathering any necessary contracts or client agreements as a project dependency to beginning work.

Furthermore, your definition of done should adhere to any company policies for confidentiality and information classification. That may mean marking deliverables with the appropriate classification, or enforcing other controls as part of the delivery process.

If no policies, standards, or controls for any of these things exist in your company, it's not the project manager's job to invent them. Instead, you should document the issues, and raise them to stakeholders and business leadership for disposition.


(In most cases) They shouldn't even need to know.

When asked:

What are you hoping to accomplish by giving this document to them?

You answered:

Say, in the case of the client wanting to know the project specifications and planning?

Given any random client and scenario, I am 97% sure that, when a client asks for the project spec/plan, they do not need nor even want a detailed analysis of how the code looks and behaves behind the scenes.

Rather, what they want to know is how he product will behave. Most clients will not care one whit whether their data is stored on an external server's database or an external server's flat files. What they will care about is if that data is secure, if the data can be accessed in a timely manner, if the data is correct, etc.

And in order to determine that, you have no need to provide implementation details.

You need to work on separating implementation details (we'll use these classes and this framework and this architecture...) from product behavioural details (the client needs a CRUD interface to maintain information regarding...).

The former is under the sole purview of developers; few other needs or even care to know about them. The latter is mostly under the purview of the client, so clearly they need to know about them - in most cases, the client will be the one supplying such information (though often not without assistance from the vendor).

Not the answer you're looking for? Browse other questions tagged or ask your own question.