Adobe, as a company, sells authoring tools. It doesn't make money building runtimes and then giving them away. Even the money from licensing runtimes (Air) is insignificant. The runtime was just a necessary overhead due to inconsistent and poor native rendering capabilities in the browser - it existed solely to allow the development of powerful authoring tools.
So after browsers improved their native support and announced they are dropping support for the plugin, Adobe migrated to a new version of the authoring tools (Adobe Animate) that can compile to the legacy flash player runtime if needed, but also to html/js, or svg, or other targets.
They still want to sell more of the authoring tools. They don't particularly care about flash, and are probably happy to be rid of it.
What they don't want is someone else taking control over the runtime and then building rival authoring tools for it, opening it up to other authoring tools, or creating any kind of rival authoring eco-system.
It's like if you give away razors to sell your own blades, and then you come up with razor 2.0, you still don't want people taking the razor 1.0 and keeping it alive by selling their own blades for it, or even giving away their own blades for it, as then you would be in competition with yourself.
Whether these business concerns are justified or not, or whether our IP laws are too extreme, is a separate question. These aren't simple questions.
In other words Flash likely isn't some isolated directory they can just zip and share to the world, and even if it is they might want to pick the bones later so why throw it away? (from their perspective)
I'm somewhat hopeful that Ruffle will somehow drive its resurgence. Older versions of Flash (the authoring software) aren't that hard to find, and maybe in due time someone would even build an open-source reimplementation of that, too. The SWF format itself definitely won't ever be dead by any means.
Ruffle is open source and works. See: https://ruffle.rs/
What is missing that Ruffle doesn't cover?
It'll get there eventually of course as it's very much WIP. I wonder when will it stop calling itself a "flash player emulator" tho. It plays flash files. It's literally a flash player.
This, in particular, is limited by manpower and reverse engineering. Simply documenting what Flash actually does would be a huge help. Volunteers welcome.
Rendering flash requires that you be pixel compatible to something that is not documented anywhere. That requires someone to do a lot of experiments on something that barely runs anywhere anymore, document what they find, and then have someone convert that into code.
As for Actionscript 3, here is the tracking issue: https://github.com/ruffle-rs/ruffle/issues/1368
But as soon as there was any interactivity, e.g. random game from Kongregate (e.g. https://www.kongregate.com/games/moonkey/hexiom-connect or https://www.kongregate.com/games/kajika/planet-defender) ruffle just didn't do much other than hang at the loading screen.
My own personal use case for flash is to access baseboard management interfaces on servers. e.g. the Cisco UCS220B3 series uses a flash based interface. No dice with ruffle. It can do the login form and that's all there is.
Networking is the one thing that can't be fully reproduced by using a wasm thing vs a browser plugin, requiring changes on the receiving side. Flash player did cross-origin security quite differently. When you sent the first request to a new origin, it would first fetch /crossdomain.xml from that domain to see if you're allowed to do that, and only then proceed. Browsers rely on the Access-Control-Allow-Origin header instead. Then there are sockets, for Flash it's mostly the same idea: you could specify an arbitrary host and TCP domain, then Flash player would connect to it itself and send the string "<policy-file-request/>". The server is supposed to respond with the contents of a crossdomain.xml and close the connection. Flash would then connect again and this time hand over the socket to your code. Websockets don't work anything like that; you get one by upgrading an existing HTTP connection, and you can't have that on an arbitrary port either, and there's mandatory encryption.
With that said why the hell would a company pay for this when there a good OSS alternative. Is it all about support and covering your ass from any lawsuits?
ruffle.rs is a reimplementation, and YMMV, but none of the things I tried playing with it worked properly (although afaik plenty other things do) and still in active development.
The source code does sometimes "accidentally" leak, though.
May instead of a graphics engine, it's a proprietary video codec, or a bytecode interpreter, or a network stack, or a sound library.
Things like these are a big reason lots of projects aren't released as FOSS. Take something that looks simple on the outside, rip out its guts, and you're left with what exactly?
Flash Video FLV files usually contain material encoded with codecs following the Sorenson Spark or VP6 video compression formats. As of 2010 public releases of Flash Player (collaboration between Adobe Systems and MainConcept) also support H.264 video and HE-AAC audio.[3] All of these compression formats are restricted by patents. - Wikipedia’s page on FLV, the video format that YouTube was built around.
Not directly, but if someone were to use some of that code that a company put significant resources into developing, in a product that made someone else money, most companies would probably have a hard time mentally justifying that.
Interesting — I just checked the standalone flash player I still have (and use sometimes), the "about" window doesn't list any free software. So either they aren't using any, or... But I find it unlikely that a company with this many lawyers would not read every letter of the license of every library they include in any of their projects.