notty author here. notty is basically way down a yakstack for me - I wanted better CLI/TUI tools, so I wanted to write a framework for writing CLI/TUI tools, but some of the features I wanted aren't supported by terminals, so I started writing a new terminal. But I don't know anything about graphics programming & this is really far away from what I actually wanted to be doing - so when jwilm showed me alacritty & mentioned implementing notty with it I was pretty stoked.
That is not how Copyleft software licenses work at all. All the AGPL gurantees is that 'Bigco' must contribute back to the community any modifications they make to the software.
Exactly! How many bigco's have a terminal emulator incorporated into a product? If you're just using this to run tmux, vim, etc. the AGPL's strengthened sharing provisions aren't going to affect you at all :-)
I was just pointing out that regardless of modification/distribution/whatever, bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company.
The author(s) are free to use AGPL, but there are significant downsides if they care about adoption.
> bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company."
Wait, that seems extremely paranoid, even if only meant figuratively... Can you explain the thinking on restricting the use of AGPL'd licensed applications?
It's a very common company policy, because it's 'never use GPL' is a much easier rule to follow than 'only use GPL when it doesnt expose the company to risk'. Programmers aren't lawyers.
Is that true? My understanding of the AGPL was that any software product which uses it as a component becomes subject to the AGPL - it has the linking semantics of the GPL, not the LGPL. If that's not the case, please do disabuse me of my misconception!
Yes, it is like the GPL. But in this case, where the product is a standalone application, that distinction shouldn't matter unless you're actually planning on bundling it into your own product somehow.
The problem is that "outside of the company" can be murky. What if the company outsources? What if the company hires contractors? What if the company employs an intern - does the intern now have the right to distribute the software?
These are the legal landmines that BigCos want to avoid, mainly because they're questions that have not really been decided.
That only addresses part of the reason for the policy. Please, you have to be aware the legal world and companies is very complicated, and smart people spend a lot of time analyzing this.
"Integration into your products" is too narrow. For example, AGPL may mean that contractors who use company internal web services must be given access to the source code of those services. That's a frightening prospect for companies.
I meant use more in "install and use, maybe fix a few bugs", which is what I'd primarily expect for a terminal emulator. It's not the kind of software you're likely going to specially interface with your systems, unless you ship it with your own OS.
I think you make a good point in this instance, so I upvoted. The follow-on discussion establishes the policy of big-cos pretty well and I don't think Alacritty much benefits from the AGPL since actual integration into other software base is unlikely (except for some of the sub-libs perhaps, but personally I feel that fundamental libraries flourish better under less-restrictive licenses anyway)