Around the time of Horizon Online appearing in 2010 (not original pre-2k Horizon), the UK government, also the sole shareholder of the Post Office, was at the cutting edge of bringing open source into public procurement and increasing technical transparency.

What surprises me is that, at this point, there is very little questioning of whether single-purpose government contract closed source is automatically the right choice - there's a case for open and for closed, but Github is a lot easier to access for an expert witness. While there were also issues with the reference data, it is hard to think of a starker example of why having access for third-parties, even just to the code, matters (yes ironic, but did a Medium article few days back if anyone wants some more context links for this point).

This has become my go-to answer to "whether government money means public code only impacts technical people".

A few years back, I created a set of libs to provide this in Gnome Terminal. Not the most elegant solution but it allowed SVG to be rendered into the terminal and so, once the custom libvte was installed then gnome-terminal would support overlays like a miniview for vim (only requiring a vim plugin), ability to print image files to the terminal, matplotlib graphs for system monitoring, etc. I even had partial tmux multiplexing support and passthrough for SSH.

Naturally, there was a lot of work to do going forward to make a stable production tool - for example, if a program can write arbitrary images to your terminal it can mislead you in ways a normal console program couldn't, but equally usage/security issues like that were not necessarily _that_ far from what you could already do, and these were not unsolvable problems. Compatibility-wise, anything that could output SVG as text could manage the simple protocol, and I'd client libs for Python so it was a little like ncurses usage (in fact, one example uses ncurses and gasket).

After a while I realised that the general response was "Nice novelty - shrug" so rather than keeping maintaining or improving a fork of libvte, I stopped. That was 8 years ago - now I still miss my miniview in vim :/

Re-reading the article, I now think it's just a handy definition of what an API is, not specific to the case. Think that is effectively what the ACs who disagreed above are saying too.

I've tweeted Bloomberg Technology to suggest it's clarified, especially as it sounds a bit like Google have stolen a big, functioning bit of software and for some reason they're refusing to pay up (maybe that was debated in an earlier component of the case, IIRC, but not the current issue). In particular, that's the only bit of the article I can see with any technical explanation of what happened, so it's hard to come away thinking "yes, I can see Google's point", which is unlike most write-ups I've seen to date.

Have I completely misunderstood this case or has Bloomberg?

Agreed - developers conflating Open Source (OSI compliant) and proprietary licenses, including "non-commercial", causes wide-ranging problems. Not suggesting CopperheadOS do this, only a number of previous commenters

1. Developers including open source code, to later find out that they have just sunk their company's product. Even with GPL, you can look at becoming compliant. Here, that means winding up your company
   • My Github code is MIT licensed, use for your project! (By the way, I built it on another MIT licensed project - turns out it wasn't, sorry, but a random third-party developer now wants damages from your employer). Lot less likely when upstream doesn't stick source-available non-OSS project on Github with an MIT license. Looking at you, HoverCSS.
2. It's anticompetitive, which is fine, but pretends to be collaborative, which isn't. Open source works because it's a clear concept, with interpretations all following some basic principles. NC doesn't. If Android was source-available there would be no CopperheadOS.
3. It feeds FUD. Building on open source doesn't automatically destroy your business. But using this would.
4. It perpetuates the "Open Source is anti-commercial" myth. Not convinced? Read the comments above. That makes it far harder for those of us running businesses making (and selling) commercial open source products to challenge those assumptions (and so survive commercially).
5. It's far harder to prove non-derivation of your own code from source-available than closed source you haven't had access to.

Summary order of preference:

1. Open source
2. Source-available proprietary
3. Closed proprietary
4. Being delivered a trained parrot and monkey who alone may interact with the software on my behalf
5. Either 2 or 3 pretending to be 1.

First was Howl's moving castle: http://www.onlineghibli.com/howls_castle/. Finding out later that Howl was from Wales was a bit of a surprise, but I guess they have the world's most castles per capita, so if there's a moving one anywhere...

Although Spirited Away had the edge, for me.

It's a little unclear what is official response, what is somebody else's response (e.g. "For the record, I am not a member..." doesn't suggest an authoritative source) and what is actually required. In fairness to them, the major objection in the article is over UNetBootIn - Geza Kovacs (the upstream author) has kindly posted in the comments section: "They seem to have simply followed my instructions for customization [...] so I don't mind."

Lack of responsiveness would obviously be an issue, and one that's easy to confirm, so maybe a big statement in the article saying "I made formal contact directly a week ago and heard nothing back" would have been a good first step to answer "Is this a blatant disregard for the GPL and Apache licenses by an optimistic startup, or were the authors too eager to release that they forgot to provide access to the repo?"

Having touch-typed for a fair time and diligently done my RSA courses back at school, I match fingers to keys pretty consistently. However, looking at this question made me spot a couple things and now I want to know if they're common for formal-ish typists too...

1. Pinky never hits the top row. A, Z, ", |, / [en-us], that's it.
2. 6 always left index, Y always right index EXCEPT when index finger just used on bottom row, then (unconsciously) middle finger: e.g. V6, any, my, BT.

I get neither of these are particularly odd in themselves, but it is more that I have been doing this for over fifteen years, recognising only two or three letter combinations and mentally remapping, but never once noticed.

And typing this is a bit like listening to yourself breathing. It's actually going to drive me crazy.

Swapping Caps and Escape has changed my life to the extent I would consider carrying little stickers around for all the keyboards I remap. Unsurprisingly, I'm a fairly heavy vim user, but I believe this is an increasing trend, especially on Mac.

As vi was written on an ADM-3A, which had Esc in the currently common Tab location, the notoriously heavy use of Esc in vim makes sense. However, swapping with Caps makes it reachable from the home position - initially skeptical, I only realised how much of a difference it makes when I tried to switch back...

On Gnome 3, I have recently switched from using xmodmap to setting org.desktop.gnome.input-sources.xkb-options to ['caps:swapescape'] in dconf-editor. Much easier.

Agreed - I find that with Laravel, I can practically sneeze a (development) mock-up. With a bit of practice, it can be kept clean, conceptually reproducing relationships described by the client, easy to unit (and acceptance) test and, for moderately simple websites, extended smoothly to what you ultimately want. With the foundations nailed down, you can spend your time drawing up your HTML/CSS layout in the views and enjoy concise snippets for dropping in object properties and looping over items. I admit, I am more of a developer, but I would say Laravel would be a great choice for a designer who wants to get power without spending all their time in PHP.

More importantly, from the OPs perspective, if you know some PHP and understand OOP, it is slimline enough to dip in and out of the libraries to see what's going on. But for anything fairly standard you don't need to, because there is adequate documentation and reference websites such as the excellent Laracasts or tutorial sites, such as, for the more adventurous, Culttt. No deep hidden binary blobs, as in some commercial libraries, or spaghetti bowl of indecipherable ramblings, as can happen organically in some PHP projects, but plenty of power and extensible neatly through (as the parent pointed out) composer.

Could this requirement maybe be extended to large vendor zero-day vulns?

Just imagine a world where the only zeroes weren't in the second or third digits of the days-to-patch.