Star Commands Revamp

Hi,

• The use of wildcards and recursion could be improved (I recently wanted to copy all but a specific file from a directory and couldn’t find a simple way to do it).
• Also, a general flag to skip errors would be great – e.g. if you try and wipe a file that isn’t there but don’t mind if it isn’t…
• As an example of specific improvements: could CDir create all the directories in the path specified (e.g. CDir top.middle.end would create all three directories if they’re not present.

Thanks, Adam

You’ve got the ‘X’ command in BootCommands which does your second request. Prefix a command with ‘x ’ and any error will be suppressed. The third request is covered by the ‘mkdir’ utility which lives in RiscOS.Library.UNIX in the released BBE. You can copy that into !Boot.Library and set an alias:

*Set Alias$cdir "mkdir -p "

this will do what you’re after.

Thanks for the tip about “X”.

As for mkdir – that’s kind of missing my point. I’m not looking for an (optional non-standard) alternative to CDir (for example) but for CDir to be improved.

Adam

As for mkdir – that’s kind of missing my point. I’m not looking for an (optional non-standard) alternative to CDir (for example) but for CDir to be improved.

Adam

Arbitarily changing the behaviour of existing * commands seems to me to be dangerous.

I think it would be better to add Mkdir to RISC OS or to add a -ALL parameter to CDir to make all the dirs.

I think it would make more sence to make something like bash a standard component of RISC OS and keep the old CLI for compatability.

James wrote:

Arbitarily changing the behaviour of existing * commands seems to me to be dangerous.

Yes, you’re right.

I think it would be better to add Mkdir to RISC OS or to add a -ALL parameter to CDir to make all the dirs.

Sounds good :) (I was only using CDir as an example – I’m sure there are similar improvements waiting for lots of the star commands.)

Julian wrote:

I think it would make more sence to make something like bash a standard component of RISC OS and keep the old CLI for compatability.

Wow, an interesting option – it’d certainly bring a comprehensive new world of scripting :)

Would this be feasible? How would it work? (Presumably you’d have a new set of “bash” filetypes to mirror, obey, taskobey etc?)

Adam

Would this be feasible? How would it work? (Presumably you’d have a new set of “bash” filetypes to mirror, obey, taskobey etc?)

You could probably get away with one filetype, with obey/taskobey selected by an embedded comment on the first line of the script.

I believe however that bash is gpl.

I believe however that bash is gpl.

So? As long as it stays a separate component that would not be a problem. GPL code can be used in non-GPL projects, see Martin Würthner’s GutenPrint as an example.

So? As long as it stays a separate component that would not be a problem. GPL code can be used in non-GPL projects, see Martin Würthner’s GutenPrint as an example.

GPL code is not compatible with the RISC OS Shared Source Licence. GutenPrint is an irrelevant example.

GPL code is not compatible with the RISC OS Shared Source Licence.

Yes, we all know that. But that only means that we can’t mix GPL code and Castle code within a single OS module or executable.

GutenPrint is an irrelevant example.

No it is not, as it demonstrates the use of GPL code in a commercial project, where the rest of the code is not under a GPL compatible licence.

Yes, we all know that. But that only means that we can’t mix GPL code and Castle code within a single OS module or executable.

Maybe to you but, on this website at: https://www.riscosopen.org/content/documents/ssfaq

It’s also clear from looking at the GPL that it has no real concept of RISC OS relocatable modules. The GPL expects a Linux-like system when applied to an operating system. This would make understanding scope of its effects very difficult in the case of building a complete RISC OS ROM with some of the Castle shared source modules and some a mixture with others completely independently developed.

No it is not, as it demonstrates the use of GPL code in a commercial project, where the rest of the code is not under a GPL compatible licence.

1. Gutenprint does not compile into a single rom image (Arguably the RISC OS ROM can be considered a single executable)

2. Gutenprint is not intended for commercial sale to 3rd parties on the basis that it ‘includes no GPL code’

3. GPL code was briefly included in RISC OS 5 once; despite the bold example of Gutenprint it was eventually removed.

Can we have a definitive answer on the question of GPL contributions from the ROOL people please?

I don’t think we’re going to be able to provide a definitive answer, I’m afraid. It all hinges on what consititutes a “derivative work” of a GPL program, and where you consider the exception covering “mere aggregation” to kick in. Even the FSF themselves admit that they can’t define this, and that it is “a legal question, which ultimately judges will decide”.

In the absence of legal precedent, we (and anyone else distributing something containing GPL code) would need to weigh up the risks of doing so, comparing the level of integration of GPL code and the likelihood which we consider that a judge would rule that we had formed a derivative work. As a not-for-profit organisation with no assets, ROOL would not be worth anyone’s money to sue, but Castle or other commercial operators might well take a different stance and opt to exclude all GPL code. This means we also have to bear in mind the fact that including GPL code in a ROOL distribution of a RISC OS ROM might force a futher fork in RISC OS which would be undesirable and would not otherwise be necessary.

The FSF’s non-legally-binding GPL FAQ says that they view two pieces of code intended to be run together in the same address space to consititute one program. If this were taken literally, it would preclude the distribution of any GPL code by anybody to run under RISC OS at all. Although this interpretation is supported by the fact that the Linux kernel needs a special licence exception to allow it to run non-GPL applications, I can’t believe this is what is intended.

My personal view is that it is the act of linking code together—either statically or dynamically—that forms a derivative work. This is commonly performed by the linker tool in a compiler suite, but I believe that in order to include dynamic linking operations (as intended by the FSF), the definition should include any operation performed on the binary by itself, or by an external agent, which changes the content of the binary for the purposes of interworking with other code, and which is necessary for the binary to function correctly.

This would have the following implications for RISC OS code:

• The HAL image and the OS image are not linked, merely aggregated in the ROM image. They communicate via standardised headers, and you could distribute multiple HAL and OS images, leaving it to the user to concatenate them without the use of specialist tools. This is why the use of GPL code in the Iyonix HAL did not infect the OS.

• Most assembler modules are position-independent code, and if included in the ROM image, they are concatenated together and are otherwise unchanged. I consider this to be mere aggregation and therefore not subject to GPL infection between modules. Likewise, softloading an assembler module merely involves copying it into the RMA.

• Softloadable C modules (and a few assembler ones) are not position-independent and so need to be patched upon loading—this happens transparently to the user, but it happens nonetheless. Most C modules are also dynamically linked with the SharedCLibrary. Critically, these linking steps are performed by the user during the act of execution of the module, not by the developer prior to distribution of the module, so GPL distribution restrictions do not apply.

• C modules present in the ROM are different, because they are by definition read-only and so cannot be patched. They are statically linked during the creation of the ROM image—this is why doing *RMFaster on any C module will fail. The creation of a ROM containing GPL C modules is definitely breaking at least the spirit of the GPL, because the end-user wouldn’t be able to make changes to a GPL module and just reinsert it back into the ROM image. C modules are not “merely aggregated” into a ROM image.

Having said that, I can suggest the following approach that arguably gets round the issue, and that is to include GPL C modules in the ROM in the form of soft-loadable modules residing in ResourceFS. This is inefficient because the module doesn’t execute in place, but for any class of module that doesn’t mind initialising after all the “real” ROM modules and which can’t (for whatever reason) be included on the hard disc, it could have its uses.

I repeat, this is my personal interpretation of the GPL, and does not represent the views of ROOL, Castle or the FSF.

Moot point, but sticking a module in the RMA isn’t ‘all’ that must be done – it does have to be linked to the kernel’s module handler and this could be considered a form of dynamic linking.

I’ve long been unhappy with the way C modules are built (in general) and OS ones in particular. They could have been dynamically linked, with the jump table in the RMA accessed through R12. Position-independence is then easy-peasy.

All you need is a new compiler. :P

Has anyone checked if the GPLv3 clarifies some of these points? If not, maybe it would not be too late to suggest a few clarifications?

I hadn’t really looked at GPL v3 in great depth before now, but it doesn’t appear to be any more specific about what consitutes a “derivative work”. In fact, it no longer uses the term at all, preferring “a work based on the Program”. However, it does offer a more precise definition of its exemption:

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

...although this is still open to interpretation of what constitutes a “separate and individual work” – we can but hope that a judge would consider distinct modules of a RISC OS ROM image to fall under this classification. If we proceed from this assumption, then the rights granted by the GPL to the end user to run, modify and distribute modified and unmodified versions of the GPL code in source and binary form would require anyone distributing (strictly speaking, “conveying”) a RISC OS ROM, at a minimum to either

1. supply all the non-GPL modules in binary (for assembler) and object (for C) format, plus GPL modules in source format, along with the ROM linker tool, or
2. supply all non-GPL modules as a pre-linked partial ROM image, plus GPL modules in source formart, along with a tool to link the GPL modules at the end of the ROM

An important point that occurs to me when comparing GPL v2 and v3 is that they have tightened up the definition of the supporting code for which the distributor of the GPL program is not responsible for either distributing, or ensuring that a third party will distribute, to the receivers of the GPL program. It used to be “anything that is normally distributed [...] with the major components (compiler, kernel, and so on) of the operating system”, which would obviously include all the RISC OS ROM modules. Now, it explicitly only includes:

• libraries implementing an interface specified for a particular language (eg the ANSI C/C++ standard libraries)
• libraries implementing an interface defined by a recognised standards body (spot the Linux-centric thinking here: the main Linux system API is defined by POSIX, an IEEE standard—by comparison, there’s next to no chance that any standards body is going to adopt the RISC OS SWI API)
• libraries whose sole job is to enable the use of the work with a “major essential component [...] of the operating system” (we haven’t really got libraries of this type, except perhaps if you split up OSLib on a per-module basis)

For example, I doubt you could count the Toolbox as an “essential component” of the OS, since it’s possible (and fairly common) to write a GUI application without it. This would mean that anyone distributing a GPL v3 application that used the Toolbox would be responsible for either supplying the Toolbox sources, or ensuring that a third party was able to do so (say, by supporting ROOL).

I’ve brushed over the whole issue of patent protection and the care you would have to take in writing a distribution licence in this respect for a ROM which included both GPL and non-GPL code. That’s largely because I haven’t really got my head around it.

Basically, the GPL is a pain to work with, especially if you need to interwork it with other non-GPL licences. It’s really not well suited for use under RISC OS in particular. I’d recommend not using it, if at all possible.

Again, this is all my personal view.