Distribution terms for TurboActivate libraries and TurboActivate.h file?Answered

Hello,

I asked this already via reply to the signup e-mail for your service a few days ago, but so far did not receive a response, so trying here again. What are the distribution terms for the TurboActivate libraries and TurboActivate.h header files? After downloading the package I could not find a file with license terms, neither on the forum or your docs. The TurboActivate.h file also does not contain any header with copyright info or redistribution & use terms?

We want to use LimeLM for an open-source project that is hosted with its full source code in a public GitHub repository, so people could continue to have the source code for free and build executables themselves, but the executable binaries we build/ship/support from GitHub would require a LimeLM product key.

For this we obviously need to upload the TurboActivate dynamic libraries into our GitHub repository for redistribution, but also to simplify build setup, ideally add the TurboActivate.h header file to our public GitHub repo. I wanted to make sure this is ok.

Thanks.

Answer

Hey Mario,

The the header and any source files aren't licensed to be posted publicly (or to be relicensed). You can obviously include the compiled libraries (TurboActivate, TurboFloat) with your compiled version of your app.

The best way to get around this problem is to have simple defines that control whether the header is included or not.

Hi Wyatt, thanks for the quick reply.

So TurboActivate.h must not show up on our GitHub, but can only be locally stored on the build machines, which also excludes easy building from within a public CI. That is a bit puzzling to me, given that the header doesn't contain any secret info one couldn't learn from your online docs, or from the open-source code that actually calls the functions defined in the header. But ok.

It is fine though to use the Example.c code as basis to build our own functionality, ie. use modified bits of that code to build our own integration? Iow. I don't have to retype everything from scratch?

What about TurboActivate.lib for Windows? Ok to upload or not?

And the compiled binary TurboActivate.dylib, TurboActivate.dll and TurboActivate.so can go into our GitHub repo, which we also use for distribution of the compiled executables. The “app” is actually a set of dynamically loadable plugins for another host application. That makes sense, because otherwise one couldn't use dynamic linking at all.

What about TurboActivate.lib for Windows? Ok to upload or not?

No, neither are the static libraries.

It is fine though to use the Example.c code as basis to build our own functionality, ie. use modified bits of that code to build our own integration? Iow. I don't have to retype everything from scratch?

Yes, that's fine.

That is a bit puzzling to me, given that the header doesn't contain any secret info one couldn't learn from your online docs, or from the open-source code that actually calls the functions defined in the header. But ok.

It's to control the flow of information as much as we can. We don't want customers to get files from outside sources (it increases our support costs).

Also, Microsoft / Github violates copyright by ingesting all code and documentation into it's generative-slop algorithms (they call “AI”). This is a standing issue that will be resolved by courts once the courts aren't filled with geriatrics.

We own the copyright to all words written in that file. But Microsoft / Github doesn't care (and they won't care until they're forced to care / pay). But as long as they can steal data without consequence, they will.

So TurboActivate.h must not show up on our GitHub, but can only be locally stored on the build machines, which also excludes easy building from within a public CI.

Putting non-open source code in a public repository is atypical.

Ok. So we will only commit the dynamic libraries TurboActivate.dylib, TurboActivate.dll and TurboActivate.so into our public GitHub repo. We use the stuff in our repo also for distribution of our compiled executables, not only the source code. Users can either git clone the ready-to-use toolbox onto their machines, or download zip files generated by the GitHub Actions CI system. Inclusion of the dynamic libraries into our GitHub repo is ok, according to your previous statements, right?

Is there any specific text blurb we should add to mention the use of your product, e.g., in our License.txt file? I could not find any proper license file for your software anywhere.

So we will only commit the dynamic libraries TurboActivate.dylib, TurboActivate.dll and TurboActivate.so into our public GitHub repo.

No, the binary files can be included with your final packaged app. Not included in a repository. Not the header / integration files either.

Is there any specific text blurb we should add to mention the use of your product, e.g., in our License.txt file? I could not find any proper license file for your software anywhere.

Nope, no attribution is needed. Our terms and conditions are what you agree to when you sign up.

, edited

Ok, this is really bad for us. I just spent over a month integrating LimeLM's TurboActivate into our software, tested it successfully and was quite happy with my test results, and found (painful and burdensome for future contributors and our process) workarounds for the inability to upload any of the header/integration files into our repository.

Based on your original reply from mid August “You can obviously include the compiled libraries (TurboActivate, TurboFloat) with your compiled version of your app.” we were just about ready to sign up for a proper paid account and to do the final integration, and now you tell me I can't even integrate the required runtime libraries into our repository? Your terms and conditions didn't mention any restrictions or conditions wrt. distribution of TurboActivate at all, there's literally nothing in there wrt. use of your client libraries, and from your previous answers I concluded that including the dynamic runtime libraries into our repos would be fine.

We don't have a “final packaged app”. Our software is an add-on toolbox extending other software, consisting of hundreds of functions, and of some compiled plugins which we wanted to protect/license with LimeLM. Our general distribution method for these is cloning the repository from GitHub. Based on your statement, this method would be impossible to continue in the future.

Additionally we provide a downloadable zip file on our GitHub releases page for each official release for users unfamiliar with the use of git. This zip file is added to the “Assets” section of each tagged release. Cfe. the 3.0.19.14.zip file in the assets section of our latest public release here: https://github.com/Psychtoolbox-3/Psychtoolbox-3/releases/tag/3.0.19.14

Can we at least manually add your dynamic libraries to those zip files on the GitHub releases page? Iow. download the zip file in the assets section of a release created from the repository, add the TurboActivate.dylib/dll/so manually and then reupload the zip file? This way the runtime libraries are part of the zip file stored on the GitHub release page, but not a part of the version controlled Git repository. This way, at least our regular non-expert users would have a workable and familiar solution for installing our software and wouldn't get punished with a much worse setup experience for buying paid licenses from us.

“You can obviously include the compiled libraries (TurboActivate, TurboFloat) with your compiled version of your app.”

That still stands. Don't include the binaries in your code repository. Include them in the packaged end-result (whether an installer or zip files, or however you distribute the final binaries of your app).

Can we at least manually add your dynamic libraries to those zip files on the GitHub releases page?

Yes.

Reply
Discard post