[gentoo-dev] terminal spreadsheet - sc fork

[gentoo-dev] terminal spreadsheet - sc fork

[Andrés Martinelli]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

Hello there!!
I am working on a terminal spreadsheet based on "sc", but with some adds
like undo/redo..
you can find it here:

https://github.com/andmarti1424/scim

Any new ideas and/or contribution is always welcome!
Thanks!
-- 
Andrés M.

[-- Attachment #2: Type: text/html, Size: 729 bytes --]

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Peter Stuge]

Andrés Martinelli wrote:
> I am working on a terminal spreadsheet based on "sc", but with some adds
> like undo/redo..
> you can find it here:
> 
> https://github.com/andmarti1424/scim
> 
> Any new ideas and/or contribution is always welcome!

See also teapot. Right, an undo stack is a nice feature.


//Peter

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Matthias Maier]

Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli <andmarti@gmail.com>:

> I am working on a terminal spreadsheet based on "sc", but with some
> adds like undo/redo..
> you can find it here:
>
> https://github.com/andmarti1424/scim
>
> Any new ideas and/or contribution is always welcome!

Just out of curiosity.

The original sc program is public domain [1].

You have chosen to relicense your fork of the codebase under a custom
license that you labeled "SCIM license".

A quick peek at the license [2] reveals quite a cumbersome number of
issues (forced contact, contact possibility, redistribution in form of
tarballs and patches). Such a license usually prevents any meaningful
number of external contributions and packaging. Not to mention that
layman's licenses are almost always fundamentally flawed.

Why not using an FSF-approved, OSI-approved, and/or DFSG compatible
license instead? I'm sure that there is something available that fits
your taste. (You can e.g. license under "GPL 2 or later" and ask for a
special (non binding) courtesy to inform you of changes/patches.)

Best,
Matthias

[1] http://metadata.ftp-master.debian.org/changelogs//main/s/sc/sc_7.16-3_copyright
[2] https://github.com/andmarti1424/scim/blob/master/LICENSE

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Andrés Martinelli]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

Hello there. Thanks for your time and taking a look at the app.

About the license, my idea was to start scim with its own license, and keep
it as simple as could be, but keeping in line with the points mentioned in
it.
I believe it will always suit best something particular and written for it,
than something more general, but take in mind that this license can suffer
modifications since this project is just starting! Since SCIM can be
modified and redistributed with other license, such as any other GPL
compatible, I believe is not as restrictive as it seems.
Please, I am interested in hearing what points you dislike or consider are
restrictive.
Thanks!

2014-11-03 9:01 GMT-03:00 Matthias Maier <tamiko@gentoo.org>:

>
> Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli <andmarti@gmail.com>:
>
> > I am working on a terminal spreadsheet based on "sc", but with some
> > adds like undo/redo..
> > you can find it here:
> >
> > https://github.com/andmarti1424/scim
> >
> > Any new ideas and/or contribution is always welcome!
>
> Just out of curiosity.
>
> The original sc program is public domain [1].
>
> You have chosen to relicense your fork of the codebase under a custom
> license that you labeled "SCIM license".
>
> A quick peek at the license [2] reveals quite a cumbersome number of
> issues (forced contact, contact possibility, redistribution in form of
> tarballs and patches). Such a license usually prevents any meaningful
> number of external contributions and packaging. Not to mention that
> layman's licenses are almost always fundamentally flawed.
>
> Why not using an FSF-approved, OSI-approved, and/or DFSG compatible
> license instead? I'm sure that there is something available that fits
> your taste. (You can e.g. license under "GPL 2 or later" and ask for a
> special (non binding) courtesy to inform you of changes/patches.)
>
> Best,
> Matthias
>
> [1]
> http://metadata.ftp-master.debian.org/changelogs//main/s/sc/sc_7.16-3_copyright
> [2] https://github.com/andmarti1424/scim/blob/master/LICENSE
>
>


-- 
Andrés Martinelli

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Diego Elio Pettenò]

Beside being off-topic. And beside SCIM being a well-known opensource
projector for IME.

If you're inventing a new license, that's simply wrong.
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


On 3 November 2014 13:24, Andrés Martinelli <andmarti@gmail.com> wrote:
> Hello there. Thanks for your time and taking a look at the app.
>
> About the license, my idea was to start scim with its own license, and keep
> it as simple as could be, but keeping in line with the points mentioned in
> it.
> I believe it will always suit best something particular and written for it,
> than something more general, but take in mind that this license can suffer
> modifications since this project is just starting! Since SCIM can be
> modified and redistributed with other license, such as any other GPL
> compatible, I believe is not as restrictive as it seems.
> Please, I am interested in hearing what points you dislike or consider are
> restrictive.
> Thanks!
>
> 2014-11-03 9:01 GMT-03:00 Matthias Maier <tamiko@gentoo.org>:
>
>>
>> Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli <andmarti@gmail.com>:
>>
>> > I am working on a terminal spreadsheet based on "sc", but with some
>> > adds like undo/redo..
>> > you can find it here:
>> >
>> > https://github.com/andmarti1424/scim
>> >
>> > Any new ideas and/or contribution is always welcome!
>>
>> Just out of curiosity.
>>
>> The original sc program is public domain [1].
>>
>> You have chosen to relicense your fork of the codebase under a custom
>> license that you labeled "SCIM license".
>>
>> A quick peek at the license [2] reveals quite a cumbersome number of
>> issues (forced contact, contact possibility, redistribution in form of
>> tarballs and patches). Such a license usually prevents any meaningful
>> number of external contributions and packaging. Not to mention that
>> layman's licenses are almost always fundamentally flawed.
>>
>> Why not using an FSF-approved, OSI-approved, and/or DFSG compatible
>> license instead? I'm sure that there is something available that fits
>> your taste. (You can e.g. license under "GPL 2 or later" and ask for a
>> special (non binding) courtesy to inform you of changes/patches.)
>>
>> Best,
>> Matthias
>>
>> [1]
>> http://metadata.ftp-master.debian.org/changelogs//main/s/sc/sc_7.16-3_copyright
>> [2] https://github.com/andmarti1424/scim/blob/master/LICENSE
>>
>
>
>
> --
> Andrés Martinelli

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

>>>>> On Mon, 03 Nov 2014, Matthias Maier wrote:

> You have chosen to relicense your fork of the codebase under a custom
> license that you labeled "SCIM license".

> A quick peek at the license [2] reveals quite a cumbersome number of
> issues (forced contact, contact possibility, redistribution in form of
> tarballs and patches). Such a license usually prevents any meaningful
> number of external contributions and packaging. Not to mention that
> layman's licenses are almost always fundamentally flawed.

AFAICS, this is identical to the vim license, but with clause
II) 2) e) removed. (Which makes the sentence "must be distributed in
one of the following five ways" flawed, because now there are only
four ways a) to d) left.)

> Why not using an FSF-approved, OSI-approved, and/or DFSG compatible
> license instead? I'm sure that there is something available that fits
> your taste. (You can e.g. license under "GPL 2 or later" and ask for a
> special (non binding) courtesy to inform you of changes/patches.)

The vim license is approved by the FSF:
https://www.gnu.org/licenses/license-list.html#Vim

Most likely it will remain a free software license even after removal
of above-mentioned clause, but certainly it is no longer GPL
compatible.

Otherwise, I agree that using one of the existing free software
licenses would be much preferred. License proliferation is a real
problem.

Ulrich


> [2] https://github.com/andmarti1424/scim/blob/master/LICENSE

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Andrés Martinelli]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Yes, Vim license was the base of it, as I noticed, at least by now, that it
meets the requirements I thought necessary. About that mistake, thanks for
noticing it. It will be corrected.

As I said earlier, I am interested in getting different people feedback
about each item of the license, and if anyone consider something could be
added and/or modified in any way, I would be glad to hear about it.
Thanks again!

2014-11-03 16:00 GMT-03:00 Ulrich Mueller <ulm@gentoo.org>:

> >>>>> On Mon, 03 Nov 2014, Matthias Maier wrote:
>
> > You have chosen to relicense your fork of the codebase under a custom
> > license that you labeled "SCIM license".
>
> > A quick peek at the license [2] reveals quite a cumbersome number of
> > issues (forced contact, contact possibility, redistribution in form of
> > tarballs and patches). Such a license usually prevents any meaningful
> > number of external contributions and packaging. Not to mention that
> > layman's licenses are almost always fundamentally flawed.
>
> AFAICS, this is identical to the vim license, but with clause
> II) 2) e) removed. (Which makes the sentence "must be distributed in
> one of the following five ways" flawed, because now there are only
> four ways a) to d) left.)
>
> > Why not using an FSF-approved, OSI-approved, and/or DFSG compatible
> > license instead? I'm sure that there is something available that fits
> > your taste. (You can e.g. license under "GPL 2 or later" and ask for a
> > special (non binding) courtesy to inform you of changes/patches.)
>
> The vim license is approved by the FSF:
> https://www.gnu.org/licenses/license-list.html#Vim
>
> Most likely it will remain a free software license even after removal
> of above-mentioned clause, but certainly it is no longer GPL
> compatible.
>
> Otherwise, I agree that using one of the existing free software
> licenses would be much preferred. License proliferation is a real
> problem.
>
> Ulrich
>
>
> > [2] https://github.com/andmarti1424/scim/blob/master/LICENSE
>



-- 
Andrés Martinelli

[-- Attachment #2: Type: text/html, Size: 2853 bytes --]

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Luca Barbato]

On 03/11/14 20:24, Andrés Martinelli wrote:
> Yes, Vim license was the base of it, as I noticed, at least by now, that it
> meets the requirements I thought necessary. About that mistake, thanks for
> noticing it. It will be corrected.
>

Just:

- change the name, it conflicts with another package.
- use AGPLv3 + as many exceptions as you like if you want something 
special, who doesn't agree with them has to stay with the vanilla agpl3 
with all its forced "freedom".
- I'd advise to stay with LGPL though. (it is actually GPL3+exceptions 
as well)

I hope it helps.

lu

Re: [gentoo-dev] terminal spreadsheet - sc fork

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

>>>>> On Tue, 04 Nov 2014, Luca Barbato wrote:

> - use AGPLv3 + as many exceptions as you like if you want something
> special, who doesn't agree with them has to stay with the vanilla
> agpl3 with all its forced "freedom".

I disagree. AGPL-3 only makes sense for programs that directly
interact with users via a web server or similar. Using it for other
packages can lead to awkward situations. (If you want an example,
we're currently bitten by Oracle's inappropriate use of AGPL-3 for
sys-libs/db:6.0 [1].)

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=525110

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: terminal spreadsheet - sc fork

[Duncan]

Ulrich Mueller posted on Tue, 04 Nov 2014 12:51:54 +0100 as excerpted:

>>>>>> On Tue, 04 Nov 2014, Luca Barbato wrote:
> 
>> - use AGPLv3 + as many exceptions as you like if you want something
>> special, who doesn't agree with them has to stay with the vanilla agpl3
>> with all its forced "freedom".
> 
> I disagree. AGPL-3 only makes sense for programs that directly interact
> with users via a web server or similar. Using it for other packages can
> lead to awkward situations. (If you want an example, we're currently
> bitten by Oracle's inappropriate use of AGPL-3 for sys-libs/db:6.0 [1].)
> 
> Ulrich
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=525110

I think that was the intention.

The suggestion was that if you want a lot of otherwise custom 
restrictions, to avoid license proliferation start with something like 
the AGPLv3+ that's recognized as a standard free license but ends up 
being impractical for many, and then add further liberating exceptions as 
you like.  Because the AGPLv3 is a recognized standard free license even 
if restricted for many in practice, and the exceptions only add 
additional freedoms, anyone who doesn't like them or doesn't want to 
legally review them can take the already well reviewed AGPLv3 only, while 
the exceptions do reduce the normal restrictions of the AGPLv3 in certain 
additional areas, for those who want/need them.

Because the AGPLv3 is already both lawyer reviewed and accepted as a 
standard free license, that'll solve several issues at once, being 
unlikely to have the loopholes or internal conflicts that layman-created 
licenses without sufficient lawyer review often have, being accepted as a 
standard free license, allowing distros to do their distro thing without 
too much additional hassle because it's a license they're familiar with, 
etc.  But at the same time it's restrictive enough that it tends to 
prevent a lot of code sharing, like the custom license alternative it 
replaces, and a license exception can be fashioned to encourage 
distribution of patches as separate tarballs, etc, as necessary.  
Assuming there's a proprietary license available for those wishing to 
purchase it and be freed of the restrictions otherwise imposed by the 
AGPLv3, the choice of AGPLv3 for those not choosing to purchase the 
proprietary license may be seen as appropriate indeed.

And given Oracle's history of deliberate choice of incompatible licenses 
in other areas I strongly suspect the "inappropriate choice" of the AGPLv3 
in this area was deliberate obstructionism as well.  IOW, given Oracle's 
goals, they very likely see the AGPLv3 as an /entirely/ appropriate 
choice for this product, as evidenced by their active enforcement 
activities.  Who care's about the unpaid user?  Certainly Oracle doesn't 
seem too much concerned about inconveniencing them.  They're unpaid and 
thus generate no revenue, after all!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman