Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm a programmer who is starting to build small commercial apps (for mobile phones (java,android), web pages and c++ apps built in visual studio).
Now the problem is that i don't understand how licencing works. From what I've seen I am not allowed to use any library, not even java's basic one because they are either under GPL or something else.
For example, am I obliged to pay Sun to use their java libraries to build my app ? or how can I write a mobile app when it is necessary to release my code. How do big companies get around that ?
Another thing I don't understand, what libraries and apis am I allowed to use for free that are windows specific (like MFC, .NET, COM). How do this licences work? if I just bought the visual studio suit will it be enough to allow me to use this api's ? I'm in a situation that I learned to use this libraries/apis/frameworks and now when it's time to actually use them for something I must pay for them.
If that's true than that means it's impossible to build commercial apps without spending thousands of dollars on other things ?
Here are some cases and how to deal with them:
copying source code into your own code
This is where you should be very aware where you're copying from and under which license(s) the code was released. Most of the cases you will NOT be allowed to copy it. In almost all other cases you will need to put the original copyright notice in the code. In some cases (GPL) you're obliged to release the source code along with any public distribution of your product. In some cases you can purchase a license for redistribution rights in binary form. In all cases it's good practice to put a comment, marking the origin of the code.
Using libraries but not shipping
If you compile an application for Android or for Windows, you'll inevitably use their API's and libraries. As long as these belong to the platform, you do not need to ship the libraries with your app. So you only need to care if you're allowed to use them (link to them) from within your app. For OS and Language libs, this is usually the case.
Shipping 3rd party libraries with your app
Here again, you will need to know exactly what you're doing because there are big differences. This field is quite complex... Some development environments and frameworks include "redistributable" packages, which are meant for inclusion in your app. But they come with license terms, too, and it's worthwhile to read and understand the implications.
Rule of thumb: BSD style licenses are fine if you give proper credit in your documentation. GPL is almost always a no-go for commercial applications unless you're willing to release your entire source code with your product.
Disclaimer: IANAL
Your question is extremely broad, covering a wide range of libraries and associated licenses. IANAL but the short answer is that most of the library code that you mention can be used for commercial purposes without paying anything; particularly the Java and .Net code. The respective platform holders WANT people to use them. It's only when you get into more specialised situations that they start extracting revenue, usually through support contracts or special VM versions (like the old JRockit VM).
There is a big difference between copying code and use it as your own, versus linking to it.
The semantics can get complicated very fast, as there are many types of licences, so as a warm recommendation, hire the services of a good lawyer that is familiar with the field. That can save you a lot of trouble in the future!!
Big companies are careful in examining the license for every tool/sdk/library that they incorporate in their solutions.
In what's concerning the obligation of releasing your source code, you don't have to if you are using either Microsoft sdks or the Java base libraries.
But in order to be 100% sure, you always have to read the licenses. A good start to understanding how licensing works would be to read the following Wikipedia articles:
CopyLeft - if a license is copyleft then all the restrictions of that license will also apply to your code, but you will not be able to impose further restrictions to the code or product. That means that if you use an open source sdk that has a License which is Copyleft you will have to distribute your source code as open source.
CopyFree - if a license is copyfree, you may impose further restrictions on it like adding a fee for the end product and refuse to distribute the code.
GNU public license - the copyleft standard applies if you included or linked to copyleft based license
Lesser GNU public license - the copyleft standard applies only if you directly included copyleft licensed code into your source base. But it does not apply if you merely linked to a copyleft type licensed product
Try to spend some time and go trough a few articles on the licensing subject and then you will start to understand licenses a bit better.
HTH,
JP
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We provide per server licenses of our application to your clients. What is the best way of ensuring they're not copied to other servers? It's a JBoss server application. Are MAC address restrictions sufficient enough? A lot of applications restrict by MAC address, but I think it can be faked quite easily.
There are many issues with rolling your own license management software. If you lock to hardware, what happens when a server goes out and your customer wants to migrate to a new machine? Do you support hot standby? Do you support virtualization? Is it licensed per CPU or per instance? These are just a few sample questions that come into play; there are many, many more to consider.
Several years ago, I worked on a server system where we were required to implement license management and enforcement. We used FlexLM from Macrovision. It appears that it is now rolled into a new company and product suite as FlexNet. It was pricey but much better thought out for license management than a hand rolled solution, and, it can span pretty much any server licensing needs.
That said, I very much suggest that you do not approach license compliance in this way. Your customers are not likely to respond well to it, not because they want to cheat you on lincensing but because you are adding extra steps, however minor, to the use of the software that they are licensing. In my experience, much better solutions include simply trusting your customers to abide by the license agreement (as a jboss app I'm assuming you are dealing with corporate customers rather than a more easily "shared" consumer desktop app), include rights to audit via the license agreement, or setup the license so your customer can install at will and pay for licenses in use at specified periods. Your account managers should love having a touch point to ask about new licenses. In my experience with server software, when you make it easy for enterprise customers to expand use of your software, they tend to do so resulting in net positive sales.
Whichever way you go, good luck!
I believe that MAC address restrictions are not a very good idea. First a server may have more than one network card. Second - sometimes network cards fail, and need to be replaced - hence MAC address is changed.
A possibility is to collect some kind of hardware fingerprints of as many components as you can, and then use them to decide if this is the same machine or not. If you allow for some changes changing a single component will not stop the software, but changing 2 or 3 will require your client to contact you, to obtain new license.
Of course the ultimate protection is the so called dongle. There is a nice Software protection dongle article in Wikipedia.
All in all, there is no protection, which cannot be cracked. So whatever you choose, make sure that it does not harm your user, or you can loose more customers by virtue of bad protection mechanism than by unlicensed use.
With Licenses, if you want to crack it you can crack it ;)
That being said,
If you intend to use MAC address to ensure that only only copy of your software is used, be prepared for the following:
You need to support a single license on multiple MAC addresses, this is because customers will usually have multiple NICs and keep one of them active at a time.
You will need to have a super fast customer service. Say your customer plans to transfer this software from one machine to another, then he will ask you for a transfer of license to the new MAC address. If the software is a time critical one then this transfer should happen very fast.
Of course, you can combine solution 1 with Solution 2.
If the customers server, on which you install your software has access to internet, then the best option would be to have a online license renewal, where in your software will renew it's license with your license server. But cost is an issue here, considering all the infrastructure required.
Consider this discussion before decide on license schemes license-scheme
Also this how-are-software-license-keys-generated
And this consideration for License Management
Also JLicense is a simple library to use for simple license management.
Suggestion. Build in an automatic update of functional deficiencies (security patches/bug repairs/optimisations). And then do an ID & IP check.
You need to think about the following questions:
Would your customer breach the license agreement?
Is your customer skilled and could breach the protection?
If both answers are true, there is no chance to protect your software, except you will use a hardware component like a dongle.
If one answer is false, you could use this simple approach:
While installing your software generate an Install-Id on the customer machine using some secret algorythm and store it encrypted in an uncommon secret place on the machine and show it to the customer.
Request the Install-Id from customer and check whether it is really generated with your algorythm.
Generate a License-Key using a second secret algorythm and give it to the customer.
Validate in your software that the License-Key was generated using the Install-Id.
Since the hardware can be replaced you can not use parameters like MAC address, so you have to use something generic like an Install-Id.
The best way is to do this outside software, using the software agreement to place these restrictions. The customer can choose to follow the guidelines and be compliant or not. Chances are, if they're a public company, they're dealing w/ software audits and would rather just pay to be compliant than risk being sued.
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 got a Java project I don't want to publish under a Gnu license. (MIT, but nevermind.)
As build management tool I use Maven, that generates a “jar-with-dependencies”.
The project depends on gnu.getopt, licensed under the LGPL 2.
So my questions are:
Am I allowed to publish that “jar-with-dependencies” under another license than the LGPL? (Say, MIT, shareware …)
If not: How can I distribute executable JARs depending on LGPL code?
I do not
look for a replacement for gnu.getopt.
seek for answers like “consult your lawyer”.
want to be converted to the Gnu way of life …
Haha, you don't have to be converted to the GNU way of life although I would highly recommend it :). You are in luck, the difference between the GPL and the LGPL (Lesser GPL) is that the LGPL basically allows you to do just what you are asking wheras the GPL does not. From the GNU rationale for not using the LGPL:
The GNU Project has two principal licenses to use for libraries. One is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
GNU want to change all of their libraries to GPL eventually but, for now, if it says it uses the LGPL, you're good to go. If it had used the GNU licence, you would have to licence your software under a GNU-compliant licence. In fact, a quick search of this list reveals:
Expat License
This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. It is sometimes ambiguously referred to as the MIT License.
EDIT: Remember that IANAL! I have since found that you may not be able to licence under a compatible licence when including a GPL library: What does it mean to say a license is “compatible with the GPL?”
I do not [...] seek for answers like “consult your lawyer”
You shouldn't rely on non-qualified people for legal advice.
If you don't want to talk to a lawyer, do your own research and take your own risks. In this case, the language of the license is fairly clear and FSF provide extensive explanatory information. But you need to bear in mind that legal language does not always mean what a layman thinks it means ...
But if you are happy to ignore that advice...
My understanding is that LGPL means that you can use it with non-GPL code, provided that 1) you distribute source for any changes that you make to the library, and 2) keep the JAR file separate so that people can upgrade the library independently of your code.
I like GNU and everything the FSF did for the software engineering community. But enterprises like the Apache License better.
That may be so, but if they (enterprises) are willing to use Linux, etc then they can live with your code being GPL as well. And if they can't, they can afford to pay you some money for the privilege of embedding your code in their closed-source application.
On the other hand, you may have no problem with people using your code in that fashion.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I always hear that Java being open-source is a big benefit, but I fail to see how Java being open-source should draw me to use it as opposed to .NET which is closed-source. This website has some Q&A sections (What is the significance of these developments to the industry? in particular) that give a little info, but is being free the only (or the biggest) advantage to Java being open-source?
Since I am a beginner, have any of you pros noticed any major difference since the change was made?
EDIT:
Please disregard the .NET part of this question, I was simply using it as a comparison. What I really care about is knowing what benefit becoming open-source has been to Java.
If you are a mainstream user, there is probably no immediate benefit for you.
However, the open-source base of Java makes it easier for people to adapt it to more niche requirements that the closed-source vendor sees no need to support. Smaller vendors (or open source projects) can come up with solutions to these special needs.
For example, Java runs on a great variety of platforms and operating systems, most of them supported by companies other than Sun (granted, that was the case even before it was open source).
have any of you pros noticed any major difference since the change was made
I like the fact that Linux distributions now include the "official" Sun JVM and JDK, rather than making you install it separately or use the "mostly-compatible" alternative implementation that was provided.
Not entirely fair to say .NET is closed source - Microsoft's .NET runtime and development tools are closed-source.
Mono is an open-source implementation of many things in the .NET world - the CLR and C# being the biggest.
The primary implementation of .NET is closed source, though there are competing open-source implementations.
The primary implementation of JVM is open source, though there are competing closed-source implementations.
The standard for Java remains entirely under control of Sun (Oracle). Others are allowed to provide input, but final decisions are up to Sun.
The standard for CLR is entirely under control of the ECMA and ISO. Microsoft is allowed to provide input, but the final decision is up to the standards bodies. If Microsoft did ignore their decision, it's open to question whether the standard would remain relevant.
The improvements to OpenJDK since it was open-sourced have been immeasurable, here is just a few:
The Zero project, contributed by Redhat, has ported Hotspot to many new platforms like PowerPC (32 and 64 bit), IA-64, ARM and zSeries, and made future ports to other platforms much easier. The Shark subproject has also given it better performance on some of those platforms
The OpenJDK has been ported to new operating systems, such as Haiku and BSD
Many bugs have been reported and fixed by individuals and companies
Apple has joined the OpenJDK project and a MacOS port is in the pipeline
So has IBM
Various innovative projects, such as IcedRobot have become possible
OpenJDK jtreg tests are now available to other Java implementations
Some of the direct benefits to the average Java programmer are:
You can investigate and fix bugs in the JDK source code
You can build custom versions of the OpenJDK (eg. strip it down to make it smaller)
You don't need to pay license fees to ship OpenJDK on embedded devices
Java and .Net are both standards for which anyone can write an open-source implementation. .Net 3.0 just happens to have no complete open-source implementations.
Regardless of openness, the difference for you (and the reason many people choose Java at all) is portability. There are far more implementations of Java, and most are closed.
Java can create apps for cell phones. Java can create web apps. Java runs on Mac. Not .Net.
Sun is just advertising the simplification and standardization which a common open-source core may provide. But if you look closely at the page you linked, you'll see that it's using the future tense.
Opening up the JVM source helps in porting it to other architectures such as ARM for embedded use.
More choices. Flexibility. Java Community Process. I think mainly lower cost of ownership - Eclipse+ApacheServer+Linux - are all free.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've got a fairly simple open-source Java project I am starting. This process is new to me, I'm used to writing programs just for myself. What are some good practices to be aware of when releasing open-source projects in Java?
Here are some things I can think of, can you suggest others?
version control repository (what do you use to explain relevant tags/branches? an external README file?)
include appropriate open-source license in code
include prepackaged executable JAR file, including version number in the filename
some kind of README file that explains external dependencies needed to build/run the software (is there a common convention for what filename and where to put it?)
a webpage for the project, w/ a link to it in the source code and/or executable, in case someone obtains the source code or executable first (rather than through the webpage in question)
One thing you should definitely do (because it's Java) is to generate Javadocs for your code. This means commenting classes and methods using the Javadoc notation for easier readability to others.
You could also use Maven for releasing your code. With it it's quite easy to create a site for your project, specify the dependencies, optimize the releases...For example, the Commons projects at Apache use Maven.
Basically you want your project to work 'out of the box'. When people are choosing the right open source project for a task, they download a bunch of projects that say they support the task, and use the best one. If a project needs significant work to setup (e.g. downloading 20 JAR dependencies from 20 different sites) most people will only either try it as a last resort or just ignore it.
Repository: You might try some newer repository engine - like Mercurial or Git. They ease development and ease merging of branches. Importantly though, choose an engine that is supported natively by your IDE.
Dependencies: You should use a readme to state dependencies, but this is not sufficient, either use Maven to manage dependencies, in which case you just need to include pom.xml file, or include JARs that you are dependent on in your distribution. In second case divide dependencies into mandatory, optional, compiletime and test. An example of an optional dependency are the bytecode generation tools for Hibernate.
Site: Maven may create a site that is associated with particular version of your software (never used that though).
Documenation - JavaDoc: Document everything, and try to enforce a policy that ensures high quality javadocs:
/**
* Sets the cost
* #param decimal cost
*/
public void setCost(BigDecimal decimal){
is useless. Better is:
/**
* Sets the cost, cost is in currency setted by #setCurrency.
* #param decimal cost, precision shoule be at least three places
*/
public void setCost(BigDecimal decimal){
Documentation: Javadoc is not enough. Give some starting point - a tutorial is preferable (and I don't mean the kind of tutorial with many screenshots of eclipse dialogs ;)). Example code is OK too, or at least write somewhere - 'Reading the javadoc of the EntryPoint class is a good way to start using this library'. If you have only javadocs anyone who is considering using your library will be presented a list of all the clases and packages, and will not know where to start.
Bugtracking Software: You won't remember more that three bugs at a time (and will forget things) - also it will help you manage tasks, and new wanted features.
You may want to try:
FogBugz - its nice, but costs money. (Free for up to two developers).
Bugzilla - nice, popular and free
Project Management Software: This will help you to calculate release dates, split tasks between developers etc.
dotProject - free and OK.
FogBugz - again works great.
Try to pass Joel test
Build process: Make the build a one-click process. For example an ant script that increments the version number, launches maven builds, deploys the site and so on. Worth the effort!
Forum: A nice idea, will help support.
Wiki: In many (even quite developed) projects such wikis are rather empty which is bad (as it makes people think 'how can this be great software if no-one writes in this wiki').
Plan on developing some type of website. If your code involves web software, people really marvel if you are using it as part of your site.
Developers love good documentation and lots of samples. I have seen projects that have lots of powerful code but 0% documentation fall hard.
Having a wiki setup to let people write ideas and recipes is a definite plus. (I recommend mediawiki).
A forum to post ideas, threads of discussions, i.e. a community forum is also good.
Setup a mailing list and encourage people to join.
Post real updates to your mailing list, wiki site, and also as news on your main site to show you are really working on things. Encourage participation. Make yourself available. This all generates a sense that you are interesting in chipping in, and that you are open to input from others.
I suggest using MAVEN as tool for managing external dependencies needed to build/run
You can aslo use Vulcan or alike for continous inetgration, so it is known whetaher current version is realy working or not.
I know Maven is already mentioned, but I think that even more important than using Maven is to publish artifacts to Maven repositories, so that projects that do use Maven can use them.
Your project page can then provide direct links to a repo as well so it server as storage space for downloadables as well.
Also: in similar vein, making jars OSGi bundles -- which just means adding a few Manifest entries, nothing very complicated -- is another good thing.
Both of these help others to more easily add dependencies to your package (if applicable) and can help adoption.
Some more things to consider:
Sensible version number scheme (major version bump for incompatible changes; minor version for additions with backwards compatibility; or something like that)
Keeping good release notes
Use a bug-tracking system, if you can use one easily (Codehaus, dev.java.net, SourceForce etc all offer this)
Simple project Wiki for documentation
Mailing lists for discussion
Generate a ChangeLog from checkin comments. Separately create a release note explaining what you fixed/added in each release.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the best way to implement license enforcement in a Java application, so that the application cannot be "distributed" and used without the user purchasing the license?
Take a look at truelicense which is an open source framework for doing just that. If you want to make your own there is some documentation that explains the concepts and you can probably get some good ideas by looking at the code as well.
EDIT:
worth mentioning that it is not a copy-protection scheme
I suggest you don't even attempt to add copy protection. You will just annoy people. You are much more likely to get sales if people like your product. Being petty and treating customers like thieves is not going to help. (Unless the product really sucks, and you have to prevent people from being able to try it before they buy.)
You might want to send a license key the sole purpose of which is to satisfy users that want to receive something for their money. Just add a status somewhere to show whether it has been paid for. The status needs to be reasonably obvious so that it is clear that something has happened (a product I worked on along time ago came on floppy two discs - half of the support calls were because the installer didn't ask for the second [win32s] disc).
There isn't a licensing scheme that I am aware of that is not easily breakable. I will not go into specifics, but as an example, in the Java case if it is done in Java then it can be decompiled (as can C++ or any compiled language, but Java is easier than C++ for instance). If it is done natively then you need native methods, and the DLL/so could be replaced with one that allows access.
For the C/C++ example I know someone who decompiled the CL (Microsoft compiler) to figure out how they do name mangling. All they had was the binary, and they were able to do it with a disassembler and a lot of time.
Don't bother with this type of thing, it annoys honest users and moderately slows down those that want to copy it. Take a look at World of Goo (great game!) and their take on DRM (which is a similar idea to what you are talking about).
The developers of World of Goo found that their product was pirated 90% of the time (they explain how that number could be inaccurate), contrast that to another game that shipped with DRM and was pirated 92% of the time.
If you are talking about legitimate businesses then they want to be in license compliance usually, so ensuring that they are not copying is a waste. If you are talking about people who would not buy the product to begin with, or just don't want to pay for it, you are not really going to alter the number of people that get your software illegally, you will only slow down the first person who gets it - after that the cat is out of the bag.
Personally I think IntelliJ gets it right: fully-featured version for 30 days. You shouldn't be any more restrictive than that.
The "fully featured" part is important. If your unregistered version is so crippled as to be useless, how do you expect people to decide to buy it? They have to try features before they decide they like them and want them but the notion some vendors have that people will buy something on the promise of features they haven't been able to try is ludicrous.
Oracle is at the most liberal end of the spectrum. You can basically download a fully-featured version of their software and just use it. They treat licensing as a social problem and there's a lot of merit to that argument.
You should never nag or otherwise annoy your potential customers (beyond possibly expiring the software after a predetermined period). The most notice you should give is "X expires in N days" on say a splash screen or something.
The other thing you can and should do is provide a low barrier to entry for your software.
Provide a cheap (if not free) academic or personal version. Marketing is also a good idea. By this I mean take IntelliJ: it's offered free to approved open source projects.
As for the technical aspects of enforcement: don't be too concerned about the technical aspects. Never choose any scheme that annoys your users or, worse yet, slows down your software (as some schemes do) or (even worse) violates the security of the user's operating system (eg like the Sony rootkit fiasco). Your enforcement is not meant to be hack-proof. If people want to steal your software they will. The enforcement system is there as a gentle reminder (and nothing more) for a social not a technical problem.
After reading oracle's BCL(which affirmed commercial freedom). I then had a conversation with an oracle representative who said JavaSE is free for commercial use!.