Open Sourcing

[druck]

I'm thinking of open sourcing some of my RISC OS software such as
TimerMod. As I see it there are three questions, which I'd appreciate
your thoughts on.

1) How to handle RISC OS file types
2) Where to host
3) What licence to use

In more detail

1) I moved to using git for all my software a while ago after previously
using Perforce, neither of these ran on RISC OS at the time, so
everything has been checked in and out from a Windows or Linux box on to
a shared directory accessible to RISC OS. Sources are in c and h
directories and other file types are in the form of filename,xxx as
crated by either Lanman or Sunfish.

There is now a RISC OS port of git which stores RISC OS files without
type extensions, and applies the filetypes on checkout. I've not started
using this yet, given that the port doesn't do ssh, so still requires a
shared directory.

2) I've already used GitHub for some non RISC OS projects, and know how
to use if for merges. There is also GitLab, I've not looked at that yet,
although I should do as I've signed up for access ROOL's locally hosted
repository.

The main problem with either of those at the moment is the the RISC OS
version of git can't do SSL yet, so wont be able to access them
directly, and I ultimately want to allow a RISC OS end to end solution.

3) I could just slap a GPLv2 licence on everything, but does anyone have
experience of other open source licences which may be more suitable?
Stand-alone applications aren't such a big problem, but things like
TimerMod which people may want to use in other applications, may need
more thought.

Let me know what you think.

---druck

[Steve Fryatt]

On 14 Jun, druck wrote in message
<rc55rf$i08$1...@dont-email.me>:

> 1) I moved to using git for all my software a while ago after previously
> using Perforce, neither of these ran on RISC OS at the time, so everything
> has been checked in and out from a Windows or Linux box on to a shared
> directory accessible to RISC OS. Sources are in c and h directories and
> other file types are in the form of filename,xxx as crated by either
> Lanman or Sunfish.

The GCCSDK version of Zip can strip and set filetypes from the ,xxx
extensions, which is how I create my Zip archives. I store all non-text
files with their ,xxx extension in revision control (SVN, in my case, but it
shouldn't make any difference).

It does require a host system of some sort, however: either a network FS or
an emulated machine like RPCEmu.

> 2) I've already used GitHub for some non RISC OS projects, and know how to
> use if for merges. There is also GitLab, I've not looked at that yet,
> although I should do as I've signed up for access ROOL's locally hosted
> repository.
>
> The main problem with either of those at the moment is the the RISC OS
> version of git can't do SSL yet, so wont be able to access them directly,
> and I ultimately want to allow a RISC OS end to end solution.

I'm interested in thoughts on this, too. :-)

> 3) I could just slap a GPLv2 licence on everything, but does anyone have
> experience of other open source licences which may be more suitable?

A number of years ago, someone on the ROOL forum pointed out the EUPL v1.1,
which is effectively a GPL without some of the more "exciting" clauses. I
ended up using it for all of my Open-Sourcing, because it seemed less
political and more pragmatic.

One key point, though, is that it considers itself "GPLv2 compatible" -- so
if someone wishes to use my code in a GPLv2 project they can. This means
that I'm not forcing others to follow me in using the EUPL.

> Stand-alone applications aren't such a big problem, but things like
> TimerMod which people may want to use in other applications, may need more
> thought.

There's always the OSLib approach: "if you use the source as source, it's
GPLv2, but if you use it as a binary blob, you can have this more relaxed
licence that we apply separately for a very specific purpose".

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[Gerph]

On Sunday, 14 June 2020 13:40:16 UTC+1, druck wrote:
> I'm thinking of open sourcing some of my RISC OS software such as
> TimerMod. As I see it there are three questions, which I'd appreciate
> your thoughts on.
>
> 1) How to handle RISC OS file types

NFS-style encoding is the only way to go, really.

Filename,xxx for filetyped files.
Filename,llllllll,eeeeeeee for non-filetyped files.

It allows for the preservation of the types on transfer between systems and the editing on non-RISC OS systems with suitable fidelity. You do lose attributes, but these are commonly synthesised from the unix mode on the stored files, and rarely significant to the application. If they /are/ significant (and actually the same thing has been my rule for CI on linux as well), assert the correct filetypes at release time, just before you archive things, rather than trust the SCM to manage it. (largely from experience with perforce and its amusing way of resolving conflicts on merge which commonly result in the exact opposite of the mode change you wanted being the one that was accepted by engineers)

This form is also supported by the InfoZip tools (`zip` and `unzip`) and can be used to construct RISC OS file information from the filesystem, and vice-versa.

> 2) Where to host

Whereever you like? Open source can just mean you dump it on a server somewhere that people can download. Depends on what you want to do with it. These days, I'd use git, as you mentioned. But the two major options for hosting, to me, are GitLab and GitHub.

> 3) What licence to use

BSD or MIT, is my preference.

> In more detail
>
> 1) I moved to using git for all my software a while ago after previously
> using Perforce, neither of these ran on RISC OS at the time, so
> everything has been checked in and out from a Windows or Linux box on to
> a shared directory accessible to RISC OS. Sources are in c and h
> directories and other file types are in the form of filename,xxx as
> crated by either Lanman or Sunfish.

I had similar experience bad in the early 2000s, with cvs. These days, everything's hosted on NFS or the Mac and accessed directly using the same form of NFS encoding.

> There is now a RISC OS port of git which stores RISC OS files without
> type extensions, and applies the filetypes on checkout. I've not started
> using this yet, given that the port doesn't do ssh, so still requires a
> shared directory.

IF you want to host on a public git repository, and would like people to be able to check out the code, and build it, git's a fine choice.

> 2) I've already used GitHub for some non RISC OS projects, and know how
> to use if for merges. There is also GitLab, I've not looked at that yet,
> although I should do as I've signed up for access ROOL's locally hosted
> repository.

GitHub seems to be more popular. I use GitLab, self hosted, for all my RISC OS and non-RISC OS things. They're equally useful and workable. There are differences in presentation and each has their own quirks. Then there's BitBucket. I've only found a couple of RISC OS things on BitBucket, and having had experience with using it at previous jobs, I shy away, myself.

> The main problem with either of those at the moment is the the RISC OS
> version of git can't do SSL yet, so wont be able to access them
> directly, and I ultimately want to allow a RISC OS end to end solution.

Strictly that's a problem that is aside from the issue of making it open source. Eventually someone will address that beyond what's already present. But, the point is that both GitLab and GitHub (and BitBucket, and others) will allow you to download a copy of the source. I've worked with open source projects that despite using git, and having a front end for Pull requests/merge requests, still insist on diffs by mailing list for review. So it's hardly uncommon for that to happen. PLUS, both GitLab and GitHub offer in browser editors so that people can make changes and create branches without actually downloading the source, etc.

GitLab and GitHub offer archives of the source code for download off branch pages, and 'releases' which allow assets to be associated with a given version. That, then gives you both source and binary outputs on those platforms. Additionally, GitLab and GitHub offer CI in the form of their pipelines and workflow actions, for automated testing. Be clever, and you can build your source when you push, and cause the results to be uploaded to a distribution website.

You'll find a few people have tagged their projects on GitHub with the 'riscos' topic: https://github.com/topics/riscos

Sadly, searching gitlab for things by topics is not possible as I understand it (https://gitlab.com/gitlab-org/gitlab/-/issues/14220), which makes github more appealing if you want people to find things.

It used to be the case that you could only have a few 'private' repositories on GitLab and GitHub, but I believe that GitLab allowed unlimited, and after MS bought GitHub, they did the same, some time last year if I remember right. (my history may be off there, but I'm pretty sure they both offer private). So you can always start out using the repositories in private to get the feel for things, and then open them up later if you wish.

Oh, and you might have an aversion to Microsoft who own GitHub, so maybe that makes the decision for you. If you have an aversion to Amazon, then Gitlab may be a problem, as I believe that GitLab runs on AWS (used to be Azure, but I believe that after the MS buy out of GitHub, they diversified).

For selfhosting, GitHub offer GitHub enterprise, but I believe that's expensive and probably not a sane option for an individual. GitLab, on the other hand, offer the community edition - which I think is what you see on RISC OS Open's site, and is what I run for myself. ISTR you could also selfhost through AWS marketplace if that was your thing. I run selfhosted myself because I would prefer to keep my things local to me, and I have sufficient server space to do so - I suspect that most people don't, and the cloud hosted servers are sufficient.

I've chosen to put my (very few) public things on GitHub, mostly; but internally I use GitLab.

> 3) I could just slap a GPLv2 licence on everything, but does anyone have
> experience of other open source licences which may be more suitable?
> Stand-alone applications aren't such a big problem, but things like
> TimerMod which people may want to use in other applications, may need
> more thought.

GPL is not a nice license for reuse, unless you want to force people to buy into your ideology. To me, that's not free. IMO. BSD or MIT, depending on your preference are far freer license, without hinderance for reuse (and without a great big manifesto behind it). Or there's the zlib license which is more wordy, but about as suitable.

GPL is unsuitable for modules, unless you require all the applications and other modules that use it to also be GPL. LGPL is more suitable for modules. BSD and MIT are freer in all cases.

--
Gerph.

[Theo]

Gerph <ge...@gerph.org> wrote:
> On Sunday, 14 June 2020 13:40:16 UTC+1, druck wrote:
> > I'm thinking of open sourcing some of my RISC OS software such as
> > TimerMod. As I see it there are three questions, which I'd appreciate
> > your thoughts on.
> >
> > 1) How to handle RISC OS file types
>
> NFS-style encoding is the only way to go, really.
>

> This form is also supported by the InfoZip tools (`zip` and `unzip`) and
> can be used to construct RISC OS file information from the filesystem, and
> vice-versa.

It's also supported by HostFS on RPCEmu and I think VRPC too.

> > 3) What licence to use
>
> BSD or MIT, is my preference.

+1 Unless you want to make strong copyleft statements, I'd stick with BSD.

> IF you want to host on a public git repository, and would like people to
> be able to check out the code, and build it, git's a fine choice.

+1 I think git has 'won', over SVN, P4, bzr, Mercurial, etc etc.

> GitHub seems to be more popular. I use GitLab, self hosted, for all my
> RISC OS and non-RISC OS things. They're equally useful and workable.
> There are differences in presentation and each has their own quirks. Then
> there's BitBucket. I've only found a couple of RISC OS things on
> BitBucket, and having had experience with using it at previous jobs, I shy
> away, myself.

Agreed. RPCEmu using Mercurial is the only thing that made me use Bitbucket,
and I can't say I'm that keen.

> > The main problem with either of those at the moment is the the RISC OS
> > version of git can't do SSL yet, so wont be able to access them
> > directly, and I ultimately want to allow a RISC OS end to end solution.
>
> Strictly that's a problem that is aside from the issue of making it open
> source. Eventually someone will address that beyond what's already
> present. But, the point is that both GitLab and GitHub (and BitBucket,
> and others) will allow you to download a copy of the source. I've worked
> with open source projects that despite using git, and having a front end
> for Pull requests/merge requests, still insist on diffs by mailing list
> for review. So it's hardly uncommon for that to happen. PLUS, both
> GitLab and GitHub offer in browser editors so that people can make changes
> and create branches without actually downloading the source, etc.

To expand on that, it's worth listing a few features these provide on top of
basic git hosting:

- .zip downloads of your source (so no need to run a git client on a RISC OS
or other machine)

- 'forks': someone can 'fork' your repository, creating a copy on their
account. This links back to your repository, and github will show you who
has forked your repo. This is good for keeping track of people who have
made their own changes to your code but not committed them back

- 'issue tracking': bug reports etc can be recorded against on your project

- 'pull requests': if a contributor makes changes, they can commit them to a
branch (either on their fork of the repo or, with your permission, a branch
in your repo). They then request the changes are merged by creating a pull
request, which is a bit like an item on the issue tracker but attached to
that branch. You can accept the request, when it'll get merged into your
tree automatically, or you can say 'I like it but could you change...' and
the conversation can go on until the code is ready to merge.

- CI integration: you can have commits and pull requests automatically built
and tested so it makes sure they work before you approve them

- teams, so you can control who can access which repos for what purposes
(read/write/manage/admin). Since many developers have a github account,
it's a few clicks to give them access

- previews: rendering of common file types (documents, images, etc) in the
web interface. In particular, Markdown is a popular way to write text
documentation that is readable as-is but can be pretty-printed on the
webpages; if a folder has a README.md file in it it will be displayed as
part of the folder listing.

- wikis: for editable documentation

- releases: for allowing users to download generated binaries, linked to
particular versions of the source

- Git LFS: for hosting large files (>50MB) in the repo without forcing
everyone to download the entire history of them when they clone
(handy for things like images)


Oh, and backups :) One nice thing about git is that every who checks out
has the full history of the repo at all times, so if this happens:
https://www.theregister.com/2014/06/18/code_spaces_destroyed/
you still have the full history (although not necessarily your issue tracker
etc unless you backed those up). I think if either gitlab or github did that
the software engineering industry would have much bigger problems.

> It used to be the case that you could only have a few 'private'
> repositories on GitLab and GitHub, but I believe that GitLab allowed
> unlimited, and after MS bought GitHub, they did the same, some time last
> year if I remember right. (my history may be off there, but I'm pretty
> sure they both offer private). So you can always start out using the
> repositories in private to get the feel for things, and then open them up
> later if you wish.

2018. The limits are now based on the number of CI execution time and
package storage for private repos - not likely to bother RISC OS projects
very much

> For selfhosting, GitHub offer GitHub enterprise, but I believe that's
> expensive and probably not a sane option for an individual. GitLab, on
> the other hand, offer the community edition - which I think is what you
> see on RISC OS Open's site, and is what I run for myself. ISTR you could
> also selfhost through AWS marketplace if that was your thing. I run
> selfhosted myself because I would prefer to keep my things local to me,
> and I have sufficient server space to do so - I suspect that most people
> don't, and the cloud hosted servers are sufficient.

I'd suggest starting with the cloud versions, and moving on-prem if you have
a strong need to do so. Due to the way git works, 'what if it disappears
tomorrow' concern of cloud services is much less of a worry. The main reason
to go on-prem is security of data that can't be held in the public cloud,
and possibly cost if you need some of the enterprise-y features (which is
very unlikely for a RISC OS project).

> GPL is not a nice license for reuse, unless you want to force people to
> buy into your ideology. To me, that's not free. IMO. BSD or MIT,
> depending on your preference are far freer license, without hinderance for
> reuse (and without a great big manifesto behind it). Or there's the zlib
> license which is more wordy, but about as suitable.

I'd suggest copyleft should be a decision you actively take. If you don't
really care that much, slap a BSD or MIT licence on there. If you've
thought more about the issues, GPL or EUPL (noting that EUPL is less
understood in the USA).

https://choosealicense.com/

Theo