octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Olaf Till
Subject: Re: Octave Forge: Package groups and properties defined, RFC.
Date: Thu, 9 Mar 2017 08:34:03 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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.

(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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]