The thing with the licences that @stephen pointed out is a big wall for application distribution with Stardog - especially if you want Stardog to be usable as part of an application (like MySQL), and not as an isolated product itself.
I will show you a common situation so you will see my point: Let us say I am developing an application that uses the latest Stardog, say version 6.0.2. The version has an intrinsic connection with my application (for example, in Java I have to specificaly tell Maven to get Stargdog 6.0.2, otherwise my application will fail miserably, same with other languages). By the time the application is finished, there is a new Stardog version 6.5 released. So I send my application to two colleagues. They cannot use it. Why? They need to obtain a licence for 6.0.2, which is not available any more, so they are locked by Stardog. Yes, I could upgrade my application just before sending it, check very quickly for problems (it happend to me in the past that things working for 4.0.2 stopped working in the next subversion) and send it, and hope that there is no Stardog new release while my friends obtain the licence. The system could work if newer licences allow usage of older Stardog versions (I believe this is not the case currently), but if exact versions are required, the distribution of applications is legally broken.
Please advise about how this situation should be solved.
Stardog trial licenses are restricted to use with the version available at the start of the trial. Stardog developer and enterprise licenses are not subject to these restrictions.
Further, 30 day trial licenses don’t allow for 3rd party redistribution. Check the license file in distro for details. If you need those or other license grants, an email to sales@stardog.com is the way to go.
Thanks for the answer. It is not a trial but the Community version.
So it is not clear to me if people using this application (for which the Community version is more than enough and they will certainly not spend money in a licence) will be able to use it or not.
You can’t distribute the Community version, so whomever you send your application to will be responsible for getting their own version of Stardog and, if needed, to make changes to the code to get it to work with the latest version of Stardog. I hope that clarifies things.
Since people cannot get licences for old versions, I think it will be unfeasible to use Stardog in my proof. Despite the fact I love Stardog, my current test is so small that I will turn it into BlazeGraph (it is an easy change).
As a side note, it will be good to know your plans for the future, since approaching a bigger project in some environments (like academia) can be blocked by this licence limitation, and the possibility to distribute a code that works with Stardog is crucial in order to decide for a product or another at planning time. I am not sure the Community version is going to be mantained in future, or Stardog will be only a commercial product in all cases. If CE is here to stay, perhaps you could consider delivering Community licences that work for older versions (or at least, some older versions). Although from your comments, I doubt this is an option on the table. Otherwise, the licence model is a bit broken for some scenarios. Perhaps there is a reason for such restriction that I am not understanding. As it is now, let's say my friend Peter is allowed to download Stardog software and licences at any time, so it is not a matter of something forbidden, but he is forced to do it in a specific time frame if he wants to reuse some applications or scripts that someone else has created. As you said, the option to recompile the application by the user is there, but sometimes this will not work in practice (users don't want to install tools to recompile, new Stardog versions might introduce bugs or changes that make the application broken, an so on).
Is Stardog CE tied to the exact version or just the major version? I'm not sure how long the Stardog folks plan to maintain artifacts on the Stardog maven repo but I don't think they restrict it to only the latest version. If that's the case your users can download your code, build it, register for a Stardog CE license and they should be good to go as long as you're building against a current major revision. If that's not the case you'd have to keep your project up to date with the latest release. I believe they guarantee to the extent possible backward api compatibility withing major releases so there shouldn't be much or anything that would need to be updated other than the version.
To be honest, I don't know! If I can create an app that uses CE 5.0 and then the users can get Stardog CE 5.3 and the code works, then ther is no problem. Major changes should mean major application upgrades, so I am not surprised by licences not working from 5.0 to 6.0. But, even when I did my own tests without thinking of sharing them, minor versions make a problem, especially at the speed these guys deliver new Stardog versions : ) You can tell they do work.
Thanks Zach. If one distinguishes between license keys and API compatibility, I don’t see an actual problem here.
A docker script from Stardog 3.x may not work with 5.x but such is the way of all software progress. Within major releases API breakages are bugs and we treat them as such. That has nothing much to do with the requirement to get a new license key from time to time.
Mmm… Well, the problem I pictured is that imagine I create a Docker image for the latest version, Stardog 5.2.2 (6 March 2018). (The example is valid also for a Java application). Then I want to share it. When people get the image, they will need to provide a valid licence. They go to the Stardog Website and download Stardog CE, but as you deliver so often, it is May 2018 and there is a new Stardog 5.4. I believe the user cannot use the Docker image (or Java application) because it has been prepared for another version. Since it is impossible to obtain a licence for an old Stardog, the Docker image or Java application is unusable for them.
Perhaps I am not getting some point and actually licences work backwards, but I experienced errors in the past about version mismatches when I wanted to run old code over a new Stardog version.
I think what is getting you caught up is you can’t redistribute Stardog and that includes jars, artifacts, etc. So you’re ok if you put your application out there as, say a maven pom file, where your users can download your code and run a build. The dependencies will be pulled directly from the Stardog maven repository. In that case no Stardog code or binaries have been conveyed by you to the end user, only directly from Stardog.
If the license version is directly tied to the code version than it shouldn’t be too difficult to simply track the current version since you can’t distribute with Stardog artifacts as mentioned above and the API compatibility policy should make it as simple as a version bump in your pom file.
If you want to just make it a “download, grab license and go” I don’t think you’re going to be able to do that. If you use gradle and the gradle wrapper I suspect you could get it fairly close though.
If that is the case, then it would be confirmed that it is just not possible to share a .jar that uses Stardog, or a Docker image. I still think this is a major disadvantage in many scenarios and limits the expansion of Stardog in many fields (imagine the limitations of having a MySQL that can only be used by the creator of the application using it).
Sharing a .jar that uses Stardog is fine. What you can’t do is distribute a jar that contains Stardog. I think this is a perfectly reasonable restriction since what you’re essentially doing is distributing your own version of their product with the only restriction being that they would need to register for the free license.
Your example of MySQL isn’t quite accurate. First MySQL is an opensource and Stardog is not. Secondly you can write an application against Stardog the same way you can write an application against MySQL but in the case of Stardog you get a standards compliant interface with SPARQL and not a DBMS specific one like SQL.
I can completely understand your enthusiasm for wanting to use it but it’s a commercial product and that comes with some restrictions that may or may not be able to accommodate your use case.
Well, I am not really a developer, so I might lack some knowledge, but I afaik Maven inserts the external libraries in the jar file. I am not sure how libraries can be included outside the IDE, but if it is by installing and running Maven or Gradle, and retrieving Stardog libraries to place them in the jar, I know not many users will be willing to go throught this complex process. Which means that jar files using Stardog cannot be easily shared. Docker images either, because the main purpose I believe is to provide a Stardog up and running.
Of course I know MySQL is very different from Stardog CE. My point was how useful would be MySQL if you could not easily share apps that you build on top of it.
Of course I am enthusiastic about Stardog because I love it and I think it is an amazing product that just gets better at every version. I have promoted it every time I’ve had the chance. It is probably worth the money it costs, but for my use case (and I am not a big company) I would sadly go for another software if the CE didn’t exist.
But the issue is clear now to me - so avoid sharing of applications or develop them over another database.
I have been thinking and I see your point here (which is what Zachary said too). As you said, you are right that there is no problem if licence keys and API compatibility are separated, but only as long as Web access (“Network Programming”) or CLI access are used - Because the way to access Stardog is exactly the same as long as the API does not change.
The problem I was saying is with elements that NEED to know or are required to specify particular versions, such as Java (with Maven, Gradle…) or a Docker image. When Java is used, then the Stardog version addressed in the Java application and the installed Stardog version must match, and this is where problems arise.