Re: Octave Forge: Package groups and properties defined, RFC.

[Juan Pablo Carbajal]

On Tue, Mar 7, 2017 at 10:51 PM, Olaf Till <address@hidden> wrote:
> Hi,
>
> some Octave Forge web pages have been modified/added to clarify what
> packages are hosted at OF and how this is done. In particular, the
> existence of two groups of packages has been accounted for. Continuing
> to host both of these groups had been a public decision.
>
> The changes are in the developers page[1], particularly in the
> sections marked as draft. These sections link to new pages with common
> requirements for packages[2] and a description of the two package
> groups[3].
>
> The changes are the result of a discussion between Julien, Oliver, and
> me and are considered to be a draft. We request comments.
>
> Olaf
>
> [1] https://octave.sourceforge.io/developers.php
> [2] https://octave.sourceforge.io/common-requirements.php
> [3] https://octave.sourceforge.io/dev-descr-two-groups.php
>
> --
> public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Dear Olaf, this is just great! We are moving forward.

As a general comment I wouldn't use "Free software" but "Libre
software" or if you whish the free to be there "Free/Libre software".
See rationale below.

In [1] I would use "classdef based classes" (or something in those
lines) instead of "new style classes", since "new style" can change
its meaning over time.

In [2] I would reduce the license requirements for external packages
to "open source" licenses or just to "GPL" license (without version
specification), since, for example, the EUPL is not yet compatible
with GPLv3 (allows re-release with GPLv2)
https://en.wikipedia.org/wiki/European_Union_Public_Licence.
Similarly, for externla packages I would change "Free software" with
"Open-source software".

The rationale behind this is base don my experience. People who do not
understand libre software, although they might be completely aligned
with it, tend to be wary of strong libre software constraints, and in
particularly wary about the word "free", because they read it as
"gratis". My believe is that by consenting some "evil", we might
capture more users and dev and eventually seduce them into the libre
side. Again this is only for the external packages.

I would provide a link to
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
to ease the search of a license whenever GPL compatibility is
mentioned.

In [3] I see problmes with these sentences
* "If an external package is removed from Octave Forge, no new package
with the same name may be hosted at Octave Forge." I do not understand
the reason for this and I see extra work on keeping the name history
of packages without a clear benefit anbd the eventual failure to be
coherent with our own rules. Also consider: external package A evolves
to be so good at being matlab compatible that we move it to a
community package...so now it is not called A anymore? Silly, it
confuses users, and makes tracking the package harder. It sounds like
an unnecessary problematic rule.

* "Note that we don’t accept hosting of external packages with the
same name as an existing Matlab toolbox. The reason is that we’d like
to be able to provide the funtionality of Matlab toolboxes with
community packages." Needs clarification. I guess it means that if the
dev wants to provide matlab functionality he is invited to apply for a
community package, instead of an external package. Currently it reads
as it is "forbidden" to have a package that offers matlab
functionality. I suggest
"Note that we don’t accept hosting of external packages with the same
name as an existing Matlab toolbox, in this case the developer should
consider a community package instead. The reason is that we’d like to
be able to provide the funtionality of Matlab toolboxes with community
packages."

Cheers