Accelerate financial services firms’ journeys toward open source readiness, by advancing the readiness of participants’ firms and informing guidance for the broader industry in the form of white papers, presentations, and blog posts.
Proposal to create an InnerSource SIG working group around developing licenses, guidelines and templates for InnerSource banking software.
Currently, there are plenty of open source licenses (the 4 most popular being MIT, GPL2, Apache, GPL3)
The popularity of the licenses means people understand what can and cannot be done within the scope of these licenses.
A lot of effort is applied within a bank to communicate the boundaries of internal development. If there was a known set of InnerSource licenses, in the way there are for open source projects, communication would be easier.
Having a set of known InnerSource licenses would also be defensible in court. Assets in an InnerSource context need to be protected.
Working on a common InnerSource license will reduce the cost and effort of others implementing for themselves.
There are boundary conditions around open source and InnerSource that need to be met and there are differences between the two.
There are also different motivations between InnerSource and open source. Public recognition is there for open source and not for InnerSource. The responsibility for the product can be more within an enterprise context. The warranty might be different when sharing within the organization. Incentive mechanisms might be different.
Financial services companies also need to be regulator aware, which is different to non-regulated industries.
Clarity around internal contributor licensing agreements also needs to be understood.
InnerSource is a stepping stone towards open source, but there are some use cases where software should remain within the bank. InnerSource is still a great move forward though.
Currently, there is confusion around using a license for InnerSource: Attribution rules are different, warranty might not be "as-is", like most open source licenses.
There is a spectrum of license types from proprietary commercial, through freeware and restricted source to strong copyleft.
Ideally, the InnerSource SIG would create an a-la-carte style clause-picker, with human readable, machine readable and legal representations of the license. Like the creative commons type license.
Kick off meeting happening on 7th November within the FINOS InnerSource SIG. Everyone is welcome to participate and get involved. There is a cadence of every two weeks initially. Aiming for first draft license in May 2023.
Need to be aware of vendors on the contributing and consumption side. Throwing code over the wall and running away doesn’t work very well and needs to be mitigated.
Can the license also explain the software lifecycle of a project so you know the level of support that’s expected from an internal team. It would be good to know whether the project should be used or whether it’s experimental still.
If the lifecycle of the project isn’t handled by the project, the InnerSource community should still agree on a common lifecycle that explains the maturity of a project. Support contracts and warranties should also be included.
robmoffat
commented
1 year ago
InnerSource SIG Licensing Working Group
Proposal to create an InnerSource SIG working group around developing licenses, guidelines and templates for InnerSource banking software.
Currently, there are plenty of open source licenses (the 4 most popular being MIT, GPL2, Apache, GPL3)
The popularity of the licenses means people understand what can and cannot be done within the scope of these licenses.
A lot of effort is applied within a bank to communicate the boundaries of internal development. If there was a known set of InnerSource licenses, in the way there are for open source projects, communication would be easier.
Having a set of known InnerSource licenses would also be defensible in court. Assets in an InnerSource context need to be protected.
Working on a common InnerSource license will reduce the cost and effort of others implementing for themselves.
There are boundary conditions around open source and InnerSource that need to be met and there are differences between the two.
There are also different motivations between InnerSource and open source. Public recognition is there for open source and not for InnerSource. The responsibility for the product can be more within an enterprise context. The warranty might be different when sharing within the organization. Incentive mechanisms might be different.
Financial services companies also need to be regulator aware, which is different to non-regulated industries.
Clarity around internal contributor licensing agreements also needs to be understood.
InnerSource is a stepping stone towards open source, but there are some use cases where software should remain within the bank. InnerSource is still a great move forward though.
Currently, there is confusion around using a license for InnerSource: Attribution rules are different, warranty might not be "as-is", like most open source licenses.
There is a spectrum of license types from proprietary commercial, through freeware and restricted source to strong copyleft.
Ideally, the InnerSource SIG would create an a-la-carte style clause-picker, with human readable, machine readable and legal representations of the license. Like the creative commons type license.
Kick off meeting happening on 7th November within the FINOS InnerSource SIG. Everyone is welcome to participate and get involved. There is a cadence of every two weeks initially. Aiming for first draft license in May 2023.
Need to be aware of vendors on the contributing and consumption side. Throwing code over the wall and running away doesn’t work very well and needs to be mitigated.
Can the license also explain the software lifecycle of a project so you know the level of support that’s expected from an internal team. It would be good to know whether the project should be used or whether it’s experimental still.
If the lifecycle of the project isn’t handled by the project, the InnerSource community should still agree on a common lifecycle that explains the maturity of a project. Support contracts and warranties should also be included.