Using "should" instead of "must" about open-source-logiciel-libre

[LaurentGoderre]

Number 1 is different though because if you don't include a license then it isn't open source code. You can publish code without a license but in order for it to be open source, it must have a license.

[LaurentGoderre]

I also agree that number 3 should be a should. I don't think we want federal employees to have two separate accounts.

[gcharest]

@LaurentGoderre @pjackson28
I think the guides might actually need the "must" verb due to the fact they list elements that are covered by the law, like for the licence.

We could change the sentence syntax to explain such as:

• In order for a project to be considered legally open source, it must contain the following.
  • Licence file as part of the source code

Etc.

[gcharest]

Regarding 3, we need additional guidance from a legal perspective.

This is what the industry does and I'm open to any suggestion that could help make this as easy as possible for everyone. IP ownership of work done during work duties is Crown owned unless told otherwise.

Again, would love some creative ideas here.

[wardi]

@gcharest creative ideas for 3? It would help to know the motivation. Are you thinking we should be able to automatically scan repos for contributions to identify crown assets?

[LaurentGoderre]

Is the IP ownership this clear cut though? The crown owns the IP for it's original work but it gets murky for contributions to projects owned by external entities. A hard stance like this could lead to OSS projects refusing any contribution by the GC.

[wardi]

@LaurentGoderre +1

Clear cut ownership gets us is the ability to do things not allowed by the OSS license the project is released under, but at that point we're talking about a quasi-OSS, dual license + CLA model. That model hampers outside participation (we have more rights than contributors, contributors need to jump through more hoops) and is a risk to the success of an OSS project.

[keithdouglas]

This and other topics like it remind me: does TBS have a IP lawyer who understands software this project can consult with? I know us computing folks like to play amateur lawyer, but that's probably a bad idea. :)

[pjackson28]

It is true that it isn't open source if you don't include an open license, what I was pointing out is that it isn't a TBS mandatory requirement. The use of the "must" comes across as because TBS says so, when in reality, it has nothing to do with TBS. It would be better if it had the additional context as that gives the actual why. For instance, "Source code must include a licence before publishing to a public source code repository" could be changed to "To release software as open source, include an open source licence with the source code before publishing to a public source code repository." The second sentence doesn't come across as a TBS commandment, but instead as a reminder of what is needed to release software as open source.

[keithdouglas]

Note that some organizations already require (technically) to use real names and GoC contact information when on "official business" online. I see no reason why TBS couldn't just set this for everyone (or at least in the context of open source projects).

[pjackson28]

For number 3, it is one thing to require that GC employees use real names and GC contact information for official business online, it is another thing to try to mandate it through a guide. A guide should not be the place where you mandate anything, at most you should have references in the guide to the separate policy instrument that is responsible for establishing the requirement.

[gcharest]

@pjackson28 I agree and requirements should be added if needed in the updates of policy instruments we're pursuing as well.

@LaurentGoderre @wardi I think OSS projects are usually clear on IP of contributions. If there's a need for transfer of IP, they put a CLA in place with specific Terms and conditions. We're actually not recommending the use of CLAs here.

Because we contribute something doesn't mean we suddenly transfer our IP (whether individually or organizationally owned). It just means that we are making our own contributions under the same licence as the project.

So I technically still own the IP of the contribution I did but I'm applying the same licence to it. Sounds weird but that's why it sometimes can be hard to "procure" software that is FOSS with regards to the risk mitigation we, the GC usually put in place due regarding limitation of liability and indemnification: too many IP owners to make it manageable. What would happen here is that a company would come in and say: I'll deal with the liability risks, you're good.

@keithdouglas Yes, we hope to have these reviewed by legal but this first round of open reviews will greatly help narrow down (hopefully):

• what needs to be pushed to requirements discussions;
• what is covered by the law (it's not open source if there's not an actual licence saying so, IP ownership in OSS projects);
• and what will stay in the guide

There's already been a ton of awesome feedback so really appreciate the discussion!

[ShadeWyrm]

Parts of these items were implemented, if any remaining items still need review - please open a new item to discuss. :)

As there have been changes to wording across the document on review by legal and other areas I'm marking this as closed.