That’s if you use their code, but that’s separate from using their programming language. Like how you can’t (practically speaking) sell the GNU C compiler, but you can write your own compiler for the same C language and sell that.
4 Likes
I’m in the same boat. I have Chrome installed for just such occasions too.
The dust has settled in the browser wars a bit, but not through a respect for standards, but of simple market dominance. I wonder if Safari is next on the chopping block. I mean, Edge is Chrome under the hood. Safari might do the same thing.
I haven’t looked at that logo for a long time, but it was the humble beginnings of Mozilla.
I actually just have Firefox on my main machine running Linux.
It doesn’t happen a lot, because I’ve learned to avoid sites like that. When I can’t avoid it, I break out my seldom used Macbook with Chrome. I will not run any closed source software on my main machine. I keep the Macbook on a separate network along with any other devices I don’t fully trust.
2 Likes
Another possible downside to an IF platform using web tech beyond browser compatibility quirks is future-proofing, or rather the lack of it. The web is ridiculously unstable in that regard. Trying to keep a complex site working and looking the same even in the short run is real work. While an IF platform on top of the web lifts some of that responsibility from the game author to the platform author (just like a VM would), I’d wager the abstraction is much leakier. Stating a game made for the web will look identical twenty or thirty years later would be quite an impressive (and dubious) claim.
2 Likes
Very true. I hope, with the amount of content online, that browsers would have an “archaic mode” for old websites.
The only compliment I’ll give to Microsoft is that their bloated software is ridiculously backwards compatible (not perfect, obviously) spanning decades.
I think this is one of those areas where it’s legally a bit fuzzy? I mean, the big US case on a related topic that resolved recently was Google v. Oracle, which established that APIs are copyrightable, but that Google’s re-implementation of Java SE (using the same API and re-using some of the declaring code) was fair use. So that seems to lean in favour of it being probably fine to write your own choicescript implementation, but on a bit shakier ground than if the court had ruled that APIs are not copyrightable. And that’s about a library API, not the programming language itself, but it feels to me (note: not a lawyer) like they should be similar?
1 Like
Which should go down in history as one of the most batshit-insane decisions of all time.
An API is NOT a creative work. It is an interface, a shape of interoperability, like the slots on a bike rack. It’s crap like this that has led to the enshittification of everything.
6 Likes
An API is NOT a creative work.
As some who is working on a JavaScript API for Interactive Fiction, I have to say the development of it definitely feels creative.
1 Like
As someone who’s designed many an API, it can definitely be a lot of work.
A particular implementation can even be creative, but an API itself - no. It’s a shape that only exists to facilitate interoperability, purely functional.
2 Likes
Maybe we’re using the words differently, but designing how a user will interact with a system involves many decisions, just as designing how and where a player will interact with the story world does.
1 Like
Maybe there’s a miscommunication about the code base and the API?
I’m talking about what to expose to the user and how. For example, is going to be more high level or low level. What will be the default behavior when there are missing arguments. Which functions will you expose and how? Will you use a fluent interface and if so what are you naming the individual functions that make up the expressions?
1 Like
To stretch an analogy to the breaking point:
Someone creates the world’s first bike rack. It has slots the right size for bike wheels to sit in so they can be parked. Before this point no one had ever thought to make something people could park bikes at. That person definitely created something. But there’s a difference between someone copying that bike rack’s design versus building their own completely unique bike rack that has compatible wheel slots. The rack is a creative work, the slots aren’t.
In code, designing an API is obviously quite a bit more complicated than designing a wheel slot, involving lots of decisions and tradeoffs, but the end result (the abstract API, not the software implementation of it) is still purely functional and should not be subject to copyright. Unfortunately, courts keep pushing copyright overreach further and further.
3 Likes
I agree that it shouldn’t be copyrightable, but not because it’s pure functional, like a telephone book, but because ideas in and of themselves aren’t copyrightable. So as the oft sited example goes, you can’t copyright the idea of a Monopoly game, but the printed rules and board design can be.
2 Likes
I’m not a lawyer, but there is mention in U.S. copyright law regarding the functional/utilitarian aspects of a work not being copyrightable.
I agree with that; what I’m saying is that it’s also not copyrightable because of the aspect that is basically the idea of the interface is also not copyrightable. I guess what I took issue with was the concept that designing an API is not a creative undertaking because it certainly feels like it when I do it. Maybe you were saying that documentation of an API is not copyrightable because it’s like a telephone book and I agree with that.
2 Likes
I think we mostly agree.
Designing an API is hard. It requires a lot of thought and careful planning, but I’d make a distinction between that and creativity. It can be difficult to mentally separate the API from the implementation when designing the API while simultaneously implementing it.
Yes, and that should imply that someone making a product that uses an identical API in order to facilitate interoperability should not be subject to copyright claims, so long as they don’t copy the actual implementation (with additonal exceptions for cases where there is only one logical implementation possible).
I guess we differ in the definition of creativity. I tend to include anything that involves making decisions which have no clear cut right answer.
Off the top of my head: Early this year I was looking for a new job. Many company job application sites (for software development no less) were incredibly broken on firefox. My doctor belongs to a group of physicians and their portal doesn’t work in firefox. A retirement fund from a former employer doesn’t work either.
They’re decent, but they are sandboxing some of the most complicated code in existence. Looking at browser CVE’s, improvements have been made in some areas, but browsers continue to be plagued by security problems with no reason to believe anything will change before the heat death of the universe. Couple that with much web ‘innovation’ being driven by the giant conflict-of-interest called Google and my response is…turn off javascript when possible and run your browser from a VM that doesn’t persist state when turned off. Even then, don’t use Chrome or Edge unless it’s absolutely unavoidable.
Ha! 
I was thinking about Electron or NW.js. I guess I need to be more explicit.
Thanks for the Tauri recommendation! 