Has anyone dealt with re-distributing an application that uses the Numerical Algorithms Group (NAG) Libraries?
It seems like when I build an executable, it won't run unless I have an environment variable set for the license file- i.e. if I gave someone the code they would need a license and associated daemon as well.
Is there no way around that? I was hoping I only need the license to link with it.
#pkarasev,
You didn't say much about the nature of the application or what kind of organization. If you work for an academic institution and the application is to be shared with other researchers on a non-commercial basis, we have a program that may allow you to distribute it on a no-cost basis for users. Even if your application is to be sold, we can make so that you don't have to use NAG's license management in the application.
If you've got more questions and just want to talk with someone call either me or or John Holden in our Oxford UK office (+44 1865 511245)
Rob Meyer
+1 630 598-5215
Many parts of NAG are available for free with permissive licenses. For example, NAG's linear algebra package is taken from LAPACK, which is available in a BSD style license. You might be able to track down free versions of every sub-package in NAG, but it just won't be bundled up as nicely, and you'll then have to figure out how to make them all work together. If you list what functionality you use, perhaps people can offer more suggestions.
Related
Say there is a npm package which enables me to do functionality A. Say I write a wrapping software which basically just offers functionality A, just packages it more nicely but -apart from that- is nothing more.
Would it be legal to sell this software? Does the original contributor of functionality A (the person who wrote the npm package) get anything?
I feel like some people have done some great work, and I don't understand how it's possible that I can just use their packages and, theoretically, sell them as mine (as it were). Or am I misunderstanding some fundamental things here?
Generally the answer is:
Yes you are allowed to sell it (most of the time).
Pretty much any software you buy these days includes free software
More detailed:
there are really many licenses. Start with https://spdx.org/licenses/.
the license of the original package may not allow the selling part. This is very rare
Sometimes you need to distribute your code (e.g. GPL3) but you can sell the software.
Most free licenses try to make sure the work gets reused and sometime add conditions that they or their software gets attributed. They are not so much interested in money
Where to ask these questions:
https://opensource.stackexchange.com/
Management has asked us to look into implementing licensing features into some existing applications. Up to this point these apps were simply paid for and customers could install them as they please. We need to implement a new licensing model to generate more revenue because our older products work well enough that people do not have a reason to upgrade. So our new customers will have to pay licensing fees and/or be limited to how many installations they can have. I have never dealt with this stuff before, so please pardon my ignorance. I need as much guidance as possible (steering me in the right direction would be great!). We need the following...
Time limited demo versions. When they install the software, it works with full features for a fixed amount of time. After that, when they try to run it, it tells them their license has expired.
Licensing option that limits the app to run on a particular machine.
Licensing option that limits the app to being run by a particular user.
Licensing option that limits the app to a certain total number of users or concurrent users.
Number one is pretty simple to figure out, but I have no idea how to go about implementing the other three. Any advice is greatly appreciated.
I would look at 3rd party solutions for this honestly. There are a lot of concepts intrinsically involved in licensing, and for the cost of one week of development time you can buy a fully featured licensing product to integrate into your stuff. This is a case where writing your own is probably not worth the hassle.
I've previously used the Desaware licensing system for user and machine based licensing. Works well enough, no complaints. I believe their framework will be robust enough to handle all 4 of your requirements. http://www.desaware.com/products/licensingsystem/index.aspx
All these scnarios can be pretty complicate to implement and get just right (and hassle-free). Instead of wasting your time on this, consider using a commercial licensing solution like CryptoLicensing. It supports all the scenarios you want including trials, machine-locked, user-locked and floating/concurrent.
DISCLAIMER: I work for LogicNP Software, the developers of CryptoLicensing.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Which of the licensing options for the Ext JS library will apply if I use it in our in-house company CMS?
Take a look at this quote from Planet MySQL - GPL and Javascript:
[...] The whole story becomes a bit more
complicated when GPL is applied to a
javascript library. When users are
using the library, they will download
HTML, CSS images and the javascript
library. The first thing to realize is
that you are distributing the code. It
was on your server and now it on the
computer of the user. This gives any
user the right to look at the
javascript code and reuse it for
another project. This means that you
can’t obfuscate the javascript code
and people can copy/paste it for there
own use. This probably how you
currently look at javascript anyway.
But how about the HTML, CSS and
images, can that be publicly used? No
it can’t. Those items aren’t code as
defined in the GPL license, it should
be considered data. Therefor GPL
doesn’t ally to that part of the
application.
A web application will probably not
only have client side code, it will
also have a part on the server in the
form as PHP (or JSP, or Ruby, or ..)
scripts. The big question is, do we
need to release that part as well
(under GPL license). Although we as
developers think of the client and
server part being 2 parts of the same
application, GPL does not. When using
AJAX, the client code is interacting
with the server. However you can
compare it to any other client/server
application. This may be interpreted
as 2 applications between which data
is transfered, therefor both may have
different license. This is called the
‘ASP loophole’ and is as an error by
some. When GPLv3 was drawn up, a clear
decision was made to not close this
loophole.
As with regards to whether or not internal usage constitutes distribution, this is from the GPL FAQ:
Is making and using multiple copies within one organization or company "distribution"? No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders. However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
So IANAL, but I'd say you'd be pretty safe to use a GPL'd javascript library for internal systems, and even if you start exposing it to the rest of the world, the only restriction that applies is that if you use GPL'ed javascript libraries in your front end code, you'd have to make unobfuscated versions of your javascript files available. If you only use ExtJS for the admin area (and the admin area is only accessed by your employees) you'd still be clear of the distribution clause of GPL, the way I understand it.
Interestingly, there's another version of GPL called AGPL, which tries to close this "loophole".
The GPLv3 will apply unless you buy a commercial license. That is to say, unless you buy a commercial license, your company needs to agree to distribute the software to anyone to whom you distribute a copy of any part (ie. by sending it over to their browser) and otherwise comply with the terms of the GNU GPLv3.
Now, if this is only going to be used by employees of your company, and you don't mind giving your employees copies of your internal-only software (and, potentially, permission to personally redistribute the same), you may not mind being bound by the GPLv3. Ask your lawyer for their opinion as to whether letting employees use the software when acting as agents of the company requires licensing them a copy which they can redistribute when not acting as agents of the company -- my personal interpretation is that it doesn't, but I'm not a lawyer, cannot give legal advice, am not giving legal advice, and may well be wrong anyhow.
Bottom line: if you license your software under the GPLv3 and comply with that license, you're fine deriving from Ext; the GPL doesn't require you to distribute your source to anyone you haven't distributed any portion of the derived work to, so if it's truly in-house and never leaked (even via third-party folks downloading copies of the javascript files into their web browser), you may well be OK -- but find out what your management and legal council are comfortable with!
Now, if you (or your corporate lawyer) isn't comfortable with that (and not being comfortable with that would not be particularly surprising!), you can buy a commercial license. They're pretty reasonably priced, especially if you're buying them on a per-developer basis for only a small number of people.
According to the official license information, if you are going to derive a commercial advantage from your CMS, you are required to purchase the appropriate number of commercial licenses, unless you distribute your source code with a GPL license. In other words, you are not required to purchase commercial licenses for Ext even if you make a profit on your CMS, as long as you make your source code available under a GPL license.
http://extjs.com/products/license.php
http://extjs.com/company/dual.php
Our company has a point of sale system with many extras, such as ordering and receiving functionality, sales and order history etc. Our main issue is that the system was not designed properly from the ground up, so it takes too long to make fixes and handle requests from our customers. Also, the current technology we are using (Progress database, Progress 4GL for the language) incurs quite a bit of licensing expenses on our customers due to mutli-user license fees for database connections etc.
After a lot of discussion it is looking like we will probably start over from scratch (while maintaining the current product at least for the time being). We are looking for a couple of things:
Create the system with a nice GUI front end (it is currently CHUI and the application was not built in a way that allows us to redesign the front end... no layering or separation of business logic and gui...shudder).
Create the system with the ability to modularize different functionality so the product doesn't have to include all features. This would keep the cost down for our current customers that want basic functionality and a lower price tag. The bells and whistles would be available for those that would want them.
Use proper design patterns to make the product easy to add or change any part at any time (i.e. change the database or change the front end without needing to rewrite the application or most of it). This is a problem today because the Progress 4GL code is directly compiled against the database. Small changes in the database requires lots of code recompiling.
Our new system will be Linux based, with a possibility of a client application providing functionality from one or more windows boxes.
So what I'm looking for is any suggestions on which database and/or framework or programming language(s) someone might recommend for this sort of product. Anyone that has experience in this field might be able to point us in the right direction or even have some ideas of what to avoid. We have considered .NET and SQL Express (we don't need an enterprise level DB), but that would limit us to windows (as far as I know anyway). I have heard of Mono for writing .NET code in a Linux environment, but I don't know much about it yet. We've also considered a Java and MySql based implementation.
To summarize we are looking to do the following:
Keep licensing costs down on the technology we will use to develop the product (Oracle, yikes! MySQL, nice.)
Deliver a solution that is easily maintainable and supportable.
A solution that has a component capable of running on "old" hardware through a CHUI front end. (some of our customers have 40+ terminals which would be a ton of cash in order to convert over to a PC).
Suggestions would be appreciated.
Thanks
[UPDATE]
I should note that we are currently performing a total cost analysis. This question is intended to give us a couple of "educated" options to look into to include in or analysis. Anyone who could share experiences/suggestions about client/server setups would be appreciated (not just those who have experience with point of sale systems... that would just be a bonus).
[UPDATE]
For anyone who is interested, we ended up going with Microsoft Dynamics NAV, LS Retail (a plugin for the point of sale and various other things) and then did some (and are currently working on) customization work on top of that. This setup gave us the added benefit of having a fully integrated g/l system, which our current system lacked.
Java for language (or Scala if you want to be "bleeding edge", depending on how you plan to support it and what your developers are like it might be better, but also worse)
H2 for database
Swing for GUI
Reason: Free, portable and pretty standard.
Update: Missed the part where the system should be a client-server setup. My assumption was that the database and client should run on the same machine.
I suggest you first research your constraints a bit more - you made a passing reference to a client using a particular type of terminal - this may limit your options, unless the client agrees to upgrade.
You need to do a lot more legwork on this. It's great to get opinions from web forums, but we can't possibly know your environment as well as you do.
My broad strokes advice would be to aim for technology that is widely used. This way, expertise on the platform is cheaper than "niche" technologies, and it will be easier to get help if you hit a brick wall. Of course, following this advice may not be possible if you have non-negotiable technology already in place at customers.
My second suggestion would be to complete a full project plan, with detailed specs and proper cost estimates, before going with the "rewrite from scratch" option. Right now, you're saying that it would be cheaper to rewrite the system than maintain it, and you don't really know how much it would cost to re-write.
I suggest you use browser for the UI.
Organize your application as a web application.
There are tons of options for the back-end. You can use Java + MySQL. Java backend will save you from windows/linux debate as it will run on both platforms. You won't have any licensing cost for both Java and MySQL. (Edit: Definitely there are a lot of others languages that have run-times for both linux & windows including PHP, Ruby, Python etc)
If you go this route, you may also want to consider Google Web Toolkit (GWT) for creating the browser based front-end in a modular fashion.
One word of caution though. Browsers can be pesky when it comes to memory management. In our experience, this was the most significant challenge in doing browser based POS You may want to checkout Adobe Flex that runs in browser but might be more civil in its memory management.
What is CHUI? Character-UI, as in VT terminals? Or even 3270 style?
It sounds like you need a 3-tier system - the database backend, a middle-layer that runs the bulk of the back-end business processes, and a front-end layer for the CHUI / GUI / data-gateway.
All three layers can reside on one machine; or you can distribute the tiers out to various servers. The front-end layer would control the actual terminals, whether they are VT-terminals, or a web-browser, or a custom-written 'client' application.
Make sure you have considered the hardware needs here -- are you going to have barcode scanners, cash drawers, POS debit/credit terminals, et cetra? If you are using a standard browser, it might be hard to reliably integrate those items. (At the very least, you're likely going to have to write special applets to handle them.)
Finally, consider the possibility of a thin-client technology on Windows. It greatly simplifies system management, since you only have to upgrade the software centrally. Thin-client PC's are cheap -- sub $200.
Golden Code Development (see www.goldencode.com) has a technology that does automated conversion of Progress 4GL (the schema and code... the entire application) to a Java application with a relational database backend (e.g. PostgreSQL). They currently support a very complete CHUI environment and they do refactor the code. For example, the conversion separates the UI, the data model and the business logic into separate Java classes. The entire result is a drop-in replacement that is compatible with the original (users don't need retraining, processes don't need to be modified, the data is migrated too). This is possible because they provide an application server and a set of runtime classes that provide that compatibility. The result of the automated conversion is not something that needs further editing before you can compile and run it. True terminal support is included so hardware terminals still work (it requires a small JNI library to access NCURSES from Java). All the rest of the code in the runtime is pure Java. No Progress Software Corp technology is used in the resulting system and it runs on Linux.
At least one converted system is already in production, running a 24 by 7 mission critical environment. It is a converted ERP system that their mid-sized pilot customer uses to run their entire business.