I’m starting a new OSS CI project which will use some parts of the SS framework including ORM, Redis and a couple of APIs. Initially it should fall under the free tier. Perhaps Redis might be an issue, but anyway, how should one go about license obligations when including SS framework components?
I have another project Neo4jMapper which is already using ServiceStack.Text and tbh I haven’t spent a lot of time looking at licensing, but now might be the time to get things right from the start.
If there isn’t already a document on this, perhaps a page in the main docs site to cover off integrations under common OSS and/or commercial use-cases.
It’s essentially explained in this StackOverflow answer where OSS projects would be required to build from source to make use of the AGPL/FOSS Exception on the Source Code, e.g. in order to use libraries like OrmLite, Redis or ServiceStack without restriction.
If only needing to use libraries without restrictions like ServiceStack.Text or ServiceStack.Common OSS projects can reference the commercial NuGet packages directly.
Hmm, I didn’t see that coming. Navigating the source and splitting out what I would need would be an enormous effort, not to mention supporting ongoing maintenance and fixes each time the packages are updated. Would probably take much longer than the project itself.
I guess my only realistic option is to keep the project closed-source and use the packages in a commercial setting.
It definitely doesn’t take anywhere near that much effort, after cloning the repo you can run a simple script to pull latest and build the solutions for all the projects you’re using, with something like:
Thanks for your time. Indeed looks pretty straightforward. In terms of packaging the projects, would I be under obligation to include all of the source code in my repo, or could I just include the build instructions as you’ve shown above?
Could I include a build script which pulls from your repos, then builds the projects which are referenced by projects in my repo?
I’ve noticed in the case of FluentValidation that you’ve incorporated artifacts from the original repo into your own and renamed namespaces etc. I was hoping of course not to have to do the same.