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

[Olaf Till]

On Wed, Mar 08, 2017 at 09:47:51AM +0100, Juan Pablo Carbajal wrote:
> 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.

I'd have thought the link is sufficient for explanation... but it may
be more direct to introduce the '/Libre'.

> 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.

Good point. Will be done.

> 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 point was actually that the _package_ must be compatible with
Octaves GPL3+. You're right, if the package contains only m-code, an
arbitrary free software license is enough (GPL3+ recommended). We
probably should reword this. But "open source" won't do, since it
doesn't necessarily mean "Free/Libre 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 don't quite understand. But Octave Forge is a dedicated Free/Libre
Software site, and I would make no compromise here.

> 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.

The point was to protect contributors of external packages...

> * "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.

"forbidden" wasn't intended, of course.

> 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."

or: "should consider a community package or a different name for his
package"

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature