open-source-readiness
open-source-readiness copied to clipboard
finos
19 03 2025 - Open Source Readiness Meeting Agenda
Date
20250319
Untracked attendees
- Fullname, Affiliation, (optional) GitHub username
- ...
Meeting notices
-
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
-
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
-
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact [email protected] with any questions.
-
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
Agenda
- [x] Convene & roll call (5mins)
- [x] Display FINOS Antitrust Policy summary slide
- [x] Review Meeting Notices (see above)
- [x] Approve past meeting minutes
- [x] Introduce New Joiners
- [x] Peter - Patents Article
- [x] Tabea - Minimum Viable Process
- [ ] AOB, Q&A & Adjourn (5mins)
Decisions Made
- [ ] Decision 1
- [ ] Decision 2
- [ ] ...
Action Items
- [ ] Action 1
- [ ] Action 2
- [ ] ...
Zoom Details
- https://zoom.us/j/93808780892
- Meeting ID: 938 0878 0892
- Passcode: 358724
Join by Phone
- Find your local number: https://zoom.us/u/adl5rhui4P
Minutes
Peter's Article
https://github.com/finos/open-source-readiness/issues/208#issuecomment-2629105294
- LD: Is it important to create global patents? Often, the idea isn't innovative anymore. (Unnecessary bureaucratic overhead for no benefit.
- PS: Yeah, can take two years to get one. Which is a lifetime in software development. You can open source and patent at the same time.
- TH: A trading algo becomes less valuable when you open source it. Why is this an example?
- PS: MS have open sourced a lot of things. Some things get open sourced - trading algorithms, programming languages, etc.
- PS: MS bought a company called ETrade. Sometimes crowd sourcing can help. Meme coins, GameStop etc. Often work better with a crowd. Starting to open source some algorithms then they can use these on ETrade.
- AM: Algorithms actually aren't patentable.
- PS: Yes, that needs correcting. @psmulovics
- AM: We can add a disclaimer to say this depends on jurisdiction. In US it might be, EU it isn't. There is often a way to break a project into patentable and open parts. OpenAI have patented some things and open-sourced others. This would be a good example. @AmolMeshram19
- CS: I joined late, but I wanted to know what other folks were doing about the problem of open source patenting? For example, do we say, "anything AI we want to patent, anything infra we don't?". What is the process at other firms?
- AM: (Personal Opinion): Minor features, bug fixes, we don't want to bother. It has to be significant and non-obvious otherwise it'll get rejected.
- CS: We patent certain open source code. We categorise into buckets. I was interested to find out if other firms do this. We want to not slow down innovation, but have a process whereby the developers can opt out of patenting.
- CS: GS patented certain parts of Legend. JPMorgan payments, some of that is patented even though it's open sourced. I'm more concerned that we're tracking contributions correctly and we can extrapolate the value we're giving and getting.
- RM: My go-to is FDC3, where the founding firms "donated" their patents, or agreed not to litigate against one another over FDC3.
- RM: It would be good to link to some best practices around s/w projects with patents @psmulovics
- PS: There are lots of small companies that can benefit from this knowledge, and understand how they can use open source and also benefit from patents.
- TH: There is an interesting relationship between patenting and licensing. e.g. Pushback on Hashicorp around the Business Source License. (BSL).
- RM: Yes, some licenses make it easier to handle patents. e.g. Community Specification License (CSL) which we use for FDC3.
- AM: And in Microsoft License as well, there is an example of this @AmolMeshram19
- PS: The React license also has some stuff about this. (If you're a startup, don't use this).
- TH: The community might push back if you patent and open source. e.g. Coinbase patented some cryptographic technique for their UX. Security features and UX features sometimes get patented.
- PS: I'll put this in a Google Doc and we can work on an updated version. @psmulovics
Minimum Viable Open Source Process
-
Training
-
Onboarding
-
Access to certain projects
-
Registering GitHub handle with the firm.
-
Addition of users to CLAs
-
Registering outside/personal projects with the OSPO.
-
License/Security Scanning for new contribution projects
-
DLP Review
-
AI Code review: - AM: confirm code is not AI generated or copied
-
Hosting of OSS: Check sanctions etc.
-
Demonstrating ROI
-
TH: Supply Chain Security Attacks - is it safe to run tests / the code?
-
CS: Its important to know if a member of staff became a "bad actor" during their period of employment
-
TH: Are they a bad actor for the company they work for or the whole OSS community.
-
KW: One-off bug fixes may require less process vs a longer-term contribution
@tabea0211
Made the content of the Patent article available for commenting/editing at https://docs.google.com/document/d/12MaxyffgNtyr5MgdMR0Pxd8gZMdoriW5ru4nAsWmpcQ/edit?usp=sharing
https://www.finos.org/blog/open-source-and-patents-complementary-tools-for-innovation - see the mail thread with you
Minimum Viable Open Source Process
- Training
- Onboarding (Personal user name linked to company Github, enabling GitProxy inside your enterprise).
- Access to certain projects
- Registering GitHub handle with the firm.
- Addition of users to CLAs
- Registering outside/personal projects with the OSPO.
- License/Security Scanning for new contribution projects (OpenSSF Scorecard, Involvement of risk partners, Permissive License, LGPL Licenses, OSI, TLDR Legal, Openchain)
- DLP Review
- Offboarding (Who to remove from the list?)
- AI Code review: - AM: confirm code is not AI generated or copied
- Hosting of OSS: Check sanctions etc.
- Demonstrating ROI
- TH: Supply Chain Security Attacks - is it safe to run tests / the code?
- CS: Its important to know if a member of staff became a "bad actor" during their period of employment
- TH: Are they a bad actor for the company they work for or the whole OSS community.
- KW: One-off bug fixes may require less process vs a longer-term contribution
https://osr.finos.org/docs/bok/Certifications/FSOSD https://osr.finos.org/docs/osr-resources/Training /todogroup.org https://openchainproject.org/ https://baseline.openssf.org https://github.com/ossf/scorecard