Any updates about RiscOS on the Raspberry Pi?

even the most pedantic critic should find nothing to which he can take exception

Okay. I guess you and I have somewhat differing concepts of what “App Store” means.

Just be sure not to call your App Store an App Store. It is one of the many “devices” that Apple somehow thinks it has exclusive rights to. Yes, that Apple. The one with the hyperactive lawyers and the rounded corners.

On a slightly more constructive note:

If you present a list of web links for free software and the user clicks on one to download it and the software then opens it and installs it

If the download repository is somewhere central, then it’s back to ask-for-permission time.
If the download of each package is from the author’s own site, then you could be setting yourself up for a mountain of work. I’ll give you an example – my software encodes the version into the filename, such as “Meh_0-01.zip”. The next version would be something like “Meh_0-02.zip” (I use RISC OS style version numbering, and loathe Unix style with a passion). Anyway, when a new version is released, generally the older version is no longer linked. Whether or not the actual file itself remains usually depends upon whether or not an important bug was fixed. If there was a doozy of a cock-up in v0.01, then it would be removed entirely so there’d be no chance of somebody downloading it by mistake from my site.
Which means, if you set up a listing of useful apps, you will need to keep an eye on what versions of things are available. Some sites may have machine-readable information (for example http://www.heyrick.co.uk/software/swidx.txt) but there’s no guarantee it’ll be a standard format. For your App Store not to become outdated too rapidly/frequently, you might need to keep a close eye on these sorts of things.

Or you could just ask permission as we’ve been suggesting, then roll a distro in the usual way. It’s a lot less bother that way.

(and ROOL, who remain silent on how they are involved with this distribution)

Steve’s been on holiday for the past couple of weeks (due back in the next day or two, I think?). Ben’s also away at the moment – perhaps due back sometime next week, I’m not sure. So just because someone’s being silent, it doesn’t mean that they’re deliberately ignoring you!

Although I can’t speak on ROOL’s behalf, I’m fairly certain that they weren’t expecting the software licences to be mismanaged in the way they have, and that this wasn’t what they had in mind when they endorsed Chris’s distribution.

If the download repository is somewhere central,

The web links would have to be the existing place where the software is hosted, naturally. The ‘appplication emporium’ software would just know where to put everything inside the zip file that gets downloaded and, crucially, the ‘software supermarket’ would be able to update itself as things changed.

then even the most pedantic critic should find nothing to which he can take exception.

The reason for saying this is that it has been carefully arranged so that it complies. Critics need to be pedantic if providing useful comment. However I should have said ‘nothing to which he can take exception in terms of licence compliance (rather than just personal feelings)’.

Or you could just ask permission as we’ve been suggesting, then roll a distro in the usual way. It’s a lot less bother that way.

Yes. However I was placed in a rather odd position – six months ago an initiative was started (by someone else, again on behalf of ROOL) to ask for such permission on ‘likely software’ but it had made little progress (very few items had got to a definite Yes or No) and it appeared to me that contacting authors was therefore going to be difficult to achieve. I am still trying to find e-mail address for hipposoft and jeff drobe (their web sites don’t seem to have a ‘contact’ button).

I’d like to take this opportunity to apologise for the shortcomings in the process for officially contacting authors. Thanks, and sorry again.

Thanks, Trevor, but that’s utterly worthless if Chris is going to continue claiming that he can’t see anything wrong with his actions.

Thanks Trevor, but there’s no need for you to apologise. You and Theo did contact me and the only reason why permission wasn’t granted immediately is that Theo explained that the intention was to get the RO image distributed as part of an official, as endorsed by the foundation, RaspberryPi distro. (Don’t know if that’s still the case).

1. In my haste, this was poorly worded. Per Jeffrey’s comments, I “can’t speak on ROOL’s behalf” either! I meant “officially” in terms of following the roadmap (“Disc image: Popular RISC OS apps ready configured”, “Process control: […] Check licences of bundled software” – Licensing identified as Essential 2011-11-03) and the requesting of final formal permissions to be emailed to ROOL.
2. I don’t know what the final distribution arrangements are expected to be.
   1. But regarding the possible distribution by the Foundation, the rationale for free distribution was explained on 2011-12-02 (Fred, you’re obviously already fully aware of this, and subsequent exchanges).
3. The disc image proposals have unfortunately been almost stagnating of late.
   1. Therefore, until someone (possibly other than Theo or me – if you’re reading this and looking for something to do, please adopt an application or two!¹) contacts you directly, please feel free to share your views on the community licensing request communication (by email and/or in the relevant forum).
4. Clearly the platform no longer has the range of associated professional news publications it once did. And no single entity is “in charge” of developments and developers (Developer Newsletter, anyone?). Chris’s distro seems to have been converging toward an intended finished product (which is what would be expected IMHO) albeit in advance of the individual software licensing conditions being finalised.
   1. The fact that developers have discovered this temporary situation almost by accident can be attributed to a lack of communication.
   2. From what I’ve read on the Raspberry Pi forum, the existence of the distro has been useful to others eager to try out RISC OS sooner rather than later.
   3. If appropriate distribution licensing for your software isn’t (and possibly won’t be) agreed, hopefully you’ll still be able to note the increased audience via download/support requests – whether this will be less than the situation were your software to be included on the SD card is going to be (I would suggest) practically impossible to quantify.

¹ The password for that Gmail coordination account can be made available to trusted others willing to help out.

Trevor,

Thanks for this link (community licensing request communication) which I had not seen before nor was aware that it existed.

By replying to .. (copying to riscosrpi.coord@gmail.com) and/or posting on the forum. Any final formal permission is probably best communicated directly to ROOL at info@riscosopen.org.

Looks like a possible communication problem – if I am putting together the disc image for ROOL, as I agreed to do on 8th July, then perhaps I need to see these replies?

Yes. However I was placed in a rather odd position – six months ago an initiative was started (by someone else, again on behalf of ROOL) to ask for such permission on ‘likely software’ but it had made little progress (very few items had got to a definite Yes or No) and it appeared to me that contacting authors was therefore going to be difficult to achieve.

In which case, the software goes by the wayside.

However, you do seem to be making it much more difficult that it needs to be. For example, the email address that you contacted me on yesterday must have taken a lot more time and effort to have found than if you had simply opened the PrintPDF documentation and used the address on the front page of the manual.

I am still trying to find e-mail address for hipposoft and jeff drobe (their web sites don’t seem to have a ‘contact’ button).

Ahem. Hipposoft seems to have a clickable address at the bottom of the page, and anyway the name of the developer looks awfully familiar.

If you want an address for Jeff Doggett, let me know and I’ll send you the one I have from Fat32FS.

2. From what I’ve read on the Raspberry Pi forum, the existence of the distro has been useful to others eager to try out RISC OS sooner rather than later.

That’s fine, but still no excuse for ignoring licence conditions. It’s also no help when potentially ARMv6-unsafe software is included in the RPi image because no-one bothered to ask the developer at what point in the release cycle these issues were resolved.

To be honest, this is a similar issue to the one with the ARMv6/7 Compatibility List. A load of my software appeared on there without anyone contacting me (despite my email being clearly given in all my software’s manuals), resulting in it being (IMHO) wrong and/or misleading. A quick email would have cleared things up, and saved my annoyance when I stumbled across the information by accident. It would probably have got me updating my software for the new hardware more quickly, as ARMv6/7 compatibility wasn’t something that I’d given much thought to when it didn’t directly affect me.

then perhaps I need to see these replies?

Email sent.

ARMv6-unsafe software

AIUI ARMv7-safe <> ARMv6-safe, although I think this was less understood by some (myself included) earlier on.

[…] ARMv6/7 Compatibility List. A load of my software appeared on there without anyone contacting me […]

I may be wrong, but I thought the initial idea of that page was to alert other testers of software to those applications which had already been tried, to save duplication of effort in re-testing. Whether or not non-working software was followed up with authors was probably a combination of chance and availability of spare time by those contributing to the page.

ISTR the page being linked to quite prominently for a long time, but if news sites don’t report all developments (and as ROOL have no admin staff to issue announcements), then it’s difficult to see how things could have happened much differently. Apologies if that doesn’t sound very sympathetic.

Anyway, I expect the vast majority of developers with a current interest in the platform¹ are now more or less aware of the intentions (particularly those in the UK who are in regular contact with other developers/users).

It would have been helpful if I (or anyone else aware) had ensured Chris knew about the existing attempts to contact authors. Sorry for not doing this, even though I see Chris in person fairly regularly at our user group.

¹ That leaves the unreached remainder of current developers (along with original authors of unmaintained software) to still be engaged. I’d say this is unlikely to happen in connection with the official first RPi RISC OS release, but could perhaps be an aspiration for 2013.

The ‘appplication emporium’ software would just know where to put everything inside the zip file that gets downloaded and, crucially, the ‘software supermarket’ would be able to update itself as things changed.

Hehe… You ought to register “Application emporium” (assuming nobody else has?). I like that!

Unfortunately there’s a theory (it just knows / it can update itself) and then there’s reality where data files aren’t updated, smart parsers to find new versions on webpages get thrown by some eccentric CSS tag, and the whole lot blows up over an missing semicolon.

but it had made little progress (very few items had got to a definite Yes or No) and it appeared to me that contacting authors was therefore going to be difficult to achieve.

Yes, something of this nature is going to be an uphill battle. But, given the nature of copyright, a “yes” is a “yes” and everything else is a no. Sadly you can’t drop on the software and then look as some people might decide to say no out of annoyance.
Sorry, but it looks like the difficult task was dropped into your lap.

I am still trying to find e-mail address for hipposoft and jeff drobe (their web sites don’t seem to have a ‘contact’ button).

Jeez… Google!

Hipposoft – I assume you are looking for SwiftJPEG permission here, is “ahodgkin” at the domain “rowing” with the tld “org.uk”. Link somewhat hidden at the bottom of the page.

Jeff Drobe was a little harder to find. I’m guessing you mean the first search match – Jeff Doggett at Drobe, with Fat32FS? No email on the page, so I downloaded the Fat32FS archive and read the ReadMe. Final line of the file, he goes by his full name (jeffrey.a.doggett) and he is a user of GMail. You did read the ReadMe, didn’t you?

There, took about four minutes. ;-) At least the two you picked to mention are still involved in the scene. It’d be a bigger issue if we had a Geocities problem here and the people/info had just vanished…

Thanks for the info – I have just got in today (somewhat earlier than I expected) and will work through these. The page where fat32fs is hosted presents a page of zip files and it is not clear that the user is allowed to download them but there seems no other possible purpose in providing the page… Anyway water under the bridge now.

Can I suggest that it is better to link to an author’s home page than to a specific piece of software, because:

1. It’s proof against version updates changing the link;
2. It’s proof against the author rearranging his/her website;
3. It may expose the user to further interesting items.

Certainly, if anyone points to anything on my website, that is what I would ask.

Can I suggest that it is better to link to an author’s home page

I do agree, in principle, although it depends on the content of the web site – ideally I would point to the right item on a page where all the software available is listed.

Have my hands a bit full at the moment, so only just seen this discussion…

I should probably apologise for somewhat dropping the ball on making contacts with authors, which we started doing in Nov/Dec 2011. Partly this was because it was unclear what was happening with the RPi port while we had no access to it, and because I didn’t have a lot of time at that point.

My primary assumption has always been that if we’re not explicitly granted rights, we don’t have them. That is why designations such as ‘Freeware’ are awkward – unless you define what ‘Freeware’ means (since UK/EU law doesn’t define it) we have to assume that we have no rights. We could take a view that it’s ‘obvious’ what the author meant, but then the author is going to pop up and say they meant something else entirely. Unfortunately, the vagueness of the distribution conditions of much RISC OS software are such that we can’t be sure we have rights to do anything, and must therefore assume we have none.

I was also being cautious about half-hearted distribution rights. For example, an author gives only ROOL the rights to distribute an image. What if that image is then distributed by BitTorrent? You got the image in a thousand different bits from a thousand different servers, none of which are connected to ROOL. It’s those home servers doing the distribution, not ROOL. Is that allowed? They might distribute things that are superseded (eg putting up “last year’s” image), and we can’t stop them. What if someone ‘remixes’ the image by adding in extra software? Do they have to email a hundred different authors asking for permission to distribute the parts they already have?

In the specific case of the RPi Foundation’s distro, the educational aims of the project are about dissemination to as wide an audience as possible. Having to jump through hoops as regards distribution makes it more likely that the software requiring the hoops will simply be dropped, because that would compromise the dissemination goals.

The flip side of this is that those compiling distributions should be quick to respond to authors wishes – if the software needs to be updated (or removed), it should be quick and easy to change the distribution (with perhaps some caveats for release freezes).

Negotiations with authors is a big job, which is why it isn’t fair on Chris or other distro compilers to have to do all the work. This was the motivation for the ‘disc image proposals’ wiki page – with the hope that it could be a group effort (not helped by ROOL wiki markup being a little painful to use).

Anyway, I would encourage authors who would like their software to be included to get in touch, and encourage a wider conversation about tidying up licensing terms in RISC OS software. Meanwhile we still need to read through the license terms of software and contact those authors where distribution (and perhaps minor file layout reorganisation for distribution) conditions are unclear.

Just wondering – is there any update at all on any of the major bits of porting for the Pi, and who’s on the case?
-Hardware cursor
-Sound
-Aemulator – Adrian Lees?

Hardware cursor and sound are waiting for dual-licensing of the Linux VCHIQ code at which point they should happen fairly easily. John’s on the case for that one.

Aemulor: Adrian’s been doing work on that for BeagleBoard recently – I don’t know if he has any plans for a RPi version.

Aemulor: Adrian’s been doing work on that for BeagleBoard recently – I don’t know if he has any plans for a RPi version.

He did say something at the MUG show (but I can’t remember exactly what).

Adrian is working on a version of Aemulor for the Pi (and BB/ARMini) – see here for the last update.

On the subject of sound/VCHIQ, for the past couple of weeks I’ve been working on porting the (still GPL licensed) VCHIQ driver to RISC OS. The core code seems to be working (once you cut out all the layers and layers of cruft it’s just one source file and a few headers that are needed), but I won’t know for sure until I get the SWI interface implemented (hopefully sometime this week).

I’m also still clinging to the hope that I’ll have enough spare time to knock up a non-VCHIQ sound driver (which will only be able to support the headphone output) for if the VCHIQ license isn’t sorted out in time.

Picking up on miscellaneous other points mentioned in the last week or two:

Steve and Ben have been on holiday and off email for the last couple of weeks – haven’t received any emails from them for a while. So please don’t ascribe any opinions or motives to their silence – they’re merely having a rest!

PrintPDF: we were sending off batches of emails contacting authors, and evidently didn’t get to PrintPDF before we ran out of steam, so apologies Steve. On the wiki page it’s not marked as having an email sent or being cleared for release; software in that state is simply a ‘wishlist’ item, nothing more. People have always been free to add such things to the page (it’s a wiki, after all).

I think we’ve had an unfortunate disconnect between the work that we did in late 2011 and Chris’ work, which is my fault for not briefing Chris on exactly what the licensing position was (and is).

A licence audit is one of the things marked as essential on the RPi todo list; again I should apologise for not keeping up with Chris’ distro to spot any likely issues. ROOL haven’t been involved in checking either AFAIK – that’s part of the release freeze and signoff process.

Links to authors websites rather than apps directly: good idea generally, but you wouldn’t believe how terrible the navigation can be on some sites.

EUPL: that looks nice, I hadn’t seen it before. I’ll have a look in more detail. One caveat is that popular licenses are well-understood (or at least the points of contention are well-known). A new license may not be.

Releasing source: I’m not sure I agree that your software should be handcrafted out of finest rainforest before you release the source. It may be horrid, it may be embarrassing, but it allows your users to fix that pesky bug. Getting that bug fixed, even if wading through piles of to get there, makes users happy. I have a load of software I’ve open-sourced that I wrote when I was 13… I’m really not proud of it, but it’s there should anyone care (for the most part it seems they don’t, but that’s their choice). The code for PuTTY, which I’ve been watching for about 15 years, has been rewritten a number of times underneath to do the same functionality in a nicer way. But that’s partly a result of people being able to get involved by working on the source.

Packaging/emporium: had an email exchange about this today. I don’t know the exact spec of the new system, but communication channels are open (but time constraints press everyone).

To try and end the PrintPDF license saga on a positive note, there’s now a ‘stable’ version available which is (or at least should be) good for ARMv6/7 systems: PrintPDF 0.88.

PrintPDF: we were sending off batches of emails contacting authors, and evidently didn’t get to PrintPDF before we ran out of steam, so apologies Steve. On the wiki page it’s not marked as having an email sent or being cleared for release; software in that state is simply a ‘wishlist’ item, nothing more. People have always been free to add such things to the page (it’s a wiki, after all).

Steve and I have exchanged some emails on the subject this evening, and I think the matter is now closed (or close to being so). I hope that ROOL now have everything required from me to include PrintPDF 0.88 (or later) in the distro should it be decided to do so.

Links to authors websites rather than apps directly: good idea generally, but you wouldn’t believe how terrible the navigation can be on some sites.

Oh, I would… FWIW, my preference is a link to the website: if downloaders stumble across other useful software while picking up what they went to the site for, so much the better IMHO. If the software is too hard to find, I’ll settle for a more direct link. Linking to the actual archives is bad, however, unless there’s absolutely no alternative — not least because I’m not the only one who uses names like “printpdf088.zip”.

EUPL: that looks nice, I hadn’t seen it before. I’ll have a look in more detail. One caveat is that popular licenses are well-understood (or at least the points of contention are well-known). A new license may not be.

Indeed. Thanks to Rick for the pointer to this.

Releasing source: I’m not sure I agree that your software should be handcrafted out of finest rainforest before you release the source. It may be horrid, it may be embarrassing, but it allows your users to fix that pesky bug. Getting that bug fixed, even if wading through piles of to get there, makes users happy.

Agreed, although you’ve not seen the original source for CashBook (which started out as a mix of the worst bits of BBC BASIC and C style combined into one place).

To be honest, the main problem for me is that over the past twelve months I haven’t had the time to sit down and decide what route to take on licensing. It’s not a decision that is easy to change later, so I want to be happy I’ve made the correct decision before I leave the current arrangement behind. Now that I’m in danger of actually releasing some new software sometime, it would make sense to sort the issue out and use the new license (whatever it might end up being) for that instead of my old “Freeware” one.

I hope that ROOL now have everything required from me to include PrintPDF 0.88 (or later) in the distro should it be decided to do so.

The decision point comes a bit later (after the image is independently tested and licence conditions checked by ROOL) but I have revised the alpha distro to include 0.88, many thanks. For the moment AWViewer, StrongEd and RiscLua are omitted pending licensing discussions. Not a good time of year to do this unfortunately being holiday season…

Licensing is a real issue for RISC OS. I feel like inventing a ‘freeware’ definition that actually means that (but stands up legally).

I feel like I should say something just to acknowledge the issue. It’s unfortunate that this flared up while Steve and I were both away, as there seem to have been some misunderstandings.

Rest assured that ROOL takes licences very seriously. After years of sorting through the RISC OS source tree and preparing the DDE and RPCEmu bundles, considering licence compatibility issues, tracking down and negotiating with rights holders, we’re painfully aware of how time-consuming the process can be.

As such, we were all too grateful to have a volunteer (in the form of Chris) to take on the task for the Raspberry Pi free software bundle. We perhaps forgot how complex it can be for someone to pick up the process from scratch, especially working on their own – maybe he is regretting it now? Do we need a better way of sharing out the work?

The truth is, individual authors have different motives for making software freely available, and they are within their rights to release it under any conditions they choose. Most of them are reasonable people who will change licences or make exceptions for a good cause if you explain to them what you’re trying to achieve. But unless the software comes with a licence that clearly permits redistribution in the ways that the Raspberry Pi bundle might be used (direct download, peer-to-peer or pre-imaged into an SD card) then it does need to be explicitly cleared with the rights owners, or else the software can’t be included.

As I don’t think I’ve seen this covered anywhere yet: does GPL software count as an ‘appropriately permissive’ licence?

The GPL specifically limits the scope of its derivative works to permit GPL programs to be included on a “volume of a storage or distribution medium” (a disc, to mere mortals) so there are no licence conflicts, and anyone is implicitly permitted to distribute a disc including the software provided they comply with the conditions imposed by the GPL.

These conditions are more onerous upon ROOL (or Chris, or any other redistributor) under the GPL than under most other Open Source licences. So as a distributor, given a choice between two equivalent programs, one under GPL and the other under another licence, I’d probably choose the non-GPL one. In short, we either need to include the source on the disc (pushing up bandwidth costs and the time taken to assemble the disc image or to duplicate SD cards), or we need to arrange to archive and continue to distribute the sources for three years after we stop distributing the binaries. Yes, it’s really like that – the terms of the GPL are public and you can read them for yourself.

Yes, for the GPL stuff I just included the sources, as provided – sometimes they were rather bare as if the author was just paying lip service to it. I’ll be handing over the baton this weekend so that the proposed SD card image can be reviewed, tweaked and tested by ROOL to make sure it gets checked independently.