Related
I'm looking for free open source framework/tool for Java applications and Tomcat cluster monitoring.
The are pretty much tools and frameworks out there (Zabbix, Nagious) but most has GPL license, what makes them impossible for use withing commercial products. Others, has limited charts (JavaMelody) and does not support, or very weak support, for cluster data aggregation.
Recently, I came across MoSKito which looks very promising and has MIT license but I can't really find any reviews on that and not sure how active is that project.
So, would appreciate to get any feedbacks on MoSKito ?
Thanks,
Pavel
well I am a little bit biased, because I am also a commiter in the MoSKito project, but I'll answer nevertheless ;-)
There were like 9 releases (2 major) of the project alone this year, which I think is an indicator that the project is active.
Personally I use it in 3 projects on daily base. The biggest installation I am aware of consists of over 100 JVMs running on 18 machines.
The source code is on github:
https://github.com/anotheria/moskito
https://github.com/anotheria/moskito-control
https://github.com/anotheria/moskito-central
https://github.com/anotheria/moskito-control-agent
If you have any further questions feel free to PM me ;-)
regards
Leon
We have been using MoSKito for more than three years to monitor an onlive platform with about 20 machines and around 100 JVMs running on them, which Leon mentioned above.
Our experience with MoSKito was good. It is very robust. Has a relatively low performance impact, as far as I can tell. Attaching monitoring points can be done quite easily with Annotations. And it does what it shows on the Web-Site and does that well. The developers are always open for suggestions and discussions. The projects is very active.
We did not yet use the relatively new MoSKito central, which can aggregate and store performance data, so I can not say anything about that.
MoSKito does not record all the performance data for each request. It only records averages. On the other hand you can track single requests/sessions by marking them with a request parameter, which can be very handy to analyse performance problems. Doing so shows you a full "stacktrace" of the request with all the performance data and parameters recorded at each MoSKito monitoring point.
I can't compare MoSKito to other tools, since MoSKito is the only tool I used extensively, but I was happy with it.
I intend to make some software to be sold over internet. I've only created open-source before, so I have really no idea of how to protect it from being cracked and distributed as warez. Bearing in mind that I know like two programms that aren't either cracked or not really useful I decided that the only more or less reliable way may look like this:
Connect to a server and provide licensing info and some sort of hardware summary info
If everything is fine, the server returns some crucial missing parts of the program bound to that certain pc along with the usage limit of say 2 days
That crucial stuff is not saved to hard drive, so it is downloaded every time the program starts, if the programm runs more than 2 days, data is downloaded again
If the same info is used from different computers, suspend the customer account
What do you think about this? It may seem a bit to restrictive, but I'd better make less sales at first then eventually see my precious killer app downloaded for free. Anyways, first I need some basic theory/tutorials/guides about how to ensure that user only uses a certain Java app if he has paid for it, so please suggest some.
Thanks
I work for a company selling protected Java software.
I won't comment on the scheme for user authentication, but I can comment on the online license check.
Don't make it even "work for two days": that's how I pirate most software... Virtual Machine set "back in time" and externally firewalled so that it doesn't "phone home" anymore (that is: only allowing it to contact the server once, to get the trial key), always reimaged from the point where the software got freshly installed and bingo, the 30-days trial (or two days trial) has become a lifetime trial. Why do I do this? To learn how to better protect our app of course ;) (ok, ok, I do it just for fun too)
What we do in our commercial Java software is to check the license at every startup.
We've got hundreds of customers and nobody ever bitched about it. Not once. We generate a unique class at each run, which is different at every run, which depends both on things unique for that launch on the client side and on things generated once on the server side.
In addition to that having the app contact your server at every launch is a great way to gather analytics: download to trial ratio, nb average launches per trial, etc. And it's not nasty anymore than having an Urchin/Google JavaScript tracker on each webpage is nasty.
Simply make it clear to people that your software performs the online licence check: we'got a huge checkbox either on or off saying: "Online licence verification: OK/Failed". And that's it. People know there's a check. If they don't like it, they go use inferior competitor products and life is good.
People are used to live in a wired world.
How often can you not access GMail because your Internet connection is down? How often can you not access FaceBook or SO because your Internet connection is down?
Point is: make as much computation as possible dependent on the server side:
licence check
save user preferences
backup of the data generated by your app
etc.
Nobody will complain. You'll have 0.1% of your user complain and anyway you don't want these users: they're the one who would complain about other things and post negative feedback about your app online. You better have them not to use your software at all and complain about the fact that it requires an always-on Internet connection (which 99.99% of your target demographic and hence they won't care about the complain) rather than actually have them use the app, and complain about other things related to your app.
Regarding decompiling, .class can usually be decompiled back to .java unless you're using a code flow obfuscator that produces valid bytecode but that it impossible to be generated from .java file (hence it is impossible to get back a valid .java file).
String obfuscator helps make it harder to figure out.
Source code obfuscator helps make it harder to figure out.
Bytecode obfuscator like the free Proguard makes it harder (and produce faster code, especially noticeable in the mobile world) to figure out.
If you're shipping Windows/Linux only then you can use a Java-to-native converter like Excelsior Jet (not free and kinda expensive for startups, but it produces native code from which you simply cannot find the .java files back).
As a funny side note you'll see people trying to mess with your online server... At about 30 beta-testers we had already people (which we know where part of the trial) trying to pirate our online servers.
I am sorry to turn you down, but first you should have an idea of what you want to build; then you should prove that your idea not only works, but is also loved by users to the point where they want to pirate it. Thirdly, you have to make sure that the time you are investing in making it "secure" is actually worth the value of the application.
If you sell it for a dollar, and you only sell ten copies, and you spent 100 hours making it secure, you do the math and tell me if your time was worth that little money.
The take-home message here is: everything can be cracked or copied. At the end there are much brighter people than us doing this (iPhone cracking, digital TV, games, etc) and nobody found the silver bullet. Only thing you can do is make it harder to crack your application (often at the expenses of usability, ease of installation, and by cutting corners for some use scenarios). Asking yourself if it's worth the hassle it's always a good starting point.
Don't bother.
The gaming industry has been battling piracy for decades. Online multiplayer games with a central server typically require a subscription to play. That model is fairly resistant to piracy. Pretty much all other games are heavily pirated, despite innumerable attempts at DRM.
Your app will be cracked and pirated, no matter what language you write it in and what tools you use to prevent it. If your DRM actually works, the people who would have pirated it still won't buy it. Furthermore, legitimate users will prefer other products that don't have intrusive DRM. If there are no competing products and yours has any market to speak of, someone will create one.
Unless your application is specifically web based your users will find it to be a huge hassle to require an internet connection in order that they might access the product. What you are suggesting will work, unless it gets broken, like all DRM systems do. I understand the want to protect your intellectual property, but with many companies as examples, these systems are usually broken or the product does much worse because of them.
I have really no idea of how to
protect it from being cracked and
distributed as warez.
First, you'd be better choosing a language besides Java, if this is a concern. This is why C++ is still alive and well in the commercial apps world. Unless you are going to use an actual Java compiler to native exe, I'd reconsider Java for IP protection reasons.
For that matter, even C++ isn't impervious to cracking, but IP prorection vs. cracking are two separate, important concerns.
That's a really tricky task, especially with something running in a VM.
I would say you might be thinking in the right direction. Obfuscating it to make it reasonably hard to modify might prevent people from circumventing the built in licence checks.
However, ultimately, if your application is self-contained, it will always be crackable. If you can build it so that it uses services you provide, than you can probably command it's use.
To paraphrase a Mr Jeff Atwood, it is better to make it easier for your customer to pay you than it is to crack your app. In other words, I think you are attacking the wrong problem. Make buying your product REALLY easy and then your customers won't feel they need to go to the effort of cracking it.
I would have a look at the backlash from the game Spore before deciding on a licensing scheme. They had it phone home, and only allowed so-many installations, etc. etc. etc. Spore was supposed to be their "Killer App" and it really had a hard time simply because of the licensing. You say you are willing to have fewer sales than see people using it for free, but you may want to be careful what you ask for. I was really looking forward to spore (and so were my children) but I never did buy it because of the DRM scheme.
No matter what you do, it'll be cracked in very short order especially if the program really is worth anything.
If you do go with a licensing scheme, make it simple and usable so you are not punishing those that have actually paid for your software. Also, I would avoid any phone-home style checks, that way your customers will be able to continue to use the software even if you don't want to keep paying for that domain 3 years from now.
I see a specific weakness in your example, besides the comment most people already put in that DRM is hard(impossible) to implement and often simple to circumvent.
In your second point:
If everything is fine, the server
returns some crucial missing parts of
the program bound to that certain pc
along with the usage limit of say 2
days
This 2 (or X) days limit will most likely be extremely simple to circumvent, this would just a few minutes to find and patch (crack).
If you really want to have a DRM model the only reasonable way to go is to put at significant part of the application as a web service and require constant connection from the users.
Before you try any of this, be sure to read Exploiting Software and you will think twice before trying to do DRM.
I think, given the context, the most effective form of protection for now would be the limited demo/license key approach: it would give people time to fall in love with your application so that they are willing to pay for it, yet prevent casual copying.
Once you know that your app hit it big, and that crackers provably siphon off a significant portion of your possible earnings, then you can still add additional checks.
Another thing to consider is where your app is going to be used: if it's something people would put on the their laptops to use on the go, network connectivity is not a given.
That is some of the harshest DRM I've ever heard of, your users would hate it.
Also, keep in mind that there are a lot of good Java decompilers out there due to the nature of the language and someone determined enough could just find areas of the program dealing with your DRM and bypass/disable it then recompile it (according to this a recompilation would be unrealistic)... so you would even have to go out of your way to implement your code as complex as possible to prevent a hacker from being successful. (Which could be done with one of those code obfuscation tools they may have out there.)
As long as it's an Internet application, you could restrict it in that manner. Short of cracking the program, this would work fine except for replay attacks.
For example, if I can capture the traffic that is going to your server, and simply replay it back to my program each time, I'm still good. For example, I could create my own "web server" and ensure the program hits that instead of your server.
You should read "Surreptitious Software" from Collberg and Nagra. This book is really good to help you understand how software protection mechanisms work (such as Code obfuscation, watermarking, birthmarking, etc...).
As lorenzog said, total security doesn't exist and software security is like a constant race between software vendors and pirates.
You should use cheap obfuscating transformations (so the overhead they incur isn't killing the performances) to prevent as many attackers (remember most of them are script kiddies) as possible to "steal" your killer algorithms or any secret data.
If you're willing to push the security further you can birthmark your algorithms and watermark your copies in order to find who leaked your creation. But even if you do, this doesn't mean your software is 100% secured. Plus the time you'll spend adding these mechanisms might not be worth the effort.
These concepts are really well explained in the book I mentioned before which is worth reading.
If I had enough reputation points, I'd vote this question down. Commercial software protection is a waste of time, money, and effort for many reasons. Concentrate on making a piece of software worth buying. If your software is popular enough to maintain wide seeding by pirates, you're probably successful enough at that point that you won't even worry about piracy. Anyway, crackers crack software protection mostly for fun. The stronger your protection, the better the challenge it presents and the more they want to crack it. Your best effort will cost you thousands, take months, and be cracked in only days.
I recently graduated in Computer Engineering. I don't have a permanent job yet. The recession is making a good difference in my aim and reality. I don't want to just sit down. I want to sharpen my capabilities. I want to learn and practice in a professional work environment.
Now my question is: What are the tools and practices followed in a professional working environment? I mean IDEs, team working tools,debugging tools, unit testing tools etc?
What are the frameworks in Java EE which are must-know, or which will bring me advantages in my job interviews?
Thanks in advance.
Some initial suggestions:
IDE: Eclipse or IntelliJ
Source code management tools like git, Subversion, Mercurial, CVS
JUnit for testing
Read "Code Complete", then sleep with it under your pillow. Maybe keep a copy in your bathroom as well.
IntelliJ is by far the best Java IDE, but it is commercial. Between Eclipse and NetBeans I would recommend NetBeans, it is closer to what an IDE should look and/or do(nothing against Eclipse, but I couldn't get used with it...maybe is just something wrong with me :) ).
You might find this poll (long but) interesting... http://www.java-forums.org/new-java/7315-what-you-using-write-your-code.html
We've been running a co-op (i.e. cadette) program for the last five (or so) years. Here's a list of stuff (in no particular order) that co-ops are clueless about that we really really wish they knew "the basics of" when they arrived:
Testing - Everyone tests, but (IMHO) few do so really effectively. Myself included.
Team development - How to work together on a codebase which is bigger than anyone.
Understanding legacy systems - Hey, this code is twice is my age? WTF?
Project management - That dark arts of delivering quality on time and on budget.
Business analysis - BA's are full of it! You at-least need to know enough to smell the effluent.
Known when to say NO - Practice saying this in front of a mirror: "No sir, I'm sorry, you really can't have this Ferrarri for the price of a second-hand mini."
The technology really is the easy bit. Having said that, your first position is likely to be as a code-monkey... so the more tecken ze spreken, the more likely you are to get a foot in the door.
So I suggest
Tackle the J2EE 1.4 Tutorial
... also look at a web-app MVC framework like Struts 1 or (better) JSF; and
... also look at Hibernate - the psuedo standard persistence layer.
... also look at "early" DHTML - manipulating a html-DOM with javascript.
... also look at Swing, Applets, but try not to drown in it.
then (and only then) tackle the J2EE 1.5 Tutorial (EJB3).
I'm still in the process myself. I've been at it for two months. Anymore than two hours at-a-time makes my brain hurt, a lot... you can teach an old dog new tricks, you just have to do it slowly.
Like already stated: Every position will have it's own technology set... two people sitting next to each other may use vastly different product groups. What I advise you to learn instead of "all the techs" is the process of learning technologies, and the considerations in selecting appropriate technologies to suit a particular problem, and organisation.
The best thing you can do to improve your chances of actually getting that job is to join a "Young IT Professionals" group (like this one in Australia)... they'll probably do a "mock interview" day... constructive criticism (as apposed to spoonfeeding) will improve your job applications, your CV, and your interviewability. Hanging-out with a bunch of people who shre your interests is informative, and fun. You'll miss that "brain stimulation" in the break between uni and IT work.
On the recession thing... I graduated B.Bus(Computing) a month after the dot-com bubble burst. I worked in a supermarket, drove a cab, delivered pizza, did some builders labouring, flogged PC's, vended bad financial advise to people who can't add-up for ${nameless_charlitans}, flogged anti-virus software, tutored at the local TAFE college, got a few short-term contracts writing software for a big accounting firm... then I started voluntarily fixing up the PC's at my local employment exchange (I was there waiting for appointments for hours-on-end anyway, and it was better than doing nothing)... The IT-dude there got me an interview with "a mate" (i.e. my job was never advertised), and the rest is history. Funny how stuff works out. I feel for ya', just please don't take the knock-backs personally... you're likely to get a lot of them... it's just how the game is played.
Cheers. Keith.
For the long term, work on an open source project. You'll learn a lot, and probably more quickly than you'd learn from a job.
My Java colleagues use this for most things.
Eclipse
Oracle or MySQL
Struts
Subversion
Bugzilla
JUnit
They also use Sun's Java Composite Application Platform Suite (JCAPS) for some things.
I think you need to take a close look at the companies you are applying to. The amount of "toolage" in the java world is way too much for you to become familiar with on your own in order to become attractive to any random employer.
I personally vote that the majority of it is overcomplicated crap, despite all the marketing hype that it gets. Find a company that looks like it works with stuff that you're interested in, find out what sort of stuff they use and then familiarize yourself with that. You probably won't be able to demonstrate job-level experience, but you will show yourself to be enthusiastic.
I'm going to go the route of suggesting what I feel are the most popular choices out there, which hopefully will give you more exposure to land that first job. Once you get your feet wet, I would recommend investing some of your free time to evaluate the other options out there. There is so much in the Java ecosystem to explore.
IDE: From people that I talk to, Eclipse seems to be the most popular. Netbeans is solid too but its future is in doubt since Oracle is working on acquiring Sun. A lot of folks swear by IntelliJ but I think it's much smaller community (and costs money).
SCM: Subversion and CVS are probably the most popular and Eclipse has built-in support for both.
Unit Testing: JUnit, it's the de-facto standard.
Builds: Ant, again the de-facto standard for build automation.
Frameworks: I would recommend either (1) Spring and Hibernate, the wildly-popular open source stack or (2) EJB and JPA, the Java standards. My personal preference is towards #1. As far as UI goes, there are a lot of options available, so it's harder to recommend. Struts and Spring MVC are more "old school" classic MVC frameworks whereas GWT and JSF are more "component-oriented" frameworks. You also have less popular ones like Wicket and Tapestry.
Assuming you can get your CV/resume read by someone and get an interview:
Get a copy of Effective Java by Josh Bloch, read it, memorize it and understand it. A lot of interviewers (and I have done more than my fair share) use it as a good source of techniques that people should know and understand.
In terms of tools - you can't go wrong if you know:
Eclipse
Spring
Hibernate
Ant/Maven/Hudson
JUnit
Log4J
These are all Open Source (and hence will fit anyones budget). Most Java shops will use at least one of these!
With below tools you can make sample/demo applications
IDE : JDevloper/Eclipse/Netbeans
Server: Tomcat/Jboss/Glassfish
Technology: Hibernate,Spring,EJB,Struts,Log4J,SLF4J,Hudson,Ant,Maven
Weblogic,Jetty,JBoss or Tomcat with
-Maven build tool (indirectly background Ant and library versioning)
-Prettify ("readify")
-Minify (spaceless)
-Refactoring (batch rename units)
-XML
-Stress test tool
Old tools e.g. rsync, emacs, awk, xargs, dd handle the largest files. less is good for streaming files (shift+F)
This really depends on the jobs in your area. I suggest you take an analytical approach.
Use a job search engine for you area and do keyword searches. This will give you hard numbers of job skills people are looking for in your area.
You may also find these pages useful 10 Hot Skills for 2009 The 2009 IT Salary Guide
Write an own homepage! It shows that you have fun when you write software (so you do it in your free time).
Build something you're interested in building and choose technologies that seem correct to do the job. At the same time, take the extra time -- as you should when working as well -- to use tools that might be a hassle but you think will bring you an advantage. Knowing frameworks like Spring or Maven or whatever may or may not be relevant. A good employer doesn't care what you know, but how you know what you know. Can you learn?
Use some note repository (like Evernote or my own, TheKbase :) and start making notes about your world. Whatever knowledge you have digested should be instantly retrievable and not based on your limited memory.
I was always interested in Swing and teaching, and strangely I got a job teaching Swing (which I knew a bit), but also teaching all kinds of stuff that I didn't know like Struts and XML security (you read the books and put in the time). Plus I taught IDEs, which I always liked even, though everyone thought I was an immature programmer because I wanted autocomplete :) Again, following preferences...
My point is that unless something about learning a framework or tool particularly appeals to you, don't bother learning it. On the other hand, if frameworks are particularly annoying for you (for me they have been), take the most annoying and daunting and build something with it. It's a rite of passage that most people do because an employer asks for it, which is too late, IMO.
You already have a good list of tools from the answers above. Here are a few things you could do to get more attractive to potential employers.
Participate in an Open-Source Project
To become a better programmer, learn
a language completely different from
Java. A good starting point could be
other languages on the JVM - Clojure
/ Scala.
Gain expertise in specific areas in J2EE that will make you stand out - security, performance analysis, etc.
Create your own website using the tools and the frameworks you have learnt
I work on a project that uses multiple open source Java libraries. When upgrades to those libraries come out, we tend to follow a conservative strategy:
if it ain't broke, don't fix it
if it doesn't have new features we want, ignore it
We follow this strategy because we usually don't have time to put in the new library and thoroughly test the overall application. (Like many software development teams we're always behind schedule on features we promised months ago.)
But, I sometimes wonder if this strategy is wise given that some performance improvements and a large number of bug fixes usually come with library upgrades. (i.e. "Who knows, maybe things will work better in a way we don't foresee...")
What criteria do you use when you make these types of decisions in your project?
Important: Avoid Technical Debt.
"If it ain't broke, don't upgrade" is a crazy policy that leads to software so broken that no one can fix it.
Rash, untested changes are a bad idea, but not as bad as accumulating technical debt because it appears cheaper in the short run.
Get a "nightly build" process going so you can continuously test all changes -- yours as well as the packages on which you depend.
Until you have a continuous integration process, you can do quarterly major releases that include infrastructure upgrades.
Avoid Technical Debt.
I've learned enough lessons to do the following:
Check the library's change list. What did they fix? Do I care? If there isn't a change list, then the library isn't used in my project.
What are people posting about on the Library's forum? Are there a rash of posts starting shortly after release pointing out obvious problems?
Along the same vein as number 2, don't upgrade immediately. EVERYONE has a bad release. I don't intend to be the first to get bit with that little bug. (anymore that is). This doesn't mean wait 6 months either. Within the first month of release you should know the downsides.
When I decide to go ahead with an upgrade; test, test test. Here automated testing is extremely important.
EDIT: I wanted to add one more item which is at least as important, and maybe more so than the others.
What breaking changes were introduced in this release? In other words, is the library going off in a different direction? If the library is deprecating or replacing functionality you will want to stay on top of that.
One approach is to bring the open source libraries that you use under your own source code control. Then periodically merge the upstream changes into your next release branch, or sooner if they are security fixes, and run your automated tests.
In other words, use the same criteria to decide whether to use upstream changes as you do for release cycles on code you write in house. Consider the open source developers to be part of your virtual development team. This is really the case anyway, it's just a matter of whether you choose to recognise it as part of your development practices.
While you don't want to upgrade just because there's a new version, there's another consideration, which is availability of the old version. I've run into that problem trying to build open source projects.
I usually assume that ignoring a new version of a library (coz' it doesn't have any interesting features or improvements) is a mistake, because one day you'll find out that this version is necessary for the migration to the next version which you might want to upgrade to.
So my advice is to review carefully what has changed in the new version, and consider whether the changes requires a lot of testing, or little.
If a lot of testing are required, it is best to upgrade to the newer library at the next release (major version) of your software (like when moving from v8.0 to v8.5). When this happens, I guess there are other major modifications as well, so a lot of testing is done.
I prefer not to let the versions lag too far behind on dependant libraries.
Up to a year is ok for most libraries unless security or performance issues are known.
Libraries with known security issues are a must for refreshing.
I periodically download the latest version of each library and run my apps unit tests using them.
If they pass, I use them in our development and integration environments for a while and push to QA when I'm satisfied they don't suck.
The above procedure assumes the API hasn't changed significantly. All bets are off if I need to refactor existing code just to use a newer library version. (e.g. Axis 1x vs. 2x) Then I would need to get management involved to make the decision to allocate resources. Such a change would typically be differed until a major revision of the legacy code is planned.
Some important questions:
How widely used is the library? (If it's widely used, bugs will be found and eliminated more quickly)
How actively developed is it?
Is the documentation very clear?
Have there been major changes, minor ones, or just internal changes?
Does the upgrade break backwards compatibility? (Will you have to change any of your code?)
Unless the upgrade looks bad according to the above criteria, it's better to go with it, and if you have any problems, revert to the old version.
I'm working on a command line application for Solaris, written in Java6. I'd like to be able to scroll through a history of previous commands using the up and down arrows like many Unix tools allow (shells, VIM command mode prompt, etc).
Is there any standard way of achieving this, or do I have to roll my own?
Yes, use the GNU readline library.
I think you are looking for something like JLine but I've never used it so cannot attest to its quality.
She can apparently deal with autocompletion and command line history, and the last release was recently (feb this year) so it's by no means dead.
ledit is great on linux for that sort of thing. It's probably easily compiled on solaris.
Clarification: ledit wraps the call to your other command line app, and can even be passed a file to persistently store your history.
Here's the homepage: http://cristal.inria.fr/~ddr/ledit/
There is a SourceForge project, http://java-readline.sourceforge.net/, that provides JNI-based bindings to GNU readline. I've played around with it (not used in an actual project), and it certainly covers all of the functionality.
warning: GNU readline is subject to GPL licensing terms:
Readline is free software, distributed
under the terms of the GNU General
Public License, version 2. This means
that if you want to use Readline in a
program that you release or distribute
to anyone, the program must be free
software and have a GPL-compatible
license. If you would like advice on
making your license GPL-compatible,
contact licensing#gnu.org.
In other words, use of Readline spreads the GPL-ness from a library to the entire program. (Contrast with LGPL, which allows runtime linking to a library, and requires open-sourcing only for improvements to the library itself.)
For those of us in the commercial world, even if we're not developing commercial applications, this is a show-stopper.
Anyway, the wikipedia page lists several alternatives, including JLine, which sounds promising.
Just as an aside: I work for a company that designs medical products. We make zero (0) dollars off of PC software. Nearly all our software runs on the embedded systems that we design (and we don't make any money off sales/upgrades of this software, only the products themselves); sometimes we do have software diagnostic tools that can run on the end-users' PCs. (design/manufacture/test software that's not released to customers I would think might be possible to use GPL libraries but I'm not sure) Medical products have fairly tight controls; you basically have to prove to the FDA that it's safe for users, it's not like the end user can decide "oh, I don't like this software, I'll just tweak it or use company XYZ's aftermarket replacement" -- that would leave device manufacturers open to a huge liability.