Comment by cstross
5 years ago
This immediately sprang out at me:
> Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out.
I wonder how well this plays with the various open source software licenses?
That's actually an unfortunate side-effect of banks having weird requirements. When I was at GS we had this enormous source repo built on CVS. So we made improvements to CVS to try to make this more manageable . For example because branching in CVS absolutely sucks we had to use tags (rather than branches) to identify releases. This meant you end up with lots of tags and when you look at them it's really hard to find (visually) whether code has a particular tag. So we patched CVS to sort the tags alphabetically. We tried to upstream this but the CVS devs didn't want to know. So we had to maintain it.
Likewise a bunch of fixes to the timezone handling code that iirc glibc simply wouldn't upstream so we had to maintain even though they were bugfixes.
We did used to upstream everything we could and I think the situation is improving.
Most licenses just require your users to have access to the source code. As all the users are bank employees, this is usually easily achieved. If the license is violated it's only by accidental oversight.
Pretty much everything described is a Python library not a change in the Python interpreter so can be under a proprietary license.
The spirit of open source is a different matter.
As I understand it from a legal point of view the user in this case is the bank, not individual employees running it on the bank's behalf, and the bank already has the code so it's a non-issue.
I know some people think this is contrary to the spirit of open source, but it isn't. One of the goals of open source is so that users can customise the code to their specific use case, with no obligation to share. That's all the banks are doing. They have the same rights as any other user.
This. Even RMS has said many times that a company is a single user/owner of said code, and it doesn't matter who works on it as long as it doesn't leave the company. It's all explained in the GPL but the gist is, if the company only uses it internally/doesn't try to sell the code, they can do whatever TF they want.
Quite well. You are under no obligation to commit back your changes under any OSI license. The old Sun CDDL required it, and was denied OSI "open sourceness" as a result.
As others have mentioned, it's fine, even with GPL, as the licences only really kick in when they try to distribute the software. They are only really hurting themselves. When starting a private fork you force yourself to maintain it alone. That means either letting it rot (ie. it becomes insecure and obsolete with no new libraries supporting it) or keeping up with the mainstream yourself. Either way it's a lot of work that wouldn't be necessary if they upstreamed their changes. Maybe one day they'll get the message. You'd think that long-term investors would understand this concept better.
what would be the implication wrt external banking services that use open source software? (echoes the cloud databases story...)
Are they distributing/selling the code? If the answer is no (and it pretty much always is) then there's no implications. Nothing in the GPL says you can't have a web front end to gather info that's then processed by your modified GPL code (which never leaves your possession) and the results spat back out to that web front-end.
Well, with GPL particularly but open source licenses more generally, the user is allowed to do whatever they want with the code. It is only when the code is redistributed that the source must be provided. With AGPL the source must be provided also to anyone using a service running AGPL licensed code.
So it plays perfectly with the licenses. This is the sort of thing free software was designed for, allowing everyone that uses a codebase to own it 100%.