Licensing issues around OSLib

I notice that OSLib uses a modified version of the GNU General Public License. http://ro-oslib.sourceforge.net/faq.html#license Given the self perpetuating nature of GNU licensing¹, could this cause a problem if used in code intended for eventual inclusion in RISC OS itself?

¹ I’ve heard that if you look into a mirror and say GNU General Public License five times, Richard Stallman will appear to seize your property and set your family to work on a collectivized farm.

According to the website, there is no licencing issue, because the stated exceptions exempt you from all the non-freedoms the plain GPL forces on you.

It’s a bit like the “GNAT Modified GPL” or the “GPL with Classpath Exception”.

<rant class="unhelpful"> Would have been better to use LGPL directly, rather than making a home-brew version of GPL. That’s what it’s for… </rant>

The existing “GPL with special exception” is more liberal (in a freedom sense, not in a GNU/Stallman sense of course) than LGPL, so it is a real advantage. The special exception clears up the legendary “don’t know what it really means on a non-Unix system”-underspecification of the (L)GPL.

I still think it wise to reimplement OSLib under a sensible licence. Saves any Gotchas further down the road as I would read using “GPL with special exception” as “GPL mumble mumble please don’t sue us”.

I have worried a little about that. If it is possible to redo it, it would be an opportunity to fix various mistakes/omissions. The system that puts it together could be really handy for other projects as well.

The system that puts it together could be really handy for other projects as well.

Not least a revised API. As a first step, all the legacy cruft and the nitty-gritty of SWI calls gets encapsulated into a library of clean ISA-independent functions. (OSLib already goes a long way to achieving this.) As a second step, these library functions become the de facto API for new code.

Does anyone here know Jonathan Coxhead? Unless he’s actually transferred his copyright to someone else, he’s at liberty to release it under a different license. (For GNU to have teeth, the copyright needs to be transferred to the Free Software Foundation or similar.)

Another point worth considering is that terms and conditions aren’t there for when everyone is getting along nicely. They’re there in case things turn nasty, and when lawyers get involved, in which case a home-brew license is a potential liability. What was intended by a particular wording, and what a court rules was intended can be two different things.

Does anyone here know Jonathan Coxhead? Unless he’s actually transferred his copyright to someone else, he’s at liberty to release it under a different license.

I would suggest that your first port of call should be the current OSLib maintainers, as they’ve worked on the project for many years and are likely to hold claim to at least some of the the copyright. Not to mention all of the contributors along the way.

I’m afraid that I’d err on the side of “if it ain’t broke” for the time being. The OSLib licence works, and it is used in many projects both Open and otherwise. The GPL aspect keeps the library code Open and free from abuse, whilst the exemption allows the result to be used to make pretty much anything else.

The other big question at present is: who is actively maintaining OSLib? There have been a few patches recently which haven’t made it into the repository, and I feel that this is a much bigger and more immediate concern than the ideological purity of the licence.

Could I suggest that the first thing to worry about is whether there are any maintainers who are still active on the platform and have the time to look after OSLib? Once that question has been sorted, then maybe look at the licence.

What the platform does not need is a fork of OSLib. By all means improve it without breaking backwards compatibility (and that can be done now, via the maintainers), but we don’t have enough developers to support two competing codebases.

I feel OSLib should be replaced with a new set of Bindings. Clean up the library, get a good license.

Why not? Let’s create yet another fork of something, yet another possible dependency and yet another project to go out of maintenance – taking with it any software that was developed around it.

ETA – for clarity, that last bit is sarcasm. Replacing OSLib just consigns a lot of work and useful code to the dustbin of under-resource.

I agree that replacing OSLib is a bad idea. (And that doing so for the sake of licence purity even more so.) However that doesn’t mean there isn’t a problem.

The other big question at present is: who is actively maintaining OSLib?

The SVN repo has the last commit from John Tytgat 2019-09-29, based on patches submitted by others. His last direct commit was 2015. I think it’s fair to say it’s not really maintained.

Other direct commits are from Tom Hughes and Tony van der Hoff. I don’t think it would be feasible to relicence it without tracking down all the contributors. That might not be so many people though.

I do like the idea of keeping OSLib as an API, and replacing the SWI-level stuff underneath it with something else. (Some kind of IPC perhaps)

Tony’s posting to the oslib-support mailing list over the weekend was he doesn’t think RISC OS is being updated any more, as he only had two patch requests from gerph in 2020. So perhaps someone should let him know, things are are still happening around here.

Is there any automated way of extracting the API changes from each release, so the information could be passed on to the oslib maintainers?

So perhaps someone should let him know, things are are still happening around here.

If you read my reply to Tony’s post, I did just that… :)

It’s worth noting that I’m not aware of much that isn’t already supported: there are a couple of bugs in the Wimp API (dating back to the RiscPC, so not new), but generally when I’ve looked for stuff, it’s there already. My query about active maintainers, which I’d been considering asking for a while, was only prompted by the lack of response to the patches from late 2019 and 2020.

I think that the amount of update / correction needed to OSLib anyway would be eased by a ground up reimplementation anyway.

So what is wrong with the current implementation? You imply that it’s massively broken, when experience of using it suggests that it very definitely isn’t.

So what is wrong with the current implementation? You imply that it’s massively broken, when experience of using it suggests that it very definitely isn’t.

Mr Murray must be busy at work or something as he’s usually fairly critical of OSLib.

Comments about slowness come to mind.

Me: A library with no books = bewilderment.

Comments about slowness are usually associated with _swix().

Mr Murray must be busy at work

Nah, was traumatising kitten (or being traumatised by kitten), then made mac-a-cheese for dinner, then watched two episodes of The Expanse. It’s what passes for “a life” around here.

as he’s usually fairly critical of OSLib.

I am? Well, I guess if preferring DeskLib (and the higher level abstractions) counts as critical…? I don’t use or need OSLib because DeskLib has a bunch of low level functions too, so I just use those.
I understand that OSLib has better parameter type safety.

BTW, Authentic Steve, are you sure you aren’t mixing up OSLib and the inconsistent s***show that is RISC_OSLib? ;-)

Me: A library with no books = bewilderment.

You do realise you’re pretty much channeling my mother there?

One of the few people I’ve met who didn’t need to look up the Dewey Decimal numbering, she knew it. She’d be like “oh, 867.5309, that’s the number for books about annoying pop songs that become memes”…

Comments about slowness are usually associated with _swix().

Now swix I am critical of. Programmer convenience in having tidier looking code (than setting up registers one by one) ends up burning a billion ¹ cycles undoing the mess, and redoing it again after the SWI call.

¹ Exaggeration, but only slightly.

Well, I guess if preferring DeskLib (and the higher level abstractions) counts as critical…?

Apples and pears. OSLib isn’t the library you use to code with; it’s what is used to write the library that you use to code with.

I don’t use or need OSLib because DeskLib has a bunch of low level functions too, so I just use those.

The problem, that I’ve found when working with DeskLib projects, is what happens when you hit the low-level stuff that it doesn’t have built-in support for… The point about OSLib is that it has a wrapper for every possible OS SWI and reason code combination, so there’s never* a need to resort to _kernel_swi() or _swix().

BTW, Authentic Steve, are you sure you aren’t mixing up OSLib and the inconsistent s***show that is RISC_OSLib? ;-)

Subtle, but yes I probably was.

You do realise you’re pretty much channeling my mother there?

That would be my feminine side then.

One of the few people I’ve met who didn’t need to look up the Dewey Decimal numbering, she knew it. She’d be like “oh, 867.5309, that’s the number for books about annoying pop songs that become memes”…

That set me thinking about whether they had re-arranged the books on the shelves of Aston Uni library since 1979, in which case I wouldn’t be able to walk straight to the inorganic chemistry texts.

Now swix I am critical of. Programmer convenience in having tidier looking code (than setting up registers one by one) ends up burning a billion 1 cycles undoing the mess, and redoing it again after the SWI call.

Could you actually write something more efficient that presented the same API though?

Could you actually write something more efficient that presented the same API though?

That’d need to be done as a compiler intrinsic

Given the looming disaster of ARM dropping 32-bit support, the speed of an API that isn’t inexorably tied to it is fairly inconsequential. And anyway, it will still run faster on a Raspberry Pi than on any hardware Acorn ever produced.

Given the looming disaster of ARM dropping 32-bit support

;) That makes me want to run to the hills, run for your life. We’re all Doomed! It creates a challenge and good reason to donate to the bounties. Join in, write some code, update the wiki, …

Is there any automated way of extracting the API changes from each release, so the information could be passed on to the oslib maintainers?

Maybe checkout the before and after versions, make export both, then diff the resulting Export directories?