2019-06-05 OSR WG Meeting Notes
Meeting minutes status: Approved (on 2019/07/24)
Table of Contents
Date/Time
6/5/2019 10AM EST
Attendees
| Name | Organization | Github ID |
|---|---|---|
| FINOS | ||
| Rob Underwood (Deactivated) | FINOS | brooklynrob |
| Aitana Myohl | FINOS | |
| Andrew Aitken | wipro | |
| Brian Ingenito (Deactivated) | Morgan Stanley | |
| Colin Eberhardt | Scott Logic | |
| Gaurav Parakh | WiPro | |
| Gilles Gravier | wipro | |
| Hershal Shah (Deactivated) | IHS Markit | |
| Jim Jagielski | Consensys? | |
| Rich Heironimus | Freddie Mac | |
| Simon Holt | JPMC | |
| Sally Ellard | Deutsche Bank | |
| Aaron Griswold | FINOS | |
| Adam Batkin | AQR |
Agenda
| Time | Item | Who | Notes from the Meeting |
|---|---|---|---|
| 5 min | Convene & roll call | ||
| 50 min | Contribution considerations | Aaron Williamson and Simon Holt | This discussion focused on the strategic considerations that go into a firm's decision to contribute to an open source project or establish one, with the following list of topics (suggested by Simon) as a framework. (Notes reflect comments made by various participants.) Topics covered
It's better for a company to host its own project if it's one with significant reputational impact, because it can ensure the quality of the code and that it won't go stagnant. If it's critical that the project attract collaborators, an independent foundation is a better choice. Another important consideration is whether a project is "generic" enough in its utility to be useful to other firms. Attracting outside users & contributors is not the only reason to open source something. For example, a consultancy may wish to showcase its abilities. Companies should ask: How will this benefit the community? What is the problem it is solving? And what are the benefits to the company of open sourcing it? It's important to have as strong an internal business rational for open sourcing the code as possible. It's hard to build a vibrant open source community, so it's critical that you have the backing and resources to bring it up to speed.
If a project is close to the core business of a financial services firm, they should be circumspect about whether open sourcing it will cut into their core business. But there are easier cases, such as a good idea re: technology infrastructure -- if your solution is first out of the gate and you can build a community around it, it will be easier to maintain. With a solution to a common pain point, e.g. managing containers, keeping the project internal may have short-term benefits. But if it solves a problem everyone has to deal with, the industry will eventually standardize around some solution. It's better for you if it's the one you're already using. The salient question is, should it be standardized? If the answer is yes, someone will.
It's not clear that many financial services firms are thinking strategically about why they're acquiring patents and what they're using them for. If it's just a measure of "innovation" or value, or they're for defensive purposes, there's less of a barrier to open sourcing code that embodies the patents. You need to take into account the identity of your firm and where your value is. Our firm has a committee that looks at this. We try to ask that question at the time a project is being considered for open source contribution: is it patentable? If no, then clear it. We try to avoid bringing the issue up to IP counsel unless it clears that first check. How would you assess whether something is patentable? SH: We ask, is that a unique idea or just enhancing the state of the art? If it's a new idea, we'll do a review with IP counsel. It depends on the culture within the company. In some, patents are a goal to be attained and a measure of productivity; in others, they're not important so you don't get them. For firms that patent software partly for defensive purposes, consider looking into the OpenInventionNetwork and the LOT Network, both of which are patent cross-licensing organizations that create patent peace around technology (OIN focuses on open source in particular).
We run into licenses with restrictions that are incompatible with our use. Field-of-use restrictions aren't permitted in true open source licenses. That's true, but there are a lot of packages on NPM and a lot of projects on GitHub that will appear "open source" to a developer while having license restrictions that are incompatible with the open source definition. Are there actual examples of non-open-source software getting embedded in open source? Yes, it happens often, particularly when you're consuming open source at scale. There was a legal case involving an insurance company selling software that it believed to be open source but also included proprietary software. It's necessary to do code scanning to identify these issues. There are both commercial and open source solutions available.
|
| 5 min | Any other business & adjournment |
Decisions Made
N/A
Action Items
- Sally E. to talk to Plexus Interop product manager about presenting DB's experience open sourcing it
Need help? Email help@finos.org we'll get back to you.
Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.