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

[Julien Bect]

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 <address@hidden> wrote:
> > > > > On 8 Mar 2017, at 10:21, Olaf Till <address@hidden> 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