And that's pretty much a pattern with Sun: they usually open source stuff only once it's been reimplemented anyway and/or has become useless.... As I was saying, OpenOffice is useful, but that's pretty much the only thing of significance I think they have ever done. I don't think Sun's contributions to Gnome or Mozilla have been particularly important.
Counter-example: DTrace. Real innovation, that was recently imported into FreeBSD and MacOS X. The effort to do this import was almost certainly non-trivial, so it stands to reason that FreeBSD and MacOS X teams at Apple valued this contribution. Furthermore, the import of DTrace by Apple is notable in that it was performed by Apple entirely on its own (i.e. Apple paid engineering time for this), and that Apple is a commercial competitor to Sun.
The major open source kernel happens to be under GPL, that's just an unalterable fact. It was Sun management that has deliberately chosen to pick licenses that are incompatible with this kernel (they could have easily dual-licensed their stuff).
I take significant exception to that statement. Ever hear of any of the BSD operating systems? Maybe you mean most popular open source kernel. As a kernel developer who has worked on 3 different open source kernels, I can tell you that about the only thing Linux has over the competition is popularity, and I believe that is mostly due to historical accident. Most of the rest of the Linux kernel is simply amazing in that it works at all -- a lot of what is in Linux is engineering by accident rather than engineering by design. And if you go back far enough in Linux history, you will find major events that demonstrate this. (C.f. the abortive "experiment" in trying to make the Linux kernel a C++ program. Or look at the numerous band-aids to major kernel subsystems, that have been one band-aid after another, until certain subsystems are more band-aid than designed product. The evolution of the filesystems over the years is a good example of this. Or the various libc fiascos. Or the lack of any stable kernel API. Etc. etc. ad nasuem.)
The religious zealots here is Sun management, not the open source community.
First, the open source community != the Linux community. I'm an active NetBSD committer (I recently contributed a radeon framebuffer driver, for example), and an active contributor to OpenSolaris. I don't think it is fair to ignore these other open source efforts.
Second, there are folks in the Linux camp that have claimed that it is against the GPL to even load a proprietary kernel module into Linux. Certainly, Donald Becker has claimed in the past that attempts to port his code to a non-GPL operating system would be met with litigation. Look at the whole binary blob nonsense going on now. If this isn't a religious war, then I don't know what is.
Third, Sun (and almost anyone who wants to do anything commercial with Open Source) abhors GPL, with good reason. Its viral nature makes it almost impossible to use with any other code -- even BSD licensed code is incompatible with GPL. Don't blame a commercial entity for not sharing its crown jewels (which in this case represent millions, and for all I know billions, of dollars of R&D investment) under your terms. Shees.
Fourth, as a person who has donated GPL code in the past, GPL scares me. Specifically, GPLv2 automatically grants permission for my code to be released under GPLv3. Unfortunately, I was too short sighted to realize that RMS/FSF were going to use future GPL versions to make a political statement that I might not agree with. I now strongly regret ever releasing any of my code under GPL. It would have been better to use a BSD license for some of that stuff, or to remove the clause explicitly allowing "license upgrade" (or, in my opinion, downgrade.)
In fact, not even the design of NFS can be counted a "contribution"; NFS has poor performance, poor security, poor manageability. The value of NFS was as a prototype, to show what was possible, but it should have been replaced by something else long ago. NFS is a typical Sun effort: the occasionally good insight into the market, crappy design, and proprietary implementation.
Recall NFS was designed in 1984. At the time it was a major innovation. You are comparing 20 year old technology with today's standards. And even Sun recognized those flaws and added innovations like cachefs, SecureNFS, and ultimately, NFSv4. (And, they even gave the source code for NFSv4 away, and funded Linux development of an NFSv4 client.)
By the way, I suppose you'll hold up SMB/CIFS as a paragon of distributed filesystem design? The only truly nice distributed filesystems I've worked with is AFS, and IBM kept not only the implementation proprietary, but also the specifications, so that the only way to to get it was to buy it from IBM. (You could get DFS from OSF, but that cost big $$ too!) IBM only opened up AFS when it had become obvious that it had lost all market relevance.
Sun may or may not be the corporate entity that has released the largest number of LOCs under what they consider an open source license, but that doesn't make them a "contributor". A "contributor" contributes stuff that is actually useful and that supports the community. Dumping millions of lines of code that doesn't solve an important problem, or actually actively trying to compete with established open source projects for no good reason, is not a "contribution".
So I suppose OpenOffice is a totally useless contribution? Or the major contributions to Gnome? Or the work they did on Mozilla?
I think you need to compare Sun with the alternatives. The alternatives are companies that don't even open up the standards that let you communicate with their technology (Microsoft, IBM in the form of its database and Lotus products, etc.) The only reason IBM is contributing to Linux at all is so they don't have to have their own OS staff in house, and can commercialize the open source produced by others -- including, by the way, Sun.
In fact, Sun is trying to do to the FOSS world of what they are always accusing Microsoft of trying to do to Java: Sun is trying to fragment FOSS by introducing new, incompatible standards (NFSv4, ZFS, DTrace, etc.) and new, incompatible licenses; the fact that their fragmentation attempts involve some open source licenses is not out of the goodness of their hearts, it's because that's what it takes to fragment open source.
Gimme a break. Do you even understand why Sun wants to retain control sometimes? A big part of the Java debate, for example, can be traced to history where Microsoft tried to destroy the run-anywhere value proposition by sabotaging Java. The Java licenses were designed (among other things) to protect against abuses like this.
Sun's OpenSolaris license is widely reusable, and is basically a set of improvements upon the MPL.
Anyway, you seem to you be one of those conspiracy theorists that think Sun is evil because it gives stuff away for free. Its important that to note that just sticking everything under the planet under a GPL may not be a good idea -- Sun wants folks to be able to things with the code that, quite frankly, GPL is not well suited to.
Just because everyone doesn't buy in to RMS' idealism doesn't mean that they're out to ruin the open software community. Heck, I believe that the open software _community_ as such (and Linux in particular) would either not exist at all, or just be a lunatic toy, if it weren't for the efforts of Sun. And those efforts long predate IBM's investment in Linux.
And for what it is worth, I think there is some push to move a lot of the previous contributions under CDDL or GPL. The p
NFS was developed in 1984. Long before Linux even existed. It was engineered from the get-go to be open-standard (not necessarily open-source). It was specified in a number of RFCs. Look for example at RFC 1094, which bears a publish date of 1989. This again, was before Linux was on the scene.
At the time, the _implementation_ was proprietary. Sun espoused the ideals of open standards and private implementation. These were also, by the way, the same ideals that allowed your beloved Linux to flourish. To a certain extent, it still does. (The idea being that in a competitive markets, companies should be free to innovate and compete on the basis of their implementation, but that the industry needs interoperability. I still think this idea has a lot of merit.)
The actual open SOURCE for NFS itself was done in 2000. I believe there were releases under more restrictive licenses than that earlier.
By the way, there are other open source OS' than Linux. And there always have been, at least as long as Linux has been around. (386BSD was around at about the same time as Linux, an, IIRC, it had better/more stable networking earlier than Linux did.)
By the way, did you know that Sun is the single largest contributor of open source to the community, surpassing even UC Berkeley?
You are exactly right in that these critera don't make a project Open Source. But OpenSolaris is freely downloadable, modifiable, and redistributable. You can make your own distro. And Sun can't revoke that right away. So, by the standards that I think most knowledgable OSS folks use (including the OSI), OpenSolaris _is_ Open Source. IBM is just spouting FUD, and showing their general ignorance of both Open Source and their competition. About what you'd expect from a company that is worried because it doesn't have any real competitive advantage any longer.
But even OpenSolaris is a very new development. What I'm getting at is: IBM was putting its money where its mouth was, _long_ before Sun.
Ever hear of, oh, NFS. No? How about RPC? These Sun contributions to open source predate IBM's involvement with FOSS by a long time. Heck, they even predate the whole FOSS movement. Except for the University of California, Berkeley, I doubt any institution has ever given as much or as freely to open source as Sun has, as early as it did, or technologly that has done more to contribute to the developments that ultimately led to the Internet. And they have continued to support open source (and open standards) throughout their history.
Get your facts straight next time.
You also said:
I don't know exactly how "open" OpenSolaris is. Maybe it's really open, maybe it's one of Sun's usual smoke screens. No idea. I couldn't be bothered to care about it at that point.
Then WTF are you doing posting here? You obviously haven't looked into it. Yes, OpenSolaris is mostly OpenSource (there are a few closed bits, but they are not necessarily critical bits anyway). And guess what? Just because Sun has control of OpenSolaris, doesn't mean you can't download the whole source tree and fork it and start your own project. (Some folks have already done this, check out the PPC port of Solaris, or the port of Debian userland to the Solaris kernel, for example.) That is what Open Source means.
I am an outside contributor to OpenSolaris. I have several projects which are currently in the process of getting integrated into Solaris.
It is true that the development model at Sun is a bit more "Cathedral" than "Bazaar", and there are still some technical and administrative challenges to solve (for example they haven't figured out how to get folks to directly commit to OpenSolaris yet -- you have to hand off code to folks at Sun who integrate your code and walk it thru the process.)
Development of Solaris has always been a tricky thing, and historically has had huge amounts of "process" to get changes. This is because there are numerous quality safeguards, and committees that have been involved. There are famous questions that every project integrating has historically had to answer: (is it i18n safe, what interfaces does it expose? does it conform to various standards already established? is it portable to both intel and sparc? etc. etc.)
Part of the review process also has to uphold things like Sun's binary compatibility guarantee. In any respects, the _quality_ of Sun's Solaris product is much higher, I think, than what you find in say Linux, where churn is a lot higher and quality and oversight controls a bit less.
Anyway, it is possible to contribute to OpenSolaris now, though its a bit of a rough road right now. But they are making it better, and I expect it will be a lot easier in the next year or so.
You might want to review the original posting. I never said anything about downloading DLLs from Microsoft.
Furthermore, I run on NetBSD and Solaris, and have _never_ downloaded any microsoft codecs, legally or otherwise. Mostly this is because THEY WOULD BE TOTALLY USELESS ON MY ULTRASPARC AND MIPS HARDWARE. So content in WMV has typically not been available to me.
But in any case, I was under the impression that a fair number of codecs were closed source, including the ones Microsoft promotes for use by content producers. If this is not the case, then I apologize for my misunderstanding.
My original point, that having open source for this stuff (whether from a settlement with Microsoft due to litigation or otherwise) is going to be a very good thing.
While I do contribute heavily to opensource development, I don't have the time or energy to start writing my own codecs from documents that may or may not exist, and may or may not be sufficient to create an implementation. So, in summary, thank you Real for working to get this technology into Open Source, in one fashion or another.
Having _open source_ versions of these codecs means that lots of other FOSS can make use of them, not just RealPlayer/HelixPlayer.
Its small victories like this that make the whole litigation against monopolists like Microsoft worthwhile. Sure the billions in payoffs are great, but what really, really helps advance the field is the opening up of proprietary formats and protocols.
It also means that those of us who want to run Linux on something other than a PeeCee are not left out in the cold, and makes possible native alternatives for other less popular operating systems -- Solaris, HPUX, NetBSD, etc.
There is a much simpler solution. Simply put, it is use public key cryptography to digitally sign all e-mail. Then (assuming folks protect their private keys) no one can spoof another.
If everyone (or mostly everyone) did this, then it would become pretty easy to maintain a database of known spammers. And folks like me could feel good about rejecting any e-mail that _wasn't_ signed. Think of it as caller-ID for the internet.
If a large enough group of people did this, it would probably tip the economics of sending spam away so that spammers would:
a) consider other forms of advertising in favor of e-mail spam (telephones, faxes, etc.), some of which also have regulations or cost models that limit abuse
b) probably offer special incentives for folks to get more free services in exchange for receiving advertising (i.e. revive the free-pc offers and such, but those of us who don't opt-in wouldn't need to be bothered with it)
c) start considering ways to do much more targetted spams. folks who send UCE to a few tens of of people would probably still do so, but the mass mailing of viagra adds to millions of people at once would effectively go away
Spam would still exist, but it would be relegated to the realm of minor annoyance instead of major blight upon the face of the internet.
As long as anyone can send bulk e-mail to millions of people for nearly free, using anonymous addressing, we will continue to see these problems we have today, like grandma getting offers for medication to correct her erectile dysnfunction.
Zombied PCs would still be a problem, but the fact that the abuse would be traceable would probably also tend to quickly convince folks with insecure machines to lock them down.
We'd still need the blacklists to maintain known lists of spammer certificates. But now it would be largely unforgeable by the spammers.
Actually, I think Harrison Ford is a pretty darn good actor with more range than you give him credit for. Look at Sabrina, Witness, K-19, and Mosquito Coast. Some of these roles are serious, and they do demonstrate range. Granted he's no Dustin Hoffman (for range), but he's a damn sight better than some of the other talentless popstars that have become popular lately.
So rather than just vote with my wallet and buy from a vendor that wants to work with me, let me see-- oh I know, I'll create a viral software license, work really hard to get it used by everyone, and then, when they are using it, force them to let me run whatever the hack I want on their hardware.
Shees, RMS, just go buy from or with a vendor who shares your views.
GPLv3 is much more of a political statement than a license designed to encourage folks to use it.
I stand fully behind the decision not to use GPLv3 in the Linux kernel.
There are strong cases where manufacturers have contractual obligations to require the hardware be "closed" against random software updates. A lot of these are used in security critical environments -- like the hardware used to manage sensitive data like your bank balances, national security interests, nuclear arsenals, etc... We do _not_ want that kind of hardware to be soft-updatable by "untrusted" code. A little blinky light telling you that your credit card database has just been compromised by unvalidated code just isn't good enough.
So, maybe its more important to some folks that the free software (lower "f") they create be reusable in these environments like this than that it makes some kind of political statement.
Heck, as a political statement, I think we are far, far better off as a world where a lot of free software is readily reusable without the GPL viral features. I think the Internet would never have taken off if the BSD networking code was not readily available under the liberal BSD license.
Oh, and for those who think they bought the hardware and so should be able to do whatever they want with it: yes, you can. You also have a right to explode your nice DVD player up with lots of TNT. But that does _not_ mean that the company that sold you the DVD player has any obligation to help you do this, and neither does it mean that just because you paid for the hardware the company should help you rewrite its controlling software. There are good reasons why the company might not want you do this, and frankly, that's their perogative as long as they are in compliance with whatever licenses _they_ are using.
Anyway, use whatever license you want on _your_ own damn code. If you've not written or developed any of the technology in use, stop bitching about the licensing decisions made by other folks. If you care so much, vote with your wallet -- if you can't find what you need under a license that meets with your philosophy, then you might have to write or hire someone to write what you need -- but that's the way it works in a capitalistic society.
And, I for one, am probably far happier as a software engineer in a capitalistic society than I would ever have been in the communistic software world that RMS and his fanboys imagine.
For the record: I have given a lot of free software of my own creation away, under GPL, BSD, and Artistic licenses. Including convincing my own management and 3rd party companies (including ATI! stay tuned for a new Radeon framebuffer driver for NetBSD) to release my work to the public under similarly open licenses.
(Heh. Frankly, if the GPLv3 were widely accepted and adopted for the Linux kernel, it would probably be a very good thing for the two operating systems I do care about: Solaris and NetBSD. Adoption of the GPLv3 by the Linux kernel would drive manufacturers in droves away from Linux and towards other less well known alternatives. And, given the quality of the code present in much of Linux, that might actually be a very good thing.:-)
Go ahead, mod me down troll, but you know I'm right.:-)
It should be possible to express *any* software as a physical circuit. It just usually isn't advantageous to do so. That requirement seems quite arbitrary to me.
Copyright only covers a specific implementation of an algorithm. Its too easy to rewrite the same algorithm from scratch, and the original inventors (who actaully did the reall innovative work) get significantly less value from their invention (and the fact that they patented) than they should. Copyright also is practically indefinite right now. So in order for copyright to cover this kind of case, you'd need to greatly broaden the definition of what copyright covers, _and_ reduce the scope.
Trade secrets don't work well either. Some problems: 1) it is hard to make software secret, unless you start selling black boxes -- there is almost always someone willing to reverse engineer, or leak it. 2) until it ceases being a secret, nobody else can benefit from it. If the secret is never leaked, then the public *never* benefits.
Remember, the idea behind patents was a limited term license, to encourage inventors to _share_ their discoveries with the public. We should actually _want_ people to patent their work rather than leave it trade secret.
The fact that we consider trade secret or copyright better alternatives strongly suggests there is something broken in our patent system, not that patents as a principle are evil.
Renewals should probably be forbidden altogether -- they defeat the purpose that patents were intended for. And small tweaks should really not work, unless the "tweak" itself passes the non-obvious test, and then only the tweak should be covered by a new patent, with no impact on the terms of the original patent.
The one counter example I offer to "software" would be RSA. Its not that the software implementation of RSA should be patentable, but clearly the algorithm of how this is used for public key was innovative, new, and deserving of a patent. Or look at the general diffie-hellman public key patents. These inventions may have done more for society than the vast majority of *hardware* patents, at least in the long term.
My point here is that I don't think you can just outright say software shouldn't be patentable. Instead, I think we should spend more effort to prevent e.g. obvious patents like "on the internet" or the 1-click patents that are so obviously non-innovative.
That patents *do* expire is a good thing (unlike copyright which practically never expires). I think 17 years is too long a time in many cases, especially for software algorithms. A time window of about half that seems more in line, giving the inventors a nice window to capitalize on their inventions, while ensuring that the general public also benefits from the invention at some reasonable time.
Oh, and there should definitely be some more protection against patent trolling and submarine patents -- you shouldn't be able to start enforcing a patent if you have knowingly allowed it to be used without enforcement. And you should have to demonstrate a loss of revenue before litigation against offenders is allowed.
First off, way too many non-innovative software patents are issued. 1-click is just an example. Basically, these patents fail the test for non-obviousness and should never have been patented. (The test for obviousness should include a question of, "if you were asked to solve this problem, how would you solve it?" If the same answer is likely to be arrived at by a significant percentage of developers, then it shouldn't be patentable.)
But some truly innovative things have been patented, and it seems like a reasonable idea to allow for patents for those things. An example I'll cite is the patents on certain encryption technology like RSA. While the RSA patent has hurt some software innovation elsewhere (particularly in the FOSS world), by and large the inventors have added an immense value to the software ecosystem and the economy as a whole, and it seems fair that they should be able to reap their just rewards. A short term monopoly on the technology they invented is reasonable, I think.
But it also seems reasonable to shorten the term limit on software patents. A ten year patent gives the holder a nice window to reap the rewards, while ensuring that the patented IP will eventually fall into the public domain before it loses all of its relevance.:-)
Trade secrets as an alternative to patenting don't work well, IMO, because they are too easily leaked or reverse engineered, and then the secret is worthless. The RC5 algorithm is an example of this, as are the work to reverse engineer the p54 softmac firmware or the broadcom wifi drivers on Linux.
Now, this case is great in that it may prevent submarine patents that have plagued the industry recently.
The other good news about software patents is that they do expire, and much earlier than copyright.
The point is, the BSD folks *encourage* this kind of piggybacking, but don't require that someone who uses it has to make their stuff open too.
Here's what the GPL would do if it applied to produce instead of software:
"Here's an apple, and the particular methods I used to grow it. If you buy these apples and put them in an apple pie that you sell in a restaurant then you must also provide the recipe that you used to make that pie, and anyone else who changes that recipe must also provide their changes, etc."
This isn't about IP protection like DMCA or Patent Laws. This is about the fact that I should be allowed to retain trade secrets. And code can be trade secrets.
The *people* writing the code for all these drivers try to ensure it.
I seem to recall that one of the reasons that Linus quoted for not wanting proprietary code in the kernel was to minimize the support headaches from people who had "issues", where he couldn't debug the problem.
The FSF takes one stand on the GPL, and that is that all software should be free.
As I understand it, Linus takes a very different stand. That stand is that he wants *his* software to be free.
The GPL can be used as a tool to achieve both ends, but please don't assume that everyone who uses the GPL falls into the FSF camp, or vice versa.
It is *not* the BSD license that prevents you from seeing Nokia's code. It is the fact that Nokia has chosen to keep it proprietary and has chosen a code base that permits them to meet their business goals. Whether it be BSD, WinCE, VxWorks, or whatever.
The only way GPL can change this is to become so prevalent that vendors like Nokia have no other choices (like BSD, WinCE, VxWorks, etc.) to Linux. This isn't going to happen folks -- waaayyy too many people make their living on products that either need or want to be closed source for one reason or another. Closed source OS' aren't going away anytime soon.
If *you* don't like it, don't buy a Nokia phone, instead find a vendor that wants to keep it open -- if you can find one. If you can't find one, *start your own company* using open source (good luck...) Or make do *without*. After all, 20 years ago nobody had cell phones, and we all seemed to get along okay. Nowhere is it is written that you have a *right* to own a cell phone (created by someone else), and that the firmware on it should be in your control.
But don't claim that the existence of BSD licensed code is keeping you from being to see the sources. Unless you're Richard Stallman and believe that every line of source code ever written should be out for everyone to freely see or modify.
Actually, what is the logic behind RMS' assertion that *all* software should be open and free? Why is software running on your cellphone somehow different than, say, the design schematics of the processor and board inside it, or the design of the spark plugs in your car, or for that matter, the particular water and fertilizer rations that a farmer uses to get those extra sweet oranges that you bought at the supermarket last week?
RMS and the GPL fan-boyz are just looking for another handout, trying to piggy back off someone elses' hard labor. Hey I've been there too wishing that I had access to the sources for a certain piece of software, but _get over it_. We (at least in places like the US) live in a world run by real-world capitalism, and not everything should be free or equal. (This is much the same, btw, as folks that think that they shouldn't have to pay for access to the latest hip-hop or whatever. What a bunch of BS.)
By the way, I have worked actively on GPL, BSD, and proprietary licensed software. There is a use for all of it. I love using GPL for software that I don't want someone else to suck up into their proprietary product, but a lot of times I'd rather let folks use my work for commercial closed-source products and maybe improve the world a little bit by doing so. So its not one license is right or wrong, but that one license (or one view that all software should be free and open) is by definition inadequate.
I'm not sure the IBM case is relevant. IBM probably didn't have an EULA that required IBM DOS to run on IBM hardware. In any case, MS-DOS was available separately (not sure when MS released their edition of DOS, though), and wouldn't have had such an EULA (microsoft being a s/w company had no reason to promote IBM's PC lock-in). To some extent the case here predates shrink-wrap license agreements anyway. (Also, IBM *published* the BIOS source code, but under very limited terms!)
If someone built a 100% Mac clone, it would be legal. But would it be legal to run MacOS on it? Probably not? EULAs stipulate no more than one copy on a computer a time. Some EULAs stipulate you can't use the software for "life-threatening" purposes (nuclear power, weapons, or aircraft control as an example.) GPLv3 has all kinds of license restrictions in it. Why couldn't Apple's EULA just as well stipulate a hardware restriction? I don't see a fundamental legal difference here. Its their code, they can license it under whatever terms they see fit.
As far as PearPC goes, there is no leverage. PearPC isn't in violation of the terms (well, they might be, but that's a different problem), its the *end-users* who are in violation. Apple's case in court is very shaky at best.
It used to be that certain techniques could be used to reverse engineer for the purposes of e.g. building a clone. With DRM and DMCA, the rules have changed. If PearPC *reverse engineers* MacOS for the purposes of breaking the DRM, within the USA they could have big trouble with DMCA.
Of course, in jurisdictions where DMCA is not valid, Apple can't fight the cloners. But they can still go after end-users who violate the EULA.
MacOS X is licensed to run on one computer, and one computer only. Now, if you bought MacOS X to run on your MAC, and then installed it on your PC -- I surely hope you deinstalled it from your MAC. Because if you didn't you'd be in violation of your EULA.
Apple is certainly going to try very, very hard to prevent folks from running MacOS on non-Apple h/w, because lets face it, MacOS is just a vehicle to sell hardware. You can argue that you should be able to purchase a Mac, throw the h/w away, and then put MacOS on your PC. Of course, you'd still be violating the EULA.
Apple has a right to try to make it "hard" to do this -- you're trying to use the product in a way that it is not sold for. I'd do the same if I were Apple, precisely to prevent folks from pirating it, unless I was prepared to shift gears into being a *software* company. (And then I'd probably try to come up with another solution, ala XP's hated activation.)
Even if Apple starts selling MacOS X separately, they have every right to have a EULA that requires it to run on Apple hardware. And they have a right to reasonable technical measures to ensure that you're not in violation of the EULA. (The caveat here is that I think they need to disclose the requirement "only for use with Apple hardware" on the packaging.)
If you don't like that requirement, then vote with your feet and don't buy it. Certainly, don't *steal* it buy pirating it.
And that's really what it comes down to, isn't it? Folks aren't happy because Apple wants to make money on hardware, and they've come up with a nify OS for it. While I agree it would be nice to run that nifty OS on some other hardware, I cannot force it. So, if I want to use the OS, I have to pay the piper...err Apple. Too rich for my blood? Live without. (And ultimately, that's the choice I've made. I don't have a MAC, and as nice as MacOS seems, I actually prefer to use Solaris. So I'm no Apple fanboy.)
Btw, I feel the same way about DRM'd media. If the media companies properly disclose any use limitations, then we the consumers have no *rights* to do otherwise with the content. Don't like it, don't buy it, and don't use it.
The there is no god-given right to use MacOS X, nor is there one to watch a given movie on your personal computer. Either live with the licensing restrictions or go elsewhere. (And for pete's sake, don't pirate. Show some strength in your convictions if you're going to proclaim the evilness of DRMd content.)
By acquiring the images, you probably *have* harmed someone, even if not directly. Even if you don't purchase the image directly, someone must have had some reason for making the image available to you. (Outside of law enforcement purposes.) Did you visit a subscription website that had these on them? Maybe the website was free but makes money on advertising.
The point is, that if you have them (knowingly), then you are participating in the crime.
There are times when participation and commission of the act should be legally distinct. I don't think child porn is one of those cases.
I do think it should be a valid defense if you were unaware that you had child porn in your possession, to answer one of your other doubts.
Nutshell: I think that possession of child porn *is* as bad as producing (in the movie or photography sense) it, and should be punished accordingly.
This is based upon the following assumptions:
1) possession implies that you are creating a market for the material -- if the market dries up, maybe some children will not need to fall prey to this kind of sickness
2) the material can be "inciteful" of the deed -- meaning if you use child porn to get off, then it might follow that you would actually like to commit these acts -- and if that possession is allowed to distribute, there is the risk that you might "inspire" similar behavior in others
I think anyone who knowingly and willfully possesses or traffics in child porn should be held accountable to the strongest punishment the law allows.
Now, I suppose if someone found child porn on your computer, and you were unaware of it, then this would be a reasonable defense.
By the way, I believe (in the US) we have similar laws regarding possession of stolen property. Regardless of whether or not you actually stole it, if it was stolen and you possess it with the knowledge that it was stolen, you can be punished accordingly.
Of course, IANAL, criminal, or otherwise involved in the legal justice system.
It seems there is a lot of confusion about the requirement for encryption keys and such.
I believe RMS and the FSF want to disallow the creation of environments where if you have e.g. a device (think XBox or wifi router here) based on GPL'd code, you should be able to change the code that is in the box. (I think RMS takes it a step further, as he states that he believes that any kind of device that *doesn't* let you do this uses proprietary software and is hence immoral.)
There are a lot of special devices out there, and sometimes you need encryption and signed code for things other than DRM.
Examples: embedded wifi firmware. Now it stands to reason that if I'm a vendor, I could gain a lot by using Linux or somesuch in this device. But FCC says I have to lock down the radio so end users cannot make it do things not intended by the mfg. Well, if it is a software programmable radio, the best (and maybe only) way to achieve that while allowing for firmware updates is to use signed firmware. Under GPLv3, I cannot make this device.
Security devices. I've worked on a FIPS-140-2 certified device that has a secure key store. It was based on VxWorks, but it could have easily have been done on Linux. But in order to guarantee the integrity of the key material on the device, you have to be certain that the end user CANNOT UPDATE THE CODE UNLESS IT IS SIGNED. These kinds of devices are incredibly useful, and frankly necessary to ensure security in certain eCommerce transactions, etc.
Again, these kinds of solutions have nothing to do with DRM, but are perfectly valid kinds of platforms. GPLv3 code cannot be used here. (And, GPLv2 code is subject to debate, depending, I think, on who is interpreting the boundaries. GPLv3 really clarifies, I think, the position of the FSF.)
RMS and co. want to prevent these kinds of things being developed with GPL code. Furthermore, I think the GPL and some supporting quotes from RMS and co. can be taken to mean that one of the GPL's goals is to actually prevent proprietary code from existing at all. The impact on DRM is just a side effect, but I think it is such a hot button that the community has latched on to it.
Linus seems a bit more reasonable and I think he actually wants companies to develop products on Linux, and devices like the ones I mentioned above might even seem reasonable devices to base on Linux. He just wants to make sure that he gets a copy of the source code changes so that the project can ultimately benefit. This is a totally different position than the "if I can't modify and redistribute the software then it is illegal" position of the FSF.
By the way, I've distributed code under GPL, LGPL, and BSD. Each has their own particular use -- no one license serves all needs. Adding GPLv3 to the mix doesn't change this, but it does add a new choice. (One I personally am not likely to use for any of the code I distribute, but then I like the idea of people being able to use my code in proprietary applications, as long as I get credit and a copy of any improvements.)
Binary compatibility is no more necessary for Solaris than it is for Linux. It has nothing to do with being open-source or proprietary. (I have released open source drivers for Solaris, and I have also worked on closed source drivers. There are good reasons for allowing both.) Binary compatibility is necessary for Sun for one simple reason: commercial viability. Sun's customers and partners insist on having a binary compatible API, and binary (and source!) compatibility from one release to the next are a major selling point for Sun's enterprise customers.
Linux still takes the hobbyist approach, where everyone should be expected to be able to recompile the kernel and device drivers. This is BSD unix legacy circa 1982, where to add a driver you had to recompile the kernel. Now Linux isn't quite that bad, but you still are expected to have to compile the *driver*.
Lets take the case of the company that wants to support this kind of environment:
1) Which version of the Linux kernel (2.2, 2.4, or 2.6? What about patch revs?)
do my customers need?
2) Which userland environment do I support (where are kernel modules installed
for example? It varies from distro to distro, folks!)
3) Which *compiler* version is being used? Gcc 3.3, 3.4, 4.x? Have I tested my
driver for these?
4) What other kernel patches have been applied by the end user? Have they busted
an interface or changed a header in some way?
Obviously directly "supporting" the device on something like Linux is going to be a great challenge.
In order to for there to be any economic incentive for hardware developers to sell to Linux masses, they need to be able to provide full support *and advertise it*.
The random home users who are willing to purchase caveat emptor devices are simply not enough of a market to be commercially interesting for these companies. (A well known WiFi vendor wasn't interesting in dealing with us for WiFi for Solaris in quantities less than a million or so, and Intel won't even sell their wireless parts without a motherboard attached.) The WinTel market is so enormous that the home Linux hobbyist community doesn't represent even a reportable fraction of their market.
That said, there are other real considerations for closed source drivers:
1) a lot of times the knowledge about the intricacies of the device are either not well documented, or documented only in a form that is inseparable from details that are proprietary (e.g. device driver author expected to be able to read device schematics).
2) a lot of devices are so similar (e.g. OEM branded devices, or devices with common ancestry like various tulip variants) or the driver can employ similar techniques that a company doesn't want to do the initial development or documentation work just to enable a competitor to get a mostly free ride
3) sometimes there are real innovations in device drivers -- e.g. when I was at Sun I wrote a Solaris driver for a crypto part that had near linear scalability for adding new crypto parts. This was a unique innovation and allowed us to set a world record for SSL performance. Giving the technology away free would have allowed any other crypto vendor to do the same.
4) there may be legal considerations involved. E.g. drivers with ancestry dating back to some other licensed software, or the already mentioned FCC rules. (And for the record, the FCC smackdown will come to the hardware company, not against the home user.)
5) there may be marketing considerations in hiding the details of a device. E.g. if you have to do some ugly performance impacting workarounds in software, are you going to want to tell folks about this?
6) if you have a suitably complex device, you might not want to enable others to reverse engineer details ab
Slashdot Mirror
Counter-example: DTrace. Real innovation, that was recently imported into FreeBSD and MacOS X. The effort to do this import was almost certainly non-trivial, so it stands to reason that FreeBSD and MacOS X teams at Apple valued this contribution. Furthermore, the import of DTrace by Apple is notable in that it was performed by Apple entirely on its own (i.e. Apple paid engineering time for this), and that Apple is a commercial competitor to Sun.
I take significant exception to that statement. Ever hear of any of the BSD operating systems? Maybe you mean most popular open source kernel. As a kernel developer who has worked on 3 different open source kernels, I can tell you that about the only thing Linux has over the competition is popularity, and I believe that is mostly due to historical accident. Most of the rest of the Linux kernel is simply amazing in that it works at all -- a lot of what is in Linux is engineering by accident rather than engineering by design. And if you go back far enough in Linux history, you will find major events that demonstrate this. (C.f. the abortive "experiment" in trying to make the Linux kernel a C++ program. Or look at the numerous band-aids to major kernel subsystems, that have been one band-aid after another, until certain subsystems are more band-aid than designed product. The evolution of the filesystems over the years is a good example of this. Or the various libc fiascos. Or the lack of any stable kernel API. Etc. etc. ad nasuem.)
First, the open source community != the Linux community. I'm an active NetBSD committer (I recently contributed a radeon framebuffer driver, for example), and an active contributor to OpenSolaris. I don't think it is fair to ignore these other open source efforts.
Second, there are folks in the Linux camp that have claimed that it is against the GPL to even load a proprietary kernel module into Linux. Certainly, Donald Becker has claimed in the past that attempts to port his code to a non-GPL operating system would be met with litigation. Look at the whole binary blob nonsense going on now. If this isn't a religious war, then I don't know what is.
Third, Sun (and almost anyone who wants to do anything commercial with Open Source) abhors GPL, with good reason. Its viral nature makes it almost impossible to use with any other code -- even BSD licensed code is incompatible with GPL. Don't blame a commercial entity for not sharing its crown jewels (which in this case represent millions, and for all I know billions, of dollars of R&D investment) under your terms. Shees.
Fourth, as a person who has donated GPL code in the past, GPL scares me. Specifically, GPLv2 automatically grants permission for my code to be released under GPLv3. Unfortunately, I was too short sighted to realize that RMS/FSF were going to use future GPL versions to make a political statement that I might not agree with. I now strongly regret ever releasing any of my code under GPL. It would have been better to use a BSD license for some of that stuff, or to remove the clause explicitly allowing "license upgrade" (or, in my opinion, downgrade.)
Recall NFS was designed in 1984. At the time it was a major innovation. You are comparing 20 year old technology with today's standards. And even Sun recognized those flaws and added innovations like cachefs, SecureNFS, and ultimately, NFSv4. (And, they even gave the source code for NFSv4 away, and funded Linux development of an NFSv4 client.)
By the way, I suppose you'll hold up SMB/CIFS as a paragon of distributed filesystem design? The only truly nice distributed filesystems I've worked with is AFS, and IBM kept not only the implementation proprietary, but also the specifications, so that the only way to to get it was to buy it from IBM. (You could get DFS from OSF, but that cost big $$ too!) IBM only opened up AFS when it had become obvious that it had lost all market relevance.
So I suppose OpenOffice is a totally useless contribution? Or the major contributions to Gnome? Or the work they did on Mozilla?
I think you need to compare Sun with the alternatives. The alternatives are companies that don't even open up the standards that let you communicate with their technology (Microsoft, IBM in the form of its database and Lotus products, etc.) The only reason IBM is contributing to Linux at all is so they don't have to have their own OS staff in house, and can commercialize the open source produced by others -- including, by the way, Sun.
Gimme a break. Do you even understand why Sun wants to retain control sometimes? A big part of the Java debate, for example, can be traced to history where Microsoft tried to destroy the run-anywhere value proposition by sabotaging Java. The Java licenses were designed (among other things) to protect against abuses like this.
Sun's OpenSolaris license is widely reusable, and is basically a set of improvements upon the MPL.
Anyway, you seem to you be one of those conspiracy theorists that think Sun is evil because it gives stuff away for free. Its important that to note that just sticking everything under the planet under a GPL may not be a good idea -- Sun wants folks to be able to things with the code that, quite frankly, GPL is not well suited to.
Just because everyone doesn't buy in to RMS' idealism doesn't mean that they're out to ruin the open software community. Heck, I believe that the open software _community_ as such (and Linux in particular) would either not exist at all, or just be a lunatic toy, if it weren't for the efforts of Sun. And those efforts long predate IBM's investment in Linux.
And for what it is worth, I think there is some push to move a lot of the previous contributions under CDDL or GPL. The p
NFS was developed in 1984. Long before Linux even existed. It was engineered from the get-go to be open-standard (not necessarily open-source). It was specified in a number of RFCs. Look for example at RFC 1094, which bears a publish date of 1989. This again, was before Linux was on the scene.
At the time, the _implementation_ was proprietary. Sun espoused the ideals of open standards and private implementation. These were also, by the way, the same ideals that allowed your beloved Linux to flourish. To a certain extent, it still does. (The idea being that in a competitive markets, companies should be free to innovate and compete on the basis of their implementation, but that the industry needs interoperability. I still think this idea has a lot of merit.)
The actual open SOURCE for NFS itself was done in 2000. I believe there were releases under more restrictive licenses than that earlier.
By the way, there are other open source OS' than Linux. And there always have been, at least as long as Linux has been around. (386BSD was around at about the same time as Linux, an, IIRC, it had better/more stable networking earlier than Linux did.)
By the way, did you know that Sun is the single largest contributor of open source to the community, surpassing even UC Berkeley?
You are exactly right in that these critera don't make a project Open Source. But OpenSolaris is freely downloadable, modifiable, and redistributable. You can make your own distro. And Sun can't revoke that right away. So, by the standards that I think most knowledgable OSS folks use (including the OSI), OpenSolaris _is_ Open Source. IBM is just spouting FUD, and showing their general ignorance of both Open Source and their competition. About what you'd expect from a company that is worried because it doesn't have any real competitive advantage any longer.
Ever hear of, oh, NFS. No? How about RPC? These Sun contributions to open source predate IBM's involvement with FOSS by a long time. Heck, they even predate the whole FOSS movement. Except for the University of California, Berkeley, I doubt any institution has ever given as much or as freely to open source as Sun has, as early as it did, or technologly that has done more to contribute to the developments that ultimately led to the Internet. And they have continued to support open source (and open standards) throughout their history.
Get your facts straight next time.
You also said:
Then WTF are you doing posting here? You obviously haven't looked into it. Yes, OpenSolaris is mostly OpenSource (there are a few closed bits, but they are not necessarily critical bits anyway). And guess what? Just because Sun has control of OpenSolaris, doesn't mean you can't download the whole source tree and fork it and start your own project. (Some folks have already done this, check out the PPC port of Solaris, or the port of Debian userland to the Solaris kernel, for example.) That is what Open Source means.Somebody mod the parent down, please!
I am an outside contributor to OpenSolaris. I have several projects which are currently in the process of getting integrated into Solaris.
It is true that the development model at Sun is a bit more "Cathedral" than "Bazaar", and there are still some technical and administrative challenges to solve (for example they haven't figured out how to get folks to directly commit to OpenSolaris yet -- you have to hand off code to folks at Sun who integrate your code and walk it thru the process.)
Development of Solaris has always been a tricky thing, and historically has had huge amounts of "process" to get changes. This is because there are numerous quality safeguards, and committees that have been involved. There are famous questions that every project integrating has historically had to answer: (is it i18n safe, what interfaces does it expose? does it conform to various standards already established? is it portable to both intel and sparc? etc. etc.)
Part of the review process also has to uphold things like Sun's binary compatibility guarantee. In any respects, the _quality_ of Sun's Solaris product is much higher, I think, than what you find in say Linux, where churn is a lot higher and quality and oversight controls a bit less.
Anyway, it is possible to contribute to OpenSolaris now, though its a bit of a rough road right now. But they are making it better, and I expect it will be a lot easier in the next year or so.
You might want to review the original posting. I never said anything about downloading DLLs from Microsoft.
Furthermore, I run on NetBSD and Solaris, and have _never_ downloaded any microsoft codecs, legally or otherwise. Mostly this is because THEY WOULD BE TOTALLY USELESS ON MY ULTRASPARC AND MIPS HARDWARE. So content in WMV has typically not been available to me.
But in any case, I was under the impression that a fair number of codecs were closed source, including the ones Microsoft promotes for use by content producers. If this is not the case, then I apologize for my misunderstanding.
My original point, that having open source for this stuff (whether from a settlement with Microsoft due to litigation or otherwise) is going to be a very good thing.
While I do contribute heavily to opensource development, I don't have the time or energy to start writing my own codecs from documents that may or may not exist, and may or may not be sufficient to create an implementation. So, in summary, thank you Real for working to get this technology into Open Source, in one fashion or another.
Having _open source_ versions of these codecs means that lots of other FOSS can make use of them, not just RealPlayer/HelixPlayer.
Its small victories like this that make the whole litigation against monopolists like Microsoft worthwhile. Sure the billions in payoffs are great, but what really, really helps advance the field is the opening up of proprietary formats and protocols.
It also means that those of us who want to run Linux on something other than a PeeCee are not left out in the cold, and makes possible native alternatives for other less popular operating systems -- Solaris, HPUX, NetBSD, etc.
There is a much simpler solution. Simply put, it is use public key cryptography to digitally sign all e-mail. Then (assuming folks protect their private keys) no one can spoof another.
If everyone (or mostly everyone) did this, then it would become pretty easy to maintain a database of known spammers. And folks like me could feel good about rejecting any e-mail that _wasn't_ signed. Think of it as caller-ID for the internet.
If a large enough group of people did this, it would probably tip the economics of sending spam away so that spammers would:
a) consider other forms of advertising in favor of e-mail spam (telephones, faxes, etc.), some of which also have regulations or cost models that limit abuse
b) probably offer special incentives for folks to get more free services in exchange for receiving advertising (i.e. revive the free-pc offers and such, but those of us who don't opt-in wouldn't need to be bothered with it)
c) start considering ways to do much more targetted spams. folks who send UCE to a few tens of of people would probably still do so, but the mass mailing of viagra adds to millions of people at once would effectively go away
Spam would still exist, but it would be relegated to the realm of minor annoyance instead of major blight upon the face of the internet.
As long as anyone can send bulk e-mail to millions of people for nearly free, using anonymous addressing, we will continue to see these problems we have today, like grandma getting offers for medication to correct her erectile dysnfunction.
Zombied PCs would still be a problem, but the fact that the abuse would be traceable would probably also tend to quickly convince folks with insecure machines to lock them down.
We'd still need the blacklists to maintain known lists of spammer certificates. But now it would be largely unforgeable by the spammers.
Actually, I think Harrison Ford is a pretty darn good actor with more range than you give him credit for. Look at Sabrina, Witness, K-19, and Mosquito Coast. Some of these roles are serious, and they do demonstrate range. Granted he's no Dustin Hoffman (for range), but he's a damn sight better than some of the other talentless popstars that have become popular lately.
So, a printer won't do what you want it to.
:-)
:-)
So rather than just vote with my wallet and buy from a vendor that wants to work with me, let me see-- oh I know, I'll create a viral software license, work really hard to get it used by everyone, and then, when they are using it, force them to let me run whatever the hack I want on their hardware.
Shees, RMS, just go buy from or with a vendor who shares your views.
GPLv3 is much more of a political statement than a license designed to encourage folks to use it.
I stand fully behind the decision not to use GPLv3 in the Linux kernel.
There are strong cases where manufacturers have contractual obligations to require the hardware be "closed" against random software updates. A lot of these are used in security critical environments -- like the hardware used to manage sensitive data like your bank balances, national security interests, nuclear arsenals, etc... We do _not_ want that kind of hardware to be soft-updatable by "untrusted" code. A little blinky light telling you that your credit card database has just been compromised by unvalidated code just isn't good enough.
So, maybe its more important to some folks that the free software (lower "f") they create be reusable in these environments like this than that it makes some kind of political statement.
Heck, as a political statement, I think we are far, far better off as a world where a lot of free software is readily reusable without the GPL viral features. I think the Internet would never have taken off if the BSD networking code was not readily available under the liberal BSD license.
Oh, and for those who think they bought the hardware and so should be able to do whatever they want with it: yes, you can. You also have a right to explode your nice DVD player up with lots of TNT. But that does _not_ mean that the company that sold you the DVD player has any obligation to help you do this, and neither does it mean that just because you paid for the hardware the company should help you rewrite its controlling software. There are good reasons why the company might not want you do this, and frankly, that's their perogative as long as they are in compliance with whatever licenses _they_ are using.
Anyway, use whatever license you want on _your_ own damn code. If you've not written or developed any of the technology in use, stop bitching about the licensing decisions made by other folks. If you care so much, vote with your wallet -- if you can't find what you need under a license that meets with your philosophy, then you might have to write or hire someone to write what you need -- but that's the way it works in a capitalistic society.
And, I for one, am probably far happier as a software engineer in a capitalistic society than I would ever have been in the communistic software world that RMS and his fanboys imagine.
For the record: I have given a lot of free software of my own creation away, under GPL, BSD, and Artistic licenses. Including convincing my own management and 3rd party companies (including ATI! stay tuned for a new Radeon framebuffer driver for NetBSD) to release my work to the public under similarly open licenses.
(Heh. Frankly, if the GPLv3 were widely accepted and adopted for the Linux kernel, it would probably be a very good thing for the two operating systems I do care about: Solaris and NetBSD. Adoption of the GPLv3 by the Linux kernel would drive manufacturers in droves away from Linux and towards other less well known alternatives. And, given the quality of the code present in much of Linux, that might actually be a very good thing.
Go ahead, mod me down troll, but you know I'm right.
It should be possible to express *any* software as a physical circuit. It just usually isn't advantageous to do so. That requirement seems quite arbitrary to me. Copyright only covers a specific implementation of an algorithm. Its too easy to rewrite the same algorithm from scratch, and the original inventors (who actaully did the reall innovative work) get significantly less value from their invention (and the fact that they patented) than they should. Copyright also is practically indefinite right now. So in order for copyright to cover this kind of case, you'd need to greatly broaden the definition of what copyright covers, _and_ reduce the scope. Trade secrets don't work well either. Some problems: 1) it is hard to make software secret, unless you start selling black boxes -- there is almost always someone willing to reverse engineer, or leak it. 2) until it ceases being a secret, nobody else can benefit from it. If the secret is never leaked, then the public *never* benefits. Remember, the idea behind patents was a limited term license, to encourage inventors to _share_ their discoveries with the public. We should actually _want_ people to patent their work rather than leave it trade secret. The fact that we consider trade secret or copyright better alternatives strongly suggests there is something broken in our patent system, not that patents as a principle are evil. Renewals should probably be forbidden altogether -- they defeat the purpose that patents were intended for. And small tweaks should really not work, unless the "tweak" itself passes the non-obvious test, and then only the tweak should be covered by a new patent, with no impact on the terms of the original patent.
The one counter example I offer to "software" would be RSA. Its not that the software implementation of RSA should be patentable, but clearly the algorithm of how this is used for public key was innovative, new, and deserving of a patent. Or look at the general diffie-hellman public key patents. These inventions may have done more for society than the vast majority of *hardware* patents, at least in the long term.
My point here is that I don't think you can just outright say software shouldn't be patentable. Instead, I think we should spend more effort to prevent e.g. obvious patents like "on the internet" or the 1-click patents that are so obviously non-innovative.
That patents *do* expire is a good thing (unlike copyright which practically never expires). I think 17 years is too long a time in many cases, especially for software algorithms. A time window of about half that seems more in line, giving the inventors a nice window to capitalize on their inventions, while ensuring that the general public also benefits from the invention at some reasonable time.
Oh, and there should definitely be some more protection against patent trolling and submarine patents -- you shouldn't be able to start enforcing a patent if you have knowingly allowed it to be used without enforcement. And you should have to demonstrate a loss of revenue before litigation against offenders is allowed.
First off, way too many non-innovative software patents are issued. 1-click is just an example. Basically, these patents fail the test for non-obviousness and should never have been patented. (The test for obviousness should include a question of, "if you were asked to solve this problem, how would you solve it?" If the same answer is likely to be arrived at by a significant percentage of developers, then it shouldn't be patentable.)
But some truly innovative things have been patented, and it seems like a reasonable idea to allow for patents for those things. An example I'll cite is the patents on certain encryption technology like RSA. While the RSA patent has hurt some software innovation elsewhere (particularly in the FOSS world), by and large the inventors have added an immense value to the software ecosystem and the economy as a whole, and it seems fair that they should be able to reap their just rewards. A short term monopoly on the technology they invented is reasonable, I think.
But it also seems reasonable to shorten the term limit on software patents. A ten year patent gives the holder a nice window to reap the rewards, while ensuring that the patented IP will eventually fall into the public domain before it loses all of its relevance. :-)
Trade secrets as an alternative to patenting don't work well, IMO, because they are too easily leaked or reverse engineered, and then the secret is worthless. The RC5 algorithm is an example of this, as are the work to reverse engineer the p54 softmac firmware or the broadcom wifi drivers on Linux.
Now, this case is great in that it may prevent submarine patents that have plagued the industry recently.
The other good news about software patents is that they do expire, and much earlier than copyright.
The point is, the BSD folks *encourage* this kind of piggybacking, but don't require that someone who uses it has to make their stuff open too.
Here's what the GPL would do if it applied to produce instead of software:
"Here's an apple, and the particular methods I used to grow it. If you buy these apples and put them in an apple pie that you sell in a restaurant then you must also provide the recipe that you used to make that pie, and anyone else who changes that recipe must also provide their changes, etc."
What a bunch of crap.
This isn't about IP protection like DMCA or Patent Laws. This is about the fact that I should be allowed to retain trade secrets. And code can be trade secrets.
The GPL doesn't try to ensure this at all.
The *people* writing the code for all these drivers try to ensure it.
I seem to recall that one of the reasons that Linus quoted for not wanting proprietary code in the kernel was to minimize the support headaches from people who had "issues", where he couldn't debug the problem.
The FSF takes one stand on the GPL, and that is that all software should be free.
As I understand it, Linus takes a very different stand. That stand is that he wants *his* software to be free.
The GPL can be used as a tool to achieve both ends, but please don't assume that everyone who uses the GPL falls into the FSF camp, or vice versa.
No, please stop spreading this FUD.
It is *not* the BSD license that prevents you from seeing Nokia's code. It is the fact that Nokia has chosen to keep it proprietary and has chosen a code base that permits them to meet their business goals. Whether it be BSD, WinCE, VxWorks, or whatever.
The only way GPL can change this is to become so prevalent that vendors like Nokia have no other choices (like BSD, WinCE, VxWorks, etc.) to Linux. This isn't going to happen folks -- waaayyy too many people make their living on products that either need or want to be closed source for one reason or another. Closed source OS' aren't going away anytime soon.
If *you* don't like it, don't buy a Nokia phone, instead find a vendor that wants to keep it open -- if you can find one. If you can't find one, *start your own company* using open source (good luck...) Or make do *without*. After all, 20 years ago nobody had cell phones, and we all seemed to get along okay. Nowhere is it is written that you have a *right* to own a cell phone (created by someone else), and that the firmware on it should be in your control.
But don't claim that the existence of BSD licensed code is keeping you from being to see the sources. Unless you're Richard Stallman and believe that every line of source code ever written should be out for everyone to freely see or modify.
Actually, what is the logic behind RMS' assertion that *all* software should be open and free? Why is software running on your cellphone somehow different than, say, the design schematics of the processor and board inside it, or the design of the spark plugs in your car, or for that matter, the particular water and fertilizer rations that a farmer uses to get those extra sweet oranges that you bought at the supermarket last week?
RMS and the GPL fan-boyz are just looking for another handout, trying to piggy back off someone elses' hard labor. Hey I've been there too wishing that I had access to the sources for a certain piece of software, but _get over it_. We (at least in places like the US) live in a world run by real-world capitalism, and not everything should be free or equal. (This is much the same, btw, as folks that think that they shouldn't have to pay for access to the latest hip-hop or whatever. What a bunch of BS.)
By the way, I have worked actively on GPL, BSD, and proprietary licensed software. There is a use for all of it. I love using GPL for software that I don't want someone else to suck up into their proprietary product, but a lot of times I'd rather let folks use my work for commercial closed-source products and maybe improve the world a little bit by doing so. So its not one license is right or wrong, but that one license (or one view that all software should be free and open) is by definition inadequate.
A standard copyright grants *no* rights. EULAs also grant rights to use (albeit under limited terms).
Some of the restrictions in GPLv3 relating to DRM were what I was referring to.
I'm not sure the IBM case is relevant. IBM probably didn't have an EULA that required IBM DOS to run on IBM hardware. In any case, MS-DOS was available separately (not sure when MS released their edition of DOS, though), and wouldn't have had such an EULA (microsoft being a s/w company had no reason to promote IBM's PC lock-in). To some extent the case here predates shrink-wrap license agreements anyway. (Also, IBM *published* the BIOS source code, but under very limited terms!)
If someone built a 100% Mac clone, it would be legal. But would it be legal to run MacOS on it? Probably not? EULAs stipulate no more than one copy on a computer a time. Some EULAs stipulate you can't use the software for "life-threatening" purposes (nuclear power, weapons, or aircraft control as an example.) GPLv3 has all kinds of license restrictions in it. Why couldn't Apple's EULA just as well stipulate a hardware restriction? I don't see a fundamental legal difference here. Its their code, they can license it under whatever terms they see fit.
As far as PearPC goes, there is no leverage. PearPC isn't in violation of the terms (well, they might be, but that's a different problem), its the *end-users* who are in violation. Apple's case in court is very shaky at best.
It used to be that certain techniques could be used to reverse engineer for the purposes of e.g. building a clone. With DRM and DMCA, the rules have changed. If PearPC *reverse engineers* MacOS for the purposes of breaking the DRM, within the USA they could have big trouble with DMCA.
Of course, in jurisdictions where DMCA is not valid, Apple can't fight the cloners. But they can still go after end-users who violate the EULA.
Its really, really simple.
...err Apple. Too rich for my blood? Live without. (And ultimately, that's the choice I've made. I don't have a MAC, and as nice as MacOS seems, I actually prefer to use Solaris. So I'm no Apple fanboy.)
MacOS X is licensed to run on one computer, and one computer only. Now, if you bought MacOS X to run on your MAC, and then installed it on your PC -- I surely hope you deinstalled it from your MAC. Because if you didn't you'd be in violation of your EULA.
Apple is certainly going to try very, very hard to prevent folks from running MacOS on non-Apple h/w, because lets face it, MacOS is just a vehicle to sell hardware. You can argue that you should be able to purchase a Mac, throw the h/w away, and then put MacOS on your PC. Of course, you'd still be violating the EULA.
Apple has a right to try to make it "hard" to do this -- you're trying to use the product in a way that it is not sold for. I'd do the same if I were Apple, precisely to prevent folks from pirating it, unless I was prepared to shift gears into being a *software* company. (And then I'd probably try to come up with another solution, ala XP's hated activation.)
Even if Apple starts selling MacOS X separately, they have every right to have a EULA that requires it to run on Apple hardware. And they have a right to reasonable technical measures to ensure that you're not in violation of the EULA. (The caveat here is that I think they need to disclose the requirement "only for use with Apple hardware" on the packaging.)
If you don't like that requirement, then vote with your feet and don't buy it. Certainly, don't *steal* it buy pirating it.
And that's really what it comes down to, isn't it? Folks aren't happy because Apple wants to make money on hardware, and they've come up with a nify OS for it. While I agree it would be nice to run that nifty OS on some other hardware, I cannot force it. So, if I want to use the OS, I have to pay the piper
Btw, I feel the same way about DRM'd media. If the media companies properly disclose any use limitations, then we the consumers have no *rights* to do otherwise with the content. Don't like it, don't buy it, and don't use it.
The there is no god-given right to use MacOS X, nor is there one to watch a given movie on your personal computer. Either live with the licensing restrictions or go elsewhere. (And for pete's sake, don't pirate. Show some strength in your convictions if you're going to proclaim the evilness of DRMd content.)
By acquiring the images, you probably *have* harmed someone, even if not directly. Even if you don't purchase the image directly, someone must have had some reason for making the image available to you. (Outside of law enforcement purposes.) Did you visit a subscription website that had these on them? Maybe the website was free but makes money on advertising.
The point is, that if you have them (knowingly), then you are participating in the crime.
There are times when participation and commission of the act should be legally distinct. I don't think child porn is one of those cases.
I do think it should be a valid defense if you were unaware that you had child porn in your possession, to answer one of your other doubts.
Nutshell: I think that possession of child porn *is* as bad as producing (in the movie or photography sense) it, and should be punished accordingly.
This is based upon the following assumptions:
1) possession implies that you are creating a market for the material -- if the market dries up, maybe some children will not need to fall prey to this kind of sickness
2) the material can be "inciteful" of the deed -- meaning if you use child porn to get off, then it might follow that you would actually like to commit these acts -- and if that possession is allowed to distribute, there is the risk that you might "inspire" similar behavior in others
I think anyone who knowingly and willfully possesses or traffics in child porn should be held accountable to the strongest punishment the law allows.
Now, I suppose if someone found child porn on your computer, and you were unaware of it, then this would be a reasonable defense.
By the way, I believe (in the US) we have similar laws regarding possession of stolen property. Regardless of whether or not you actually stole it, if it was stolen and you possess it with the knowledge that it was stolen, you can be punished accordingly.
Of course, IANAL, criminal, or otherwise involved in the legal justice system.
It seems there is a lot of confusion about the requirement for encryption keys and such.
I believe RMS and the FSF want to disallow the creation of environments where if you have e.g. a device (think XBox or wifi router here) based on GPL'd code, you should be able to change the code that is in the box. (I think RMS takes it a step further, as he states that he believes that any kind of device that *doesn't* let you do this uses proprietary software and is hence immoral.)
There are a lot of special devices out there, and sometimes you need encryption and signed code for things other than DRM.
Examples: embedded wifi firmware. Now it stands to reason that if I'm a vendor, I could gain a lot by using Linux or somesuch in this device. But FCC says I have to lock down the radio so end users cannot make it do things not intended by the mfg. Well, if it is a software programmable radio, the best (and maybe only) way to achieve that while allowing for firmware updates is to use signed firmware. Under GPLv3, I cannot make this device.
Security devices. I've worked on a FIPS-140-2 certified device that has a secure key store. It was based on VxWorks, but it could have easily have been done on Linux. But in order to guarantee the integrity of the key material on the device, you have to be certain that the end user CANNOT UPDATE THE CODE UNLESS IT IS SIGNED. These kinds of devices are incredibly useful, and frankly necessary to ensure security in certain eCommerce transactions, etc.
Again, these kinds of solutions have nothing to do with DRM, but are perfectly valid kinds of platforms. GPLv3 code cannot be used here. (And, GPLv2 code is subject to debate, depending, I think, on who is interpreting the boundaries. GPLv3 really clarifies, I think, the position of the FSF.)
RMS and co. want to prevent these kinds of things being developed with GPL code. Furthermore, I think the GPL and some supporting quotes from RMS and co. can be taken to mean that one of the GPL's goals is to actually prevent proprietary code from existing at all. The impact on DRM is just a side effect, but I think it is such a hot button that the community has latched on to it.
Linus seems a bit more reasonable and I think he actually wants companies to develop products on Linux, and devices like the ones I mentioned above might even seem reasonable devices to base on Linux. He just wants to make sure that he gets a copy of the source code changes so that the project can ultimately benefit. This is a totally different position than the "if I can't modify and redistribute the software then it is illegal" position of the FSF.
By the way, I've distributed code under GPL, LGPL, and BSD. Each has their own particular use -- no one license serves all needs. Adding GPLv3 to the mix doesn't change this, but it does add a new choice. (One I personally am not likely to use for any of the code I distribute, but then I like the idea of people being able to use my code in proprietary applications, as long as I get credit and a copy of any improvements.)
Binary compatibility is no more necessary for Solaris than it is for Linux. It has nothing to do with being open-source or proprietary. (I have released open source drivers for Solaris, and I have also worked on closed source drivers. There are good reasons for allowing both.) Binary compatibility is necessary for Sun for one simple reason: commercial viability. Sun's customers and partners insist on having a binary compatible API, and binary (and source!) compatibility from one release to the next are a major selling point for Sun's enterprise customers.
Linux still takes the hobbyist approach, where everyone should be expected to be able to recompile the kernel and device drivers. This is BSD unix legacy circa 1982, where to add a driver you had to recompile the kernel. Now Linux isn't quite that bad, but you still are expected to have to compile the *driver*.
Lets take the case of the company that wants to support this kind of environment:
1) Which version of the Linux kernel (2.2, 2.4, or 2.6? What about patch revs?)
do my customers need?
2) Which userland environment do I support (where are kernel modules installed
for example? It varies from distro to distro, folks!)
3) Which *compiler* version is being used? Gcc 3.3, 3.4, 4.x? Have I tested my
driver for these?
4) What other kernel patches have been applied by the end user? Have they busted
an interface or changed a header in some way?
Obviously directly "supporting" the device on something like Linux is going to be a great challenge.
In order to for there to be any economic incentive for hardware developers to sell to Linux masses, they need to be able to provide full support *and advertise it*.
The random home users who are willing to purchase caveat emptor devices are simply not enough of a market to be commercially interesting for these companies. (A well known WiFi vendor wasn't interesting in dealing with us for WiFi for Solaris in quantities less than a million or so, and Intel won't even sell their wireless parts without a motherboard attached.) The WinTel market is so enormous that the home Linux hobbyist community doesn't represent even a reportable fraction of their market.
That said, there are other real considerations for closed source drivers:
1) a lot of times the knowledge about the intricacies of the device are either not well documented, or documented only in a form that is inseparable from details that are proprietary (e.g. device driver author expected to be able to read device schematics).
2) a lot of devices are so similar (e.g. OEM branded devices, or devices with common ancestry like various tulip variants) or the driver can employ similar techniques that a company doesn't want to do the initial development or documentation work just to enable a competitor to get a mostly free ride
3) sometimes there are real innovations in device drivers -- e.g. when I was at Sun I wrote a Solaris driver for a crypto part that had near linear scalability for adding new crypto parts. This was a unique innovation and allowed us to set a world record for SSL performance. Giving the technology away free would have allowed any other crypto vendor to do the same.
4) there may be legal considerations involved. E.g. drivers with ancestry dating back to some other licensed software, or the already mentioned FCC rules. (And for the record, the FCC smackdown will come to the hardware company, not against the home user.)
5) there may be marketing considerations in hiding the details of a device. E.g. if you have to do some ugly performance impacting workarounds in software, are you going to want to tell folks about this?
6) if you have a suitably complex device, you might not want to enable others to reverse engineer details ab