mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #33] As a library #33
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#33
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JKSnd on GitHub (Nov 4, 2016).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/33
Originally assigned to: @NickeManarin on GitHub.
This could be a very powerful support tool if it could be included in a software project.
The idea as a workflow:
If such a library as screentogif.dll existed, and supported steps 3,4,6, and 7 then that would be stellar.
I'm sure we could pull the source and just do it in-house as a one-off, but everybody benefits when packages make it up to NuGet.
Thanks for considering!
@NickeManarin commented on GitHub (Nov 4, 2016):
This is an awesome idea!
@BobVul commented on GitHub (Jan 30, 2017):
If you do, please consider also dual-licensing with an additional licence, because MS-PL might not be GPL-compatible. Depending on how permissive you want to get, perhaps (one of) the LGPL or MIT licences.
@NickeManarin commented on GitHub (Jan 31, 2017):
Yes, I want to change the license of this project, but I have to read everything carefully.
@BobVul commented on GitHub (Jan 31, 2017):
Thanks! :)
I suggested dual-licensing instead of changing the existing one so existing users won't have to reevaluate the licence. Might make things easier.
@NickeManarin commented on GitHub (Jan 31, 2017):
Oh, I was thinking about switching to a license very close to the current one with the same reason in mind. :)
@JKSnd commented on GitHub (Feb 8, 2017):
That would be awesome! Especially since I'm not a pro at interpreting 3d of the Ms-Pl. What constitutes a compatible license? I'm not sure.
I'm a big fan of the MIT, for what it's worth.
Dual-licensing as a temporary way to smoothly transition may be a good option.
@vatterspun commented on GitHub (May 31, 2017):
To clarify, according to the GNU.ORG site, MS-PL is incompatible with the GPL.
Sounds great. Whatever you choose, make sure it includes something about patents (something the MS-Pl definitely gets right). So for example, Apache 2.0 does so while BSD and MIT do not.
I'm a fan of the GPL for a few reasons, but maybe the major one is that I like the idea of programs and their code living beyond their creators, where many "permissive" licenses can be taken in a fully closed source direction, as most notably happened in the case of Apple's Darwin and the Microsoft Windows networking stack.
ScreenToGif is one of the most active and interesting I've seen in a long time (and I've played with a LOT of animated GIF editors), so please don't let anyone influence you to select anything that will diminish your interest.
@vatterspun commented on GitHub (Jan 13, 2019):
This is far from a critical topic, but I did want to point out that - as Microsoft purchased Github - you can look at the top (pinned) projects from Microsoft and their open license right here on the site: https://github.com/microsoft/
I couldn't find any data on how popular the MS-Pl license is overall, but it's interesting that even Microsoft doesn't seem to be using it's own license. Maybe there's a reason for that?
@konard commented on GitHub (Oct 30, 2019):
There is another way to approach the same issue. We can record everything at the background for the last hour or two, and when something unexpected happens, we can save a recording. This way we save user time, and there is no need to reproduce anything. This approach is similar to how the black box works.
@NickeManarin commented on GitHub (Aug 8, 2020):
@Konard With the next version, there will be available a new capture mode, which only captures a frame when something actually changes within the capture region.
With this new feature, it will be possible to make long captures using less disk space.
@sharwell commented on GitHub (Nov 22, 2023):
Hi @NickeManarin,
We are very interested in using a library version of ScreenToGif as part of our product integration test pipeline. It sounds like you may be interested in having this feature be part of ScreenToGif itself, so I wanted to discuss this possibility with you and determine if it would be best to try and create the library separately (derived from this project) or work on it here as a new product feature for everyone. Looking forward to hearing your preference.
As a side note, IANAL but I have assisted other projects in license migration. If you are interested in migrating to another license, I'd be happy to explain the process we followed.
Thanks,
Sam