Questions about canossa and LICENSE question #1
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.
As it currently stands, which library is responsible for what? I'm interested in knowing where you plan taking this.
The text was updated successfully, but these errors were encountered:
I regret that the README of sentimental-skk is unkind for non-Japanese people.
To implement Pinyin feature, some customizations will be required.
I basically prefer to release my software under copyleft license.
The default dictionaries of sentimental-skk is imported from Masahiko Sato et al./SKK Development Team's SKK dictionaries, which is licensed under GPL.
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.
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.
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)
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.
As reading some materials, I have understood that the trend of license is shifting to permissive from copyleft.
At the present time, I have decided to release next version of TFF under a permissive license.
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.
That is incredible news.
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.)
Now TFF / termprop / canossa take the following roles.
TFF - create and destroy sessions (pty devices).
If you want to write a terminal multiplexer like GNU Screen/tmux, It would be a separate project using canossa.
@saitoha That is incredibly helpful! Having tmux / screen in python could open up a lot of doors.
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. :)