May 2nd Banks-Only Round Table

[robmoffat]

FINOS invites you to a FINOS Banks Only Open Source roundtable that's taking place to coincide with the FINOS BMO Hackathon in NYC on 3/4 May. Location in person in New York and virtually on Zoom. Zoom will be provided for international guests.

The roundtable will take place under Chatham House Rule, meaning participants are free to use the information received during the roundtable, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, will be revealed.

Also, in the essence of openness, anonymised content from the roundtable could be repurposed for use within Open Source Readiness. The content will be published by the FINOS team and will exclude the participant's details under Chatham House Rule.

Zoom Meeting:
https://zoom.us/j/96997289605?pwd=c0FHKy9jMTViNlJMVzBQYXIxVDc4QT09

[robmoffat]

1. Training Courses: What are your requirements for training? (Developer / OSPO?)

[robmoffat]

2. DLP: There are multiple strategies, different firms are using different ones. Can we get a review of what banks are doing what? Bluecoat ? Git-proxy?

[robmoffat]

3. License management: do people approve a bunch of licenses? Do they use GitHub’s choose-a-license categorisation mechanism.

[robmoffat]

4. Personas - based on Cara’s work on personas, more time workshopping this? Maybe divide into groups and add detail.

[robmoffat]

Based on the votes we have, we'll do a deep-dive on License Management in the round table and then tackle Training Courses in the following SIG meeting.

[robmoffat]

May 2nd Roundtable: Licenses, CLAs, DCOs

RM walked the roundtable through the existing documentation on the website. The roundtable is held under Chatham House rule, so the following comments are unattributed

Categorizing Licenses

• We’ve touched on some aspects of licensing here. There are plenty of dimensions to this, such as internal vs external, dimensions people use.
• FINOS has done some work on documenting these here https://github.com/finos/OSLC-handbook by Jilayne Lovejoy.
• FINOS dividing into category A,B, X - it often depends on context - are you going to redistribute the code. Often, the X licenses are only a problem when you distribute.
• The elephant in the room with this is often libraries working on PDFs, which have their own weird licenses.
• At (bank), we took an initial seed of FINOS licenses in JSON/markdown (see above project) and used this as a basis.
• We have 9 assessments for a new license to see if it can be used.

What tools do you use for (license management)?

• We use Waltz to do this categorization. We use SBOMs from Artifactory too, JFrog XRay. At the moment, we’re not really enforcing compliance, just monitoring it so far.
• We use Black Duck scans, approved inventories and internal Artifactory. We have dependency management tools.
• There’s a danger with these tools that they might return too much (providing license details on every demo file) or might not find everything (false positives, false negatives)
• In our org, we have an internal tooling system. When a developer wants to consume a piece of code with a given license, that triggers a legal review . The OSPO supports developers through this.

Checking License Compatibility

• It might be possible to check license compatibility using the License Chooser software (as demo’d by Chamidra from Inner Source group)
• It allows you to understand licenses in terms of what attributes they offer, and therefore you could figure out incompatible attributes
• Where a bank spins up a new business, Inner Source licenses could become important.

Consumption and Contribution

• We have to be careful to separate these two things. For contribution, we approve certain licenses for certain scenarios.
• We could develop policy around contribution RIGO that could be consistent across organisations. Distribution is the problem for licensing.
• For us, contribution is quite minor at the moment so we’ve not thought about codifying it yet. We want to understand usage.
• Sometimes, you might end up contributing to a project with an odd license where you actually have to provide support.
• GitHub’s choose-a-license is based on various attributes. You could have a policy engine based on those attributes, broadly speaking.

Visibility of Open Source

• How do other groups drive open source visibility? How do you get more people contributing?
• Right now, we listen to what people want and support that. These requests form a backlog.
• We have support at the top tier, but we’re now needing to look at engaging the lower levels.
• Yes, it’s different to cloud - you can’t just tell people they must do Open Source. For some people, contribution might have a stigma attached to it.
• I think we might be getting past that - bug fixes are obvious, but they’re not very meaningful.
• At (bank) we’ve rolled out a mandatory grass-roots training course to normalize open source culture at our firm. New Hires now know how to bug fix. We make sure they understand and have the tools to do this. We’ve done conferences. We do newsletters and deep dives.
• Has anyone tried getting an all-star Open Source programmer/pioneer to speak?
• Recognition is a great booster for internal staff.

CLA Tooling

• EasyCLA now has an API for doing CLA onboarding/off-boarding. FINOS wants to publicise this more widely and get other organisations adopting it.