Questions about canossa and LICENSE question

[tony]

@saitoha Greetings,

In the image above, I see a pane within a pane. Can this do the same functionality potentially as tmux? Can a 256-color vim be used in inside of one of those windows?

Do you intend on IME support extending to other languages also? I am interested in having Pinyin.

I noticed the License of the current related projects being GPL. This would mean that other projects with BSD, MIT, etc. Would you consider changing it to MIT or BSD?

As it currently stands, which library is responsible for what? I'm interested in knowing where you plan taking this.

[saitoha]

Hi, @tony

Can this do the same functionality potentially as tmux?

Yes.

Can a 256-color vim be used in inside of one of those windows?

Yes.

I regret that the README of sentimental-skk is unkind for non-Japanese people. I will write how to use this software in the near future.

Do you intend on IME support extending to other languages also? I am interested in having Pinyin.

To implement Pinyin feature, some customizations will be required. I guess it is not hard to do this work.

I noticed the License of the current related projects being GPL. This would mean that other projects with BSD, MIT, etc. Would you consider changing it to MIT or BSD?

I basically prefer to release my software under copyleft license. But with regard to TFF, I am considering to re-license it with other one.

The default dictionaries of sentimental-skk is imported from Masahiko Sato et al./SKK Development Team's SKK dictionaries, which is licensed under GPL. and the basic idea and features of SKK(simple kana kanji conversion) and some default settings(such as kana-conversion rules) are derived from Daredevil SKK(http://openlab.ring.gr.jp/skk/ddskk.html), which is licensed under GPL. So this software should be licensed under GPL, too.

termprop consists from my original code, but its core technique(idea of terminal detection) is strongly influenced by Unicode text editor MinEd, which is licensed under GPL. So I am licensing it under GPL now.

TFF is written by me from scratch. I am considering to change its license to MPL/GPL/LGPL triple license, or more permissive one.

Canossa is also written by me from scratch. But it depends on TFF and termprop, and it is depended by sentimental-skk. I have to determine its license to keep consistency of them.

[tony]

@saitoha:

Thank you for your response!

I grew up using Linux. Like many linux users there is a comfort with GNU and the GPL. There is a belief because of the success of Linux and the GNU tools that copyleft is very virtuous. I used to "rubber stamp" gpl on software, and considered myself to be ensuring contribution upstream and prevent nefarious entities from making millions from an effort meant to provide a tool for everyone, especially those like myself who could not afford to buy special software.

I am trying to bring a successor to tmux and vim in python to a reality because python (3), curses, vim, etc. is superior.

Important to this is seeing that effort isn't duplicated and software can re-use code from these efforts as they wish.

Copyleft licenses separate and fork effort as that MIT, BSD, Apache licensed software can't utilize them.

From a purely python perspective, even LGPL can complicate things because of the ambiguity in the language of the license. As an example, [Twisted]() had this issue mentioned in their mailing list, the author responded LGPL doesn't make any sense (in terms of python) and he would switch to MIT. It's worth it to read his whole post to understand his reasoning.

Permissive licenses are prevalent in python. This isn't to say that Python there isn't GPL software, but I found this:

Academic Free License (AFL) (20) Apache Software License (1563) Artistic License (39) Attribution Assurance License (2) BSD License (7247) Common Public License (3) Eiffel Forum License (1) European Union Public Licence 1.0 (EUPL 1.0) (1) European Union Public Licence 1.1 (EUPL 1.1) (14) GNU Affero General Public License v3 (521) GNU Affero General Public License v3 or later (AGPLv3+) (64) GNU Free Documentation License (FDL) (3) GNU General Public License (GPL) (4060) GNU General Public License v2 (GPLv2) (180) GNU General Public License v2 or later (GPLv2+) (70) GNU General Public License v3 (GPLv3) (482) GNU General Public License v3 or later (GPLv3+) (350) GNU Lesser General Public License v2 (LGPLv2) (32) GNU Lesser General Public License v2 or later (LGPLv2+) (39) GNU Lesser General Public License v3 (LGPLv3) (74) GNU Lesser General Public License v3 or later (LGPLv3+) (91) GNU Library or Lesser General Public License (LGPL) (1007) ISC License (ISCL) (197) MIT License (5488) Mozilla Public License 1.0 (MPL) (15) Mozilla Public License 1.1 (MPL 1.1) (34) Mozilla Public License 2.0 (MPL 2.0) (72) Open Group Test Suite License (1) Python License (CNRI Python License) (46) Python Software Foundation License (347) Sleepycat License (1) Sun Public License (1) University of Illinois/NCSA Open Source License (5) W3C License (11) Zope Public License (930) zlib/libpng License (38)

GPL licensed software (including LGPL) 521 + 64, +3 + 4060 + 180 + 70 + 482 + 350 + 32 + 39 + 74 + 91 + 1007 = 6973

Then there is Apache, MIT and BSD licensed code. I didn't expect to see these numbers - since GPL has far more appeal rooted of the success of GNU and habit from people growing up using GPL software. On some level, I feel permissive licenses are become more well known, but also that permissive licenses are a better fit because of the way python works.

Would you consider licensing your software under MIT or BSD if MinEd and sentimental-skk were to allow a permissive license?

[saitoha]

As reading some materials, I have understood that the trend of license is shifting to permissive from copyleft. Now I am reflecting on my attitude that "rubber stamp" GPL on my software. I also understood that, to apply LGPL for Python libraries can cause some confusions by the lack of the concept of "link" in Python.

At the present time, I have decided to release next version of TFF under a permissive license. Because now I realize what I really want is not freedom, but feedback. For my software field(terminal emulation), I feel that the best way to gain feedback, may be not freedom, but reusability, especially in the trend of modern software community.

It is not yet determined for the other my software now. But in my interpretation, it is possible to release termprop and canossa under a permissive license. I will consider about this matter.

Would you consider licensing your software under MIT or BSD if MinEd and sentimental-skk were to allow a permissive license?

yes.

[saitoha]

Now TFF 0.2.0, termprop 0.1.0 and canossa 0.1.0 are distributed under MIT License. https://pypi.python.org/pypi/tff https://pypi.python.org/pypi/termprop https://pypi.python.org/pypi/canossa

[tony]

@saitoha

That is incredible news.

Awesome.

Can this do the same functionality as tmux?

On that front - I have to dig in to see how much Canossa covers.

If there was an effort to recreate tmux in python, what role should canossa take? How high level is canossa meant to be? Would it be a separate project using canossa? A patch to canossa?

A tmux clone would consist of Sessions, Windows, Panes. Tiling. Resizing. Like http://github.com/tony/tmuxp, I'd make JSON/YAML configs and session freezing. I imagine canossa could easily go above and beyond what tmux currently offers.

(I will mark this LICENSE issue as resolved.)

[saitoha]

If there was an effort to recreate tmux in python, what role should canossa take? How high level is canossa meant to be? Would it be a separate project using canossa? A patch to canossa?

Now TFF / termprop / canossa take the following roles.

TFF - create and destroy sessions (pty devices). termprop - abstract differences among real terminals (correspond to terminfo). canossa - provides basic terminal emulation service (screen objects), partial drawing functions, and some widgets (iframe and popup window objects).

If you want to write a terminal multiplexer like GNU Screen/tmux, It would be a separate project using canossa. And if you do it, you need to consider the following materials:

• Drawing Canossa only provides basic drawing functions, which draw itself to specified rectangular area. If you want to draw borders of pane, status bar, tab bar ...and so on, you have to do it yourself.
• Daemonize Now TFF is not call setsid(2) for becoming a daemon process. If we want to implement attach / detach feature, we have to extend TFF as supporting daemonize.
• Performance Now Canossa has performance problem. You feel the emulation of Canossa is slow compared with GNU Screen or tmux.
• Scroll-back buffer Now Canossa does not implement scroll-back buffer, because I just did not need it yet.
• Documentation Now Canossa lacks its documentation.
• terminfo compatibility Canossa is not compatible with terminfo. it often uses hard-coded escape sequences. I abandon terminfo and use termprop instead, because I feel that terminfo does not resolve real problems of terminal compatibility.

[tony]

@saitoha That is incredibly helpful! Having tmux / screen in python could open up a lot of doors.

• Daemon-izing: I found this to be a starting point: http://stackoverflow.com/questions/473620/how-do-you-create-a-daemon-in-python, http://www.python.org/dev/peps/pep-3143/

  I note tmux uses a Loop for a server and a signal system (libevent now). Twisted, Tornado, Gevent may be worth looking into.

• Drawing: I have to understand curses and the mechanics of how the CLI works works more deeply.
• Documentation: Understood. I (any definitely many) still have to fill in the essentials of how terminfo and etc work. I wonder if there are any good places to find reading material on this niche lying around anywhere. Or parts/sections of open source projects to refer to (https://github.com/freebsd/freebsd-head/blob/master/lib/ncurses/ncurses/termcap.c on the right track?)
• terminfo compatibility: I will also look into studying this more.

If you come to a decision on any of these, please let me know. If I try to implement something in the future I will show you a branch. :)

edit: spelling