Octave Forge: Package groups and properties defined, RFC.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave Forge: Package groups and properties defined, RFC.

Olaf Till-2
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
On Tue, Mar 7, 2017 at 10:51 PM, Olaf Till <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Olaf Till-2
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 <[hidden email]> 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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2

> On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
>
> 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".


Of course an m-code package must necessarily be "open source" as m-files
are human readable, but compatibility whith the license of Octave is
not required in this case, so, as far as I know, but I am not a lawyer,
distribution of non-free or even proprietary packages is entirely possible.

I'm not saying we should promote non free software, of course, just that it is possible.

c.




Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
On Wed, Mar 8, 2017 at 10:56 AM, Carlo De Falco <[hidden email]> wrote:

>
>> On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
>>
>> 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".
>
>
> Of course an m-code package must necessarily be "open source" as m-files
> are human readable, but compatibility whith the license of Octave is
> not required in this case, so, as far as I know, but I am not a lawyer,
> distribution of non-free or even proprietary packages is entirely possible.
>
> I'm not saying we should promote non free software, of course, just that it is possible.
>
> c.
>
My comment only applies to external packages. I would not make
compromises on the community packages: these must be Libre software.
Againk, by putting strong constrains on the external packages we will
loose what I consider perfectly valid Libre software under GPlv3
incompatible licenses (like UEPL).
We also loos the chance to add people who do not understand Libre
software, but like the idea, although they do not call it like that.

Reply | Threaded
Open this post in threaded view
|

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

jbect
Le 08/03/2017 à 16:19, Juan Pablo Carbajal a écrit :

> On Wed, Mar 8, 2017 at 10:56 AM, Carlo De Falco <[hidden email]> wrote:
>>> On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
>>>
>>> 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".
>>
>> Of course an m-code package must necessarily be "open source" as m-files
>> are human readable, but compatibility whith the license of Octave is
>> not required in this case, so, as far as I know, but I am not a lawyer,
>> distribution of non-free or even proprietary packages is entirely possible.
>>
>> I'm not saying we should promote non free software, of course, just that it is possible.
>>
>> c.
>>
> My comment only applies to external packages. I would not make
> compromises on the community packages: these must be Libre software.
> Againk, by putting strong constrains on the external packages we will
> loose what I consider perfectly valid Libre software under GPlv3
> incompatible licenses (like UEPL).
> We also loos the chance to add people who do not understand Libre
> software, but like the idea, although they do not call it like that.

What about the list of OSI-approved licences [1] ?

Would that be acceptable as a weaker requirement for external packages ?

@++
Julien


[1] https://opensource.org/licenses/category


Reply | Threaded
Open this post in threaded view
|

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

Olaf Till-2
On Wed, Mar 08, 2017 at 04:31:25PM +0100, Julien Bect wrote:

> Le 08/03/2017 à 16:19, Juan Pablo Carbajal a écrit :
> >On Wed, Mar 8, 2017 at 10:56 AM, Carlo De Falco <[hidden email]> wrote:
> >>>On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
> >>>
> >>>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".
> >>
> >>Of course an m-code package must necessarily be "open source" as m-files
> >>are human readable, but compatibility whith the license of Octave is
> >>not required in this case, so, as far as I know, but I am not a lawyer,
> >>distribution of non-free or even proprietary packages is entirely possible.
> >>
> >>I'm not saying we should promote non free software, of course, just that it is possible.
> >>
> >>c.
> >>
> >My comment only applies to external packages. I would not make
> >compromises on the community packages: these must be Libre software.
> >Againk, by putting strong constrains on the external packages we will
> >loose what I consider perfectly valid Libre software under GPlv3
> >incompatible licenses (like UEPL).
> >We also loos the chance to add people who do not understand Libre
> >software, but like the idea, although they do not call it like that.
>
> What about the list of OSI-approved licences [1] ?
>
> Would that be acceptable as a weaker requirement for external packages ?
(I am not a lawyer...)

Any code for oct-files in distributed packages must be compatible with
GPL3+. This is enforced by Octaves license.

For m-code in the external packages, we could just require Free
Software (in the sense of Libre Software) licenses, not necessarily
(but advised to be) compatible with GPL3+. This requirement could
already be 'weak' enough for external packages.

I'm a bit irritated by the existence of different lists of Free
Software licenses. Maybe we shouldn't prescribe any of these lists for
m-code. If a license turns up which is listed only at opensource org,
we could use our common sense.

(Community packages should be compatible with Octaves GPL3+, of
course, even if they contain only m-code. My remark yesterday wasn't
well thought through.)

Olaf

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

jbect
Le 09/03/2017 à 08:34, Olaf Till a écrit :

> On Wed, Mar 08, 2017 at 04:31:25PM +0100, Julien Bect wrote:
>> Le 08/03/2017 à 16:19, Juan Pablo Carbajal a écrit :
>>> On Wed, Mar 8, 2017 at 10:56 AM, Carlo De Falco <[hidden email]> wrote:
>>>>> On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
>>>>>
>>>>> 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".
>>>> Of course an m-code package must necessarily be "open source" as m-files
>>>> are human readable, but compatibility whith the license of Octave is
>>>> not required in this case, so, as far as I know, but I am not a lawyer,
>>>> distribution of non-free or even proprietary packages is entirely possible.
>>>>
>>>> I'm not saying we should promote non free software, of course, just that it is possible.
>>>>
>>>> c.
>>>>
>>> My comment only applies to external packages. I would not make
>>> compromises on the community packages: these must be Libre software.
>>> Againk, by putting strong constrains on the external packages we will
>>> loose what I consider perfectly valid Libre software under GPlv3
>>> incompatible licenses (like UEPL).
>>> We also loos the chance to add people who do not understand Libre
>>> software, but like the idea, although they do not call it like that.
>> What about the list of OSI-approved licences [1] ?
>>
>> Would that be acceptable as a weaker requirement for external packages ?
> (I am not a lawyer...)
>
> Any code for oct-files in distributed packages must be compatible with
> GPL3+. This is enforced by Octaves license.
>
> For m-code in the external packages, we could just require Free
> Software (in the sense of Libre Software) licenses, not necessarily
> (but advised to be) compatible with GPL3+. This requirement could
> already be 'weak' enough for external packages.
>
> I'm a bit irritated by the existence of different lists of Free
> Software licenses. Maybe we shouldn't prescribe any of these lists for
> m-code. If a license turns up which is listed only at opensource org,
> we could use our common sense.

Ok, sure... I was only trying to provide a practical way for people to
know what kind of licence is acceptable or not...

To remain closer to the FSF view of things, we can use their list [1]
instead.


If I understand previous messages correctly, this should be acceptable :

a) "GPL-compatible licences" [2] for 1) community packages, or 2)
external packages that link directly to Octave (oct-files or mex-files).

b) "GPL-compatible licences" [2] or "GPL-incompatible" [3] for pure
m-file external packages.

c) "Nonfree" -> not accepted.


Finally, concerning the terminology issue raised by JP
(free/libre/open/etc.) : I think that if we decide to provide pointers
to FSF pages as suggested above, then we should stick to the FSF
definitions/vocabulary and use the word "free" only.

@++
Julien


[1] https://www.gnu.org/licenses/license-list.html
[2] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
[3] https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
[4] https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses


Reply | Threaded
Open this post in threaded view
|

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

jbect
Le 09/03/2017 à 10:43, Julien Bect a écrit :

> Ok, sure... I was only trying to provide a practical way for people to
> know what kind of licence is acceptable or not...
>
> To remain closer to the FSF view of things, we can use their list [1]
> instead.
>
>
> If I understand previous messages correctly, this should be acceptable :
>
> a) "GPL-compatible licences" [2] for 1) community packages, or 2)
> external packages that link directly to Octave (oct-files or mex-files).
>
> b) "GPL-compatible licences" [2] or "GPL-incompatible" [3] for pure
> m-file external packages.
>
> c) "Nonfree" -> not accepted.

Let me amend this proposal : in a), we should probably consider the
subset of licences that are compatible with GPLv3+.

The list [2] makes it clear in each case if there is a difference betwen
GPLv2 and GPLv3.

> [1] https://www.gnu.org/licenses/license-list.html
> [2] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
> [3]
> https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
> [4]
> https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses



Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
In reply to this post by jbect
Hi Julien,

I like your suggestiosn, little amends below

On Thu, Mar 9, 2017 at 10:43 AM, Julien Bect
<[hidden email]> wrote:

> Le 09/03/2017 à 08:34, Olaf Till a écrit :
>>
>> On Wed, Mar 08, 2017 at 04:31:25PM +0100, Julien Bect wrote:
>>>
>>> Le 08/03/2017 à 16:19, Juan Pablo Carbajal a écrit :
>>>>
>>>> On Wed, Mar 8, 2017 at 10:56 AM, Carlo De Falco
>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> On 8 Mar 2017, at 10:21, Olaf Till <[hidden email]> wrote:
>>>>>>
>>>>>> 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".
>>>>>
>>>>> Of course an m-code package must necessarily be "open source" as
>>>>> m-files
>>>>> are human readable, but compatibility whith the license of Octave is
>>>>> not required in this case, so, as far as I know, but I am not a lawyer,
>>>>> distribution of non-free or even proprietary packages is entirely
>>>>> possible.
>>>>>
>>>>> I'm not saying we should promote non free software, of course, just
>>>>> that it is possible.
>>>>>
>>>>> c.
>>>>>
>>>> My comment only applies to external packages. I would not make
>>>> compromises on the community packages: these must be Libre software.
>>>> Againk, by putting strong constrains on the external packages we will
>>>> loose what I consider perfectly valid Libre software under GPlv3
>>>> incompatible licenses (like UEPL).
>>>> We also loos the chance to add people who do not understand Libre
>>>> software, but like the idea, although they do not call it like that.
>>>
>>> What about the list of OSI-approved licences [1] ?
>>>
>>> Would that be acceptable as a weaker requirement for external packages ?
>>
>> (I am not a lawyer...)
>>
>> Any code for oct-files in distributed packages must be compatible with
>> GPL3+. This is enforced by Octaves license.
>>
>> For m-code in the external packages, we could just require Free
>> Software (in the sense of Libre Software) licenses, not necessarily
>> (but advised to be) compatible with GPL3+. This requirement could
>> already be 'weak' enough for external packages.
>>
>> I'm a bit irritated by the existence of different lists of Free
>> Software licenses. Maybe we shouldn't prescribe any of these lists for
>> m-code. If a license turns up which is listed only at opensource org,
>> we could use our common sense.
>
>
> Ok, sure... I was only trying to provide a practical way for people to know
> what kind of licence is acceptable or not...
>
> To remain closer to the FSF view of things, we can use their list [1]
> instead.
>
>
> If I understand previous messages correctly, this should be acceptable :
>
> a) "GPL-compatible licences" [2] for 1) community packages, or 2) external
> packages that link directly to Octave (oct-files or mex-files).
>
These should be GPLv3 compatible

> b) "GPL-compatible licences" [2] or "GPL-incompatible" [3] for pure m-file
> external packages.
Sounds good to me!

>
> c) "Nonfree" -> not accepted.
>
Agreed

>
> Finally, concerning the terminology issue raised by JP
> (free/libre/open/etc.) : I think that if we decide to provide pointers to
> FSF pages as suggested above, then we should stick to the FSF
> definitions/vocabulary and use the word "free" only.
>
I strongly disagree, using "free" only keeps us stuck to the
mis-interpretation. If you really want "free" to remind there
(although I see no reason, even after RMR acknowledges the problem
with the word "free") I woud go for Free/Libre software. Again, you do
not want that newcomers get it wrong, which is usually the problem! In
the words of jwe:
"Unfortunately, there are a few people who behave as though the
community owes them support as well as a 100% Matlab compatible
system, all at zero cost."
Yeap, that's what "free" also means.

Reply | Threaded
Open this post in threaded view
|

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

jbect
Le 09/03/2017 à 11:46, Juan Pablo Carbajal a écrit :
I strongly disagree, using "free" only keeps us stuck to the mis-interpretation. If you really want "free" to remind there (although I see no reason, even after RMR acknowledges the problem with the word "free") I woud go for Free/Libre software.

Sure, it is useful to make this clear for newcomers, possibly unfamiliar with the concept of free software.

One option is to use, as you suggest, a heavier expression systematically (such as "Free/Libre" instead of "Free").

Another option would be to recall the distinction only once on each page that uses the concept.  Fore instance

Like Octave itself, the packages provided at Octave Forge are Free Software.

could be changed to

Like Octave itself, the packages provided at Octave Forge are Free Software (free as in "free speech", not as in "free beer").

(with a link still pointing to the FSF page explaining the concept in more detail).

I don't know...

@++
Julien
Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
On Thu, Mar 9, 2017 at 12:03 PM, Julien Bect
<[hidden email]> wrote:

> Le 09/03/2017 à 11:46, Juan Pablo Carbajal a écrit :
>
> I strongly disagree, using "free" only keeps us stuck to the
> mis-interpretation. If you really want "free" to remind there (although I
> see no reason, even after RMR acknowledges the problem with the word "free")
> I woud go for Free/Libre software.
>
>
> Sure, it is useful to make this clear for newcomers, possibly unfamiliar
> with the concept of free software.
>
> One option is to use, as you suggest, a heavier expression systematically
> (such as "Free/Libre" instead of "Free").
>
> Another option would be to recall the distinction only once on each page
> that uses the concept.  Fore instance
>
> Like Octave itself, the packages provided at Octave Forge are Free Software.
>
> could be changed to
>
> Like Octave itself, the packages provided at Octave Forge are Free Software
> (free as in "free speech", not as in "free beer").
>
> (with a link still pointing to the FSF page explaining the concept in more
> detail).
>
> I don't know...
>
> @++
> Julien

This solution also looks good for me, even better than mine I would
say, but much more verbose.

Reply | Threaded
Open this post in threaded view
|

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

jbect
In reply to this post by Juan Pablo Carbajal-2
Le 08/03/2017 à 09:47, Juan Pablo Carbajal a écrit :
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.

Yes, perhaps the formulation is not "optimal"...

---- LONG STORY ----

The point is to acknowledge the fact that "external packages" remain under the control of their original maintainer/developer, as the first sentence : "Decisions on the content of external packages are solely in the authority of the package maintainer." already states.

Now, what happens if the package maintainer disagrees with some new orientation of Octave Forge, decides to develop it in a different direction, and thus stops making releases for OF?

Sure, this does not happen frequently with OF packages... But just for the sake of argument, as I see it, there are mainly two scenarios :

A) The package remains close to OF-compatible.  Someone from the OF community steps in and acts as "downstream" packager.  In this case the package can probably keep the same name (or perhaps be called octave-X explicitly).

B) The package diverges too much from OF requirements.  If the OF community wants to continue the development of an OF-package that will maintain no connection with the original project, this is the definition of a fork.  In this case, I believe that it is usual, as a minimal courtesy to the original dev/maintainer, and to avoid confusions, to use a different name.

The change of name can be made in such a way that the connection with the original project is not completely lost, so that users are not completely confused.  Think, e.g., of GNU Emacs -> XEmacs, NetBSD -> OpenBSD...

---- SHORT STORY / PROPOSAL ----

Since the first sentence already states that external packages remain under the control of their original dev/maintainer, I propose to remove the above sentence and simply write:

"If an external package X is removed from Octave Forge, previous releases of the package will remain available on Octave Forge."

and not discuss explicitly what happens next (scenarios A/B above, or any other variant).

@++
Julien
Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
On Thu, Mar 9, 2017 at 1:54 PM, Julien Bect
<[hidden email]> wrote:

> Le 08/03/2017 à 09:47, Juan Pablo Carbajal a écrit :
>
> 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.
>
>
> Yes, perhaps the formulation is not "optimal"...
>
> ---- LONG STORY ----
>
> The point is to acknowledge the fact that "external packages" remain under
> the control of their original maintainer/developer, as the first sentence :
> "Decisions on the content of external packages are solely in the authority
> of the package maintainer." already states.
>
> Now, what happens if the package maintainer disagrees with some new
> orientation of Octave Forge, decides to develop it in a different direction,
> and thus stops making releases for OF?
>
> Sure, this does not happen frequently with OF packages... But just for the
> sake of argument, as I see it, there are mainly two scenarios :
>
> A) The package remains close to OF-compatible.  Someone from the OF
> community steps in and acts as "downstream" packager.  In this case the
> package can probably keep the same name (or perhaps be called octave-X
> explicitly).
>
> B) The package diverges too much from OF requirements.  If the OF community
> wants to continue the development of an OF-package that will maintain no
> connection with the original project, this is the definition of a fork.  In
> this case, I believe that it is usual, as a minimal courtesy to the original
> dev/maintainer, and to avoid confusions, to use a different name.
>
> The change of name can be made in such a way that the connection with the
> original project is not completely lost, so that users are not completely
> confused.  Think, e.g., of GNU Emacs -> XEmacs, NetBSD -> OpenBSD...
>
> ---- SHORT STORY / PROPOSAL ----
>
> Since the first sentence already states that external packages remain under
> the control of their original dev/maintainer, I propose to remove the above
> sentence and simply write:
>
> "If an external package X is removed from Octave Forge, previous releases of
> the package will remain available on Octave Forge."
>
> and not discuss explicitly what happens next (scenarios A/B above, or any
> other variant).
>
> @++
> Julien
Sounds much better to me. We can discuss problems and their solutions
when they arrive.
Thanks!

Reply | Threaded
Open this post in threaded view
|

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

Olaf Till-2
In reply to this post by jbect
On Thu, Mar 09, 2017 at 01:54:01PM +0100, Julien Bect wrote:
> Since the first sentence already states that external packages remain under
> the control of their original dev/maintainer, I propose to remove the above
> sentence

Ok with me.

> and simply write:
>
> *"**If an external package X is removed from Octave Forge**, previous
> releases of the package will remain available on Octave Forge."
> *

But what has the latter sentence to do with the original issue? A
guaranty that previous releases will always be available? I think we
are not in a position to give such a guaranty, since we are only a
group of programmers, dependent on external infrastructure. And even
the persons in our group may change. We can't give many guarantees...

Can't we just remove the sentence without replacement?

Olaf

> and not discuss explicitly what happens next (scenarios A/B above, or any
> other variant).
>
> @++
> Julien

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

jbect
Le 09/03/2017 à 19:05, Olaf Till a écrit :
On Thu, Mar 09, 2017 at 01:54:01PM +0100, Julien Bect wrote:
Since the first sentence already states that external packages remain under
the control of their original dev/maintainer, I propose to remove the above
sentence
Ok with me.

and simply write:

*"**If an external package X is removed from Octave Forge**, previous
releases of the package will remain available on Octave Forge."
*
But what has the latter sentence to do with the original issue? A
guaranty that previous releases will always be available? I think we
are not in a position to give such a guaranty, since we are only a
group of programmers, dependent on external infrastructure. And even
the persons in our group may change. We can't give many guarantees...

Can't we just remove the sentence without replacement?


Yes we can (as far as I am concerned).

Reply | Threaded
Open this post in threaded view
|

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

Olaf Till-2
On Thu, Mar 09, 2017 at 08:01:18PM +0100, Julien Bect wrote:

> Le 09/03/2017 à 19:05, Olaf Till a écrit :
> >On Thu, Mar 09, 2017 at 01:54:01PM +0100, Julien Bect wrote:
> >>Since the first sentence already states that external packages remain under
> >>the control of their original dev/maintainer, I propose to remove the above
> >>sentence
> >Ok with me.
> >
> >>and simply write:
> >>
> >>*"**If an external package X is removed from Octave Forge**, previous
> >>releases of the package will remain available on Octave Forge."
> >>*
> >But what has the latter sentence to do with the original issue? A
> >guaranty that previous releases will always be available? I think we
> >are not in a position to give such a guaranty, since we are only a
> >group of programmers, dependent on external infrastructure. And even
> >the persons in our group may change. We can't give many guarantees...
> >
> >Can't we just remove the sentence without replacement?
>
>
> Yes we can (as far as I am concerned).
Ok. (Sigh of relief... that issue with avoiding giving guarantees
should have occured to me earlier.) Pushed a version with (hopefully)
all the changes discussed so far online.

Olaf

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Juan Pablo Carbajal-2
On Thu, Mar 9, 2017 at 8:35 PM, Olaf Till <[hidden email]> wrote:

> On Thu, Mar 09, 2017 at 08:01:18PM +0100, Julien Bect wrote:
>> Le 09/03/2017 à 19:05, Olaf Till a écrit :
>> >On Thu, Mar 09, 2017 at 01:54:01PM +0100, Julien Bect wrote:
>> >>Since the first sentence already states that external packages remain under
>> >>the control of their original dev/maintainer, I propose to remove the above
>> >>sentence
>> >Ok with me.
>> >
>> >>and simply write:
>> >>
>> >>*"**If an external package X is removed from Octave Forge**, previous
>> >>releases of the package will remain available on Octave Forge."
>> >>*
>> >But what has the latter sentence to do with the original issue? A
>> >guaranty that previous releases will always be available? I think we
>> >are not in a position to give such a guaranty, since we are only a
>> >group of programmers, dependent on external infrastructure. And even
>> >the persons in our group may change. We can't give many guarantees...
>> >
>> >Can't we just remove the sentence without replacement?
>>
>>
>> Yes we can (as far as I am concerned).
>
> Ok. (Sigh of relief... that issue with avoiding giving guarantees
> should have occured to me earlier.) Pushed a version with (hopefully)
> all the changes discussed so far online.
>
> Olaf
>
> --
> public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Excellent job Olaf and Julien, thanks!

Is there a way of posting pull requests to the octave forge webpages?
I think we need to reduce the click-distance to the repositories
(currently list of repositories is 2 clicks away from Octave Forge
mainpage) and I wouldn't like to impose this on you, since I can
handle some html.
Ideally also I would like to see a link to the code repositories in
the packages page: [Details, Download, Development (or Source, or
Repository)] currently only the first two; and on the package
description page (probably a new entry in the DESCRIPTION file,
"Code-Repository", "Code-Url" or something like that).

Cheers