Slashdot Mirror
SWSoft Out of Compliance With the GPL
MBCook writes "According to the Official Wine Wiki, SWSoft's Parallels 3.0 contains LGPL code. It seems that the new 3D acceleration features of Parallels 3.0 are based on Wine code (SWSoft isn't hiding this), but despite repeated requests they have not yet released their changes for the Wine developers. It has now been 22 days since SWSoft was first contacted on this issue; at the time they promised the code within 1-2 days. They have been contacted numerous time and currently say that they are waiting on 'legal department approval.'" Update: 07/03 00:06 GMT by KD : Reader something_wicked_thi notes that Parallels released the source code the next day.
We can expect the lawyers of any company challenged this way to delay, delay, delay until the challenge actually costs them money, for example by scaring off investors or landing them in court. Publication of the modified source code can open up their trade secrets or optimizations, or even disabled feature sets enabled only for more expensive releases, to activation by hackers and competitors.
I've seen at least one company do their damnedest to ignore the GPL and "forget" to notify their customers of GPL based code or modifications, or provide source, as a "trade secret". It led to a very serious argument between my supervisor and the company president, who liked us having some secret tools we could use to push our products. I wanted the GPL-based fixes to go into the next software release so we wouldn't have to keep patching things and they would just work from then on.
[ Technical note: You don't normally defrag ext2 or ext3: neither need it. ]
I've seen very similar complaints from folks who never understood or had the GPL carefully explained to them. Yes, if you build on top of someone else's code base (such as a Linux kernel, which is under GPL) and send that modified tool to your customers, then you have to send along your modifications to your customers. This is how Linux the kernel, and the GNU softwaer on which so much of Linux the operating system, became so powerful and effective.
If you're going to compete in that world, and reap the benefits of the software, you'll have to have some real addition to sell on top of it. This may be continuing technical innovation in your product line: this may be unique support for its use: it may be customization services for your customers. But yeah, you can't change 2 lines of code to break compatibility with anyone else's products and pretend it's the same product, then keep it secret. (That's basically what Microsoft did with Kerberos in Active Directory: it's been worked around in MIT's source code.) Nor can you reap 1000 man-weeks of development time, add 2 weeks for a cute new feature, and deny the others who provided that 1000 man-weeks the opportunity to test or include that feature.
If your source code is so precious that only you can be allowed to see or use it, then you are massively vulnerable to software theft. And frankly, that kind of secrecy makes your code untrustworthy: what precisely are you scared of people seeing? That you've hacked your libraries to work around a hardware bug that should never have been there? Or that your security model is a sad, sad joke? Or that your much vaunted "new feature" is something that has been in place for 4 years, but was never published? (Yes, I've seen all of these happen.)
Has any of the /. staff thought writing an addition/plugin/module/whatever to slash that identifies these troll posts and stop them from being posted ? Most of these have been around for ages, and posted many times (although i couldn't find that many from /., mainly because [AFAIK] google will not index threads that are hidden).
Shouldn't be that hard, define some way of calculating the distance between texts, allow users to flag posts as repeat troll, when enough similar flagged posts are found add it to the list, and finally check new posts against the list at post time.
But OTOH, this is probably a little overkill for something that is already dealt with rather well by the existing modding system.
Lima India November Uniform X-ray
Before we all get too excited...
The TFA links to a page on the official Parallels website that acknowledges the use of open source code from various sources, including the use of the LGPL, and offers to provide the source on request, as required.
Allegedly, when people have actually EMAILed this address, the response has been less than satisfactory.
Its quite right that the WINE people are keeping an eye on this situation, but I suggest that people browse the rest of the Parallels support fora and form an impression of the company's general track-record vis. timely and helpful responses to EMAIL requests before trying to answer the "conspiracy" vs. "cock-up" question.
Parallels for Mac is a jolly impressive product - they got a perfectly usable package out of the door, at a very low price within, what? six months of the launch of Intel Macs, and have since been regularly upping the ante in terms of OSX/Windows integration. However, they also have issues - e.g. too many people were enticed by the website to try the beta version of 2.5 and the current blurb for 3.0 widely oversells its ability to Run today's most popular PC games on a Mac.
The latter is a pity - what they've achieved is jolly impressive (e.g. I've been quite happily running "Freelancer" - everything apart from the opening splash & movie works, UT2004 was tolerable, with glitches) but its much more "enjoy a few of your 3-4 year old PC games that you didn't think you'd be able to play again".
As for the EMAIL & support: they'd been selling virtualization software to a crowd of tech-savvy developers and sysadmins, then they suddenly started dealing with regular Mac users who wanted to sync their mobile phones or run accounting software and were now trying to "virtualize" the copy of windows previously installed under "bootcamp". Anybody here want to volunteer for that particular helldesk?
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
I thought AT&T vs BSD case settled this. Header files aren't protectable. Of course it gets unclear what happens if header files contain inline functions (whoever puts code to header file should be shot at noon:) but function signatures or class definitions aren't copyrightable code.
You don't know what you don't know.