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: Juan Pablo Carbajal
Subject: Re: Octave Forge: Package groups and properties defined, RFC.
Date: Thu, 9 Mar 2017 11:46:01 +0100

Hi Julien,

I like your suggestiosn, little amends below

On Thu, Mar 9, 2017 at 10:43 AM, Julien Bect
<address@hidden> 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
>>>> <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).
>
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.

> @++
> 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 via email to

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