13 ms·

When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy wa

by gumby 3y ago

When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code. Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms; since one of the points of using unity is its cross-platform support, that suggests you’d have to find another library unless you were only deploying on real OSes. But is that Unity’s problem?

qwertox 3y ago
> But is that Unity’s problem? Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"
- tonmoy 3y ago
  So I could be missing something, but the editor itself is not getting shipped to iOS devices, only the resulting binaries are.
  - Vinnl 3y ago
    That sounds like the "and the runtime (which means your shipped game)" part?
    - doctorpangloss 3y ago
      Nobody in this thread has firmly pointed to LGPL code being linked or used in the iOS runtime in a Unity 2021 or later built game. Having not looked at this myself, I can't say either way, but it is almost certainly wrong to say that the runtime contains otherwise LGPL code that was not expressly licensed or permitted for the purpose by its authors.
  - voxic11 3y ago
    The resulting binaries depend on the unity runtime which itself depends on these LGPL components.
OmarAssadi 3y ago
Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code? I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind. Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love. For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own. Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar. I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software. I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers. Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar. EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc. [1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it. [2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.
captainmuon 3y ago
I've never understood the problem with (L)GPL code on iOS devices. Sure, users don't have the possibility to replace the code on that platform. But the restriction is not imposed by the people distributing the code, but by external circumstances (Apple). I can distribute LGPL licensed code to people no problem even if they are then, additionally, forbidden to actually excercise their freedoms by laws, think for example about radio code. I might have to get a special permission to run the code if I make changes and compile it, but that's no concern of the person licensing their source code to me. Same if, say, the code runs on a box in an inaccessible space, and in order to install their own binaries somebody would have to press a button that they can't reach. That's not a GPL violation. If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store. Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons. Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does explicitly forbid the above mentioned situations? (And of course this is just my reading as an interested layperson, you're the expert obviously :-))
- ffgjgf1 3y ago
  > I've never understood the problem with (L)GPL code on iOS devices AFAIK Apple just doesn’t allow apps which don’t that on the app store regardless of how the developer would chose to interpret the license
  - wahnfrieden 3y ago
    that's outdated info
    - BizarroLand 3y ago
      Your face is on backwards if you think it's acceptable to tell someone that their information is outdated without also providing the new and up to date information.
quotemstr 3y ago
The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived work" copyright status. Are we really supposed to believe that if non-copyleft code A is tightly coupled with copyleft code B, then the copyleft does propagate to A if we summon the ld-linux.so.2 demon for dynamic linking and doesn't propagate if A uses B via system(2) and a pipe? Ridiculous. Whether A is a derivative work of B has to do with the extent to which A is coupled to B in particular, not the mechanism of this coupling. Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work. Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?
- gumby 3y ago
  The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL. If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
  - quotemstr 3y ago
    > If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former. IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?
Y_Y 3y ago
For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1. Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity? [0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
- simiones 3y ago
  Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.
  - dagmx 3y ago
    Or they’ve dual licensed the libraries in question.
    - simiones 3y ago
      You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?
      - doctorpangloss 3y ago
        I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case. With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses. I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor. My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.
ffgjgf1 3y ago
> But is that Unity’s problem? Well: 1. Unity itself is using plenty of LGPL libraries itself so the same concerns apply. 2. If this is not an issue on desktop platforms where you can comply with LGPL there is nothing wrong with allowing such packages on the Asset Store. Certainly not all developers ship their Unity games on most platforms so it should be up to them to figure whether the specific package they decide to include can be used for a given platform.
- jillesvangurp 3y ago
  Using open source development tools is fine. What matters is what you distribute to end users (i.e. the output of those tools). I think the issue with unity is that VLC ends up being distributed as part of unity applications. I'm not a lawyer but this might indeed have some valid issues associated with it depending on how this is done. So, I can see an argument for Unity simply not wanting to put their customers in a situation where they have to worry about these issues. It seems a bit drastic though given how useful it is. Banning companies/accounts seems like it's simply unprofessional/rude and unnecessary. Sounds like they need to have a conversation with whomever thought that was a good idea about professional conduct.
  - ffgjgf1 3y ago
    > Using open source development tools is fine Yea but the article is claiming that Unity is including LGPL libraries in apps built with Unity, not just the editor itself.
freedomben 3y ago
> When I originally wrote the LGPL This might be the best opening line of a HN comment I've ever seen :-D Don't feel obligated to respond, but how do you feel about the LGPL now? How do you feel about it's evolution given the way the world has changed? Would you do anything differently now?
- qingcharles 3y ago
  It's basically the HN equivalent of "Well, when I first created the Earth in 7 days I didn't really imagine..."
  - Tommah 3y ago
    God made the world in six days, not seven, so try to be a little faster next time.
    - deleted 3y ago
      [deleted]
    - preciousoo 3y ago
      Depends on your denomination and the decade, it can be 6 or 7 days
- gumby 3y ago
  Well, TBH it didn’t have the impact I thought it might (and that RMS feared — obviously I disagreed with him). Libraries qua libraries aren’t distributed / sold so much any more as standalone packages and now we mostly have no-cost binary blobs tied to hardware or a priced API or MIT-ish-licensed stuff (like boost or npm), sadly neither of which empower any right to repair. That decade of Cygnus was a lot of hard yakka first to legitimize the idea of free software at all (in 1989 it was mostly both obscure and insane outside academia) and then popularize it. Obviously other people started working hard on this too later in the decade. The thing that made probably the most significant difference was the process of forking gcc which was a lot of negotiation — at that time forking a code base was widely considered a tragedy, despite the whole structure of free software!). Making forking good rather than a tragedy, coming up with an independent steering committee, and in that case getting the FSF to stop complaining decide to try to run out in front of the parade* was really hard but in the long term it became an approach that most important open source projects have taken, providing stability and progress. That’s definitely been an opment! And then within a few years…I was on to other, more important things. It felt like the free software / open source world was no longer an embryo so didn’t need me. Plenty of other people are doing great work, better than I would have the enthusiasm for these days. * Yes yet another case where RMS was furious about something that in the long term was a big win for the FSF too.
kazinator 3y ago
Cygwin switched to the LGPL back in 2016. That's very useful; it means there is a POSIX run-time on Windows that programs using a wide range of licensing schemes can use. When I saw the announcement on the Cygwin mailing list, I immediately set off to make a fork of the main Cygwin DLL which brings Windows-like behaviors. https://www.kylheku.com/cygnal/ https://www.kylheku.com/cygnal/

by gumby 3y ago

qwertox 3y ago

> But is that Unity’s problem? Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"

tonmoy 3y ago
So I could be missing something, but the editor itself is not getting shipped to iOS devices, only the resulting binaries are.
- Vinnl 3y ago
  That sounds like the "and the runtime (which means your shipped game)" part?
  - doctorpangloss 3y ago
    Nobody in this thread has firmly pointed to LGPL code being linked or used in the iOS runtime in a Unity 2021 or later built game. Having not looked at this myself, I can't say either way, but it is almost certainly wrong to say that the runtime contains otherwise LGPL code that was not expressly licensed or permitted for the purpose by its authors.
- voxic11 3y ago
  The resulting binaries depend on the unity runtime which itself depends on these LGPL components.

OmarAssadi 3y ago

Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code? I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind. Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love. For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own. Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar. I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software. I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers. Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar. EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc. [1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it. [2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.

captainmuon 3y ago

I've never understood the problem with (L)GPL code on iOS devices. Sure, users don't have the possibility to replace the code on that platform. But the restriction is not imposed by the people distributing the code, but by external circumstances (Apple). I can distribute LGPL licensed code to people no problem even if they are then, additionally, forbidden to actually excercise their freedoms by laws, think for example about radio code. I might have to get a special permission to run the code if I make changes and compile it, but that's no concern of the person licensing their source code to me. Same if, say, the code runs on a box in an inaccessible space, and in order to install their own binaries somebody would have to press a button that they can't reach. That's not a GPL violation. If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store. Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons. Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does explicitly forbid the above mentioned situations? (And of course this is just my reading as an interested layperson, you're the expert obviously :-))

ffgjgf1 3y ago
> I've never understood the problem with (L)GPL code on iOS devices AFAIK Apple just doesn’t allow apps which don’t that on the app store regardless of how the developer would chose to interpret the license
- wahnfrieden 3y ago
  that's outdated info
  - BizarroLand 3y ago
    Your face is on backwards if you think it's acceptable to tell someone that their information is outdated without also providing the new and up to date information.

quotemstr 3y ago

The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived work" copyright status. Are we really supposed to believe that if non-copyleft code A is tightly coupled with copyleft code B, then the copyleft does propagate to A if we summon the ld-linux.so.2 demon for dynamic linking and doesn't propagate if A uses B via system(2) and a pipe? Ridiculous. Whether A is a derivative work of B has to do with the extent to which A is coupled to B in particular, not the mechanism of this coupling. Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work. Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?

gumby 3y ago
The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL. If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
- quotemstr 3y ago
  > If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former. IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?

Y_Y 3y ago

For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1. Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity? [0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

simiones 3y ago
Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.
- dagmx 3y ago
  Or they’ve dual licensed the libraries in question.
  - simiones 3y ago
    You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?
    - doctorpangloss 3y ago
      I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case. With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses. I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor. My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.

ffgjgf1 3y ago

> But is that Unity’s problem? Well: 1. Unity itself is using plenty of LGPL libraries itself so the same concerns apply. 2. If this is not an issue on desktop platforms where you can comply with LGPL there is nothing wrong with allowing such packages on the Asset Store. Certainly not all developers ship their Unity games on most platforms so it should be up to them to figure whether the specific package they decide to include can be used for a given platform.

jillesvangurp 3y ago
Using open source development tools is fine. What matters is what you distribute to end users (i.e. the output of those tools). I think the issue with unity is that VLC ends up being distributed as part of unity applications. I'm not a lawyer but this might indeed have some valid issues associated with it depending on how this is done. So, I can see an argument for Unity simply not wanting to put their customers in a situation where they have to worry about these issues. It seems a bit drastic though given how useful it is. Banning companies/accounts seems like it's simply unprofessional/rude and unnecessary. Sounds like they need to have a conversation with whomever thought that was a good idea about professional conduct.
- ffgjgf1 3y ago
  > Using open source development tools is fine Yea but the article is claiming that Unity is including LGPL libraries in apps built with Unity, not just the editor itself.

freedomben 3y ago

> When I originally wrote the LGPL This might be the best opening line of a HN comment I've ever seen :-D Don't feel obligated to respond, but how do you feel about the LGPL now? How do you feel about it's evolution given the way the world has changed? Would you do anything differently now?

qingcharles 3y ago
It's basically the HN equivalent of "Well, when I first created the Earth in 7 days I didn't really imagine..."
- Tommah 3y ago
  God made the world in six days, not seven, so try to be a little faster next time.
  - deleted 3y ago
    [deleted]
  - preciousoo 3y ago
    Depends on your denomination and the decade, it can be 6 or 7 days
gumby 3y ago
Well, TBH it didn’t have the impact I thought it might (and that RMS feared — obviously I disagreed with him). Libraries qua libraries aren’t distributed / sold so much any more as standalone packages and now we mostly have no-cost binary blobs tied to hardware or a priced API or MIT-ish-licensed stuff (like boost or npm), sadly neither of which empower any right to repair. That decade of Cygnus was a lot of hard yakka first to legitimize the idea of free software at all (in 1989 it was mostly both obscure and insane outside academia) and then popularize it. Obviously other people started working hard on this too later in the decade. The thing that made probably the most significant difference was the process of forking gcc which was a lot of negotiation — at that time forking a code base was widely considered a tragedy, despite the whole structure of free software!). Making forking good rather than a tragedy, coming up with an independent steering committee, and in that case getting the FSF to stop complaining decide to try to run out in front of the parade* was really hard but in the long term it became an approach that most important open source projects have taken, providing stability and progress. That’s definitely been an opment! And then within a few years…I was on to other, more important things. It felt like the free software / open source world was no longer an embryo so didn’t need me. Plenty of other people are doing great work, better than I would have the enthusiasm for these days. * Yes yet another case where RMS was furious about something that in the long term was a big win for the FSF too.

kazinator 3y ago

Cygwin switched to the LGPL back in 2016. That's very useful; it means there is a POSIX run-time on Windows that programs using a wide range of licensing schemes can use. When I saw the announcement on the Cygwin mailing list, I immediately set off to make a fork of the main Cygwin DLL which brings Windows-like behaviors. https://www.kylheku.com/cygnal/ https://www.kylheku.com/cygnal/