As someone who works on BSD-licensed opensource software, this is fantastic news. Regardless of your opinion of Sony as a company, this is exactly why I love licenses like BSD & MIT - you enable engineers everywhere to build better products.
I've had the same thoughts recently. At some point it must simply become unmanageable to maintain a fork, at least if you want to enjoy updates to master. But I suspect Sony might not be interested in future updates to FreeBSD, since they will probably prefer working on a static platform, and since the hardware will remain the same as well.
Of course, for all I know, they might be planning a PlayStation 5 based on FreeBSD 11.0 to be launched in 2017, in which case they would have very good reasons to merge as much non-proprietary work upstream.
We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors.
Edit: I forgot my key point, which was that GPL is less useful in "most" cases (IMHO, YMMV, etc), but is successful because of good "marketing" and it being the most talked about license with the most vocal and ardent supporters.
Why? If you are OK with contributing back to the upstream project, why avoid doing so if the license is GPL?
> We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors.
Exactly. With the GPL, even once you do release your changes, you know that your competitors can't create a proprietary fork that builds on your work without benefiting you. It gives you a quid pro quo, while there's always worry when contributing to a BSD licensed project that a competitor may make a proprietary fork and you'll be left either continuing to push changes that benefit them without getting anything back, or making your own proprietary fork and now defeating the whole purpose of sharing changes.
Basically, permissive licenses lose at the prisoner's dilemma; GPL acts as a way to force cooperation, allowing your both to win. Remember, most of the time development is not a zero-sum game. You can gain market share by taking it from a competitor, or by increasing the size of the market. Working together on shared components helps to reduce the cost to increase the size of the market. Coming out with proprietary new features that your competitor doesn't have may increase the size of the market, or it may just steal marketshare from your competitor. And if it steals marketshare from your competitor, they have an incentive to retaliate in kind, developing proprietary features that they don't share and which steals customers from you.
Here's an example. To make the numbers simple, I'm going to assume big enterprise software, that you sell for a lot of money to a few customers. Let's say that you have two companies, Colorful Chapeau and Suzie, selling an open source system called Van Pelt (sufficiently customized, including support, perhaps with certified hardware, etc. to turn it into an actual business). For the sake of argument, to make the numbers simple, let's say it's enterprise software, sold at a high price to small number of customers. Each of them has 100 customers, who each pay $100,000 a year for the software and support, giving them a $10M a year budget (yes, I'm ignoring actual profits and the actual cost of support an whatnot; this is a simplified example).
Now, there are two major new features, A and B, that are the next big things in the industry. There are 50 more customers that would buy the systems if either A or B were added; plus, 25 customers would switch from one company to the other if they were able to add A or B and the other company isn't. Finally, there are an additional 50 new customers who would buy a system which had A and B (on top of the ones who need just A or B).
So, if Colorful Chapeau releases A, and in the kindness of their own heart, decides to push the changes upstream despite Van Pelt being BSD licensed, Suzie can spend all of their development budget on B, and release a product that incorporates A and B. 25 customers defect from Colorful Chapeau to Suzie because Suzie offers B and Chapeau doesn't. No customers defect from Suzie to Chapeau, as Suzie offers both A and B. There are 50 new customers which needed A, but both companies offer it, so they each get 25 new customers due to that. Suzie gets 25 new customers who wanted B. Suzie gets 50 new customers which needed A and B. So Chapeau is left in the same place; with 100 customers, after all of that development effort. Suzie is now up to 225 customers; with some stolen from Chapeau, and some new.
But of course, due to that expected outcome, Chapeau wouldn't do that; their stockholders would revolt. Instead, they would develop A as a proprietary feature. Suzie would develop B as a proprietary feature. Chapeau would get 50 new users, plus 25 defections, and minus 25 in the other direction, and Suzie the same, leaving them at 150 customers each. The last 50, who are holding out for a system that has A and B, are left to wait another year while Suzie and Chapeau spend duplicate effort copying each others features. The two companies are each left with less revenue, and the users lose out as no one offers A and B for another year.
Now, what happens if Van Pelt were released under the GPL instead of the BSD license? Well, releasing a proprietary feature is no longer an option. Colorful Chapeau can develop A, and Suzie can develop B, and they can both offer A and B. They will each split the 50 new customers who need A, 50 new customers who need B, and 50 new customers who need both, and will have no defections. They each now have 175 customers, and all customers can now take advantage of A and B.
Now, of course the real world is more complex than this; there can be multiple actors, benefits will not be so symmetric, full on leeches can sell the same bundled support and services without developing any new features of their own, people can sell bundles of GPLed and proprietary software as long as they don't link, the GPL does allow you to develop in secret and then do a big release to get a jump on your competitors, forks can interfere with actually sharing A and B in the same codebase, etc. But you can see how there is substantial economic value to the GPL. In development, just like the prisoner's dilemma, given a fixed strategy for your competitor, defecting is better than cooperating. But both players cooperating is better than both players defecting. So if you have an independent competitor that you can't trust, and permissively licensed software, you will likely default to defecting (not sharing code).
I suspect the cases in which permissively licensed software does the best are the ones in which the features it offers aren't a significant competitive advantage, but instead the software is more of a cost-center (something you need, but it isn't terribly important what you pick, so you might as well pick the cheapest). There the economic benefits of cooperation become more important, while you don't have as much of the reason to be afraid of sharing your code, as it won't lose you any customers or allow a competitor to gain customers that they otherwise couldn't have.
As a developer who works with a boss who has a somewhat equivocal position on open source software, I'm glad for the GPL requirements on the software that we modify and ship. He likes to use open source software, and in theory likes to pay lip-service to contributing change upstream, but when push comes to shove he's always worried that we'll let competitors get a jump on us. With GPL licensed software, I can always make the argument that we have to release the source code anyhow, so we might as well push the changes upstream and avoid the pain of maintaining a fork. With other software, well, it's always somewhere far down on the priority stack to actually release the code, and so we wind up maintaining patch stacks for years and shipping with major security vulnerabilities because we're afraid to update as it will take a lot of work to port our changes forward.
* You're modifying GPL'd software, which means you're required to release the source code including your modifications.
* Pushing the patches upstream reduces the costs to your business in the long-term, because it avoids the need to maintain separate branches for your own changes.
IMO, the second reason is a much bigger win for businesses, and exactly the reason permissive licenses (BSD, Apache 2.0) are getting more and more popular. Permissive licenses allow businesses to collaborate on code which is going to be common within and across industries (reducing development costs and time-to-market) while allowing them to keep some other parts of their code private.
The first is an unquestionable reason; it's a lot easier to get him to agree if it's a legal requirement. So even though the real reason why it benefits the company is the second, the first provides the leverage to tip the scales in favor of releasing the code. If the code were BSD licensed, we would likely never ship it upstream, because of his fear that our competitors will take advantage of it.
And there's an additional, third factor in play: if you release it under the GPL, you don't have to worry about your competitors making a proprietary fork of it, thus taking advantage of your work while keeping their own secret. So that further tips the scales. Sure, with GPL you may be required to release your modifications, but at least you know that by doing so, you won't be giving your competitors a major advantage if they then build something proprietary on it.
And finally, in many cases with GPLed licenses, you can keep your own code proprietary. Just write a separate application, rather than linking it with the GPLed components. That's how most of what my company does works; we sell a system based on Linux and many other GPLed components, but we tune it to the hardware we sell, and have our own proprietary management tools on top of it that make it integrate well into our market. This is why the LGPL or more permissive licenses are generally preferred for libraries (with very few exceptions, such as readline), which are designed to be reused regardless of the license of the application, while the GPL works so well for components like the kernel, system services, and so on.
A patch for AVX support was submitted from someone at Sony
http://lists.freebsd.org/pipermail/freebsd-amd64/2011-March/...
You need a lawyer to do anything with GPL'd software in commercial setting, and even lawyers will sometimes disagree (e.g., what is a derivative work?). With BSD-licensed software you don't have to worry about lawyers. So which software do you pick?
[1] http://sourceware.org/systemtap/wiki/SystemtapDtraceComparis...
This talk (by one of the dtrace guys) discusses methods of linux performance analysis:
https://www.joyent.com/blog/linux-performance-analysis-and-t...
http://www.freebsdonline.com/content/view/933/531/
I also found a well-written quick-start guide for DTrace:
http://www.tablespace.net/quicksheet/dtrace-quickstart.html
Remember, DTrace also ships as part of OS X (and Solaris) too, so it's worth learning if you're doing any serious development on those platforms.
Because you can't materialize a new closed-source operating system in time for a console lifecycle without basing it upon some open source one.
So you don't have much choice: it's Microsoft or open source, and guess what? Microsoft already have a console of its own.
And I doubt they would actually prevent you from making your own competing console, because A) Windows is a separate division from Xbox, and B) Xbox is a lot more than just a console that runs Windows. Just because they make their own tablet computers doesn't mean they're preventing people from making tablet computers.
If Windows doesn't count as closed-source software, then nothing does.
I would say Java is a good example of Open, Non-Free software. Oracle has made it very clear that anything Free in Java is only a Sun legacy, they would rather it weren't, and they'll chase down any lead they can to stop people from using the Java source in their own projects.
Given that the Windows source code is nowhere near as hard to obtain as you seem to think, I think it is more convenient to consider it as Open, Non-Free as well. You don't really need to be a partner or a large customer, just about anyone can get it with an MSDN subscription. A friend of mine had access to the Windows source for a research project he was doing in undergrad. He discovered a memory leak in the VC++ runtime and was able to patch it. He wasn't doing anything with operating systems specifically and he most certainly did NOT pay anything for this access. Their system for building set-top boxes and the like is completely based on recompiling the source code with your personal configuration of kernel modules you'd like to include.
I would contrast this with Adobe Photoshop as an example of very-Closed, Non-Free software. I'm not aware of anyone outside of Adobe receiving Photoshop's source code post v1.0. I've worked with a few 3rd party libraries, developed by one particular government agency, that I could not get the source code to as an employee of another particular government agency, no matter how hard I tried and how bad of a memory leak it had that they refused to fix.
I know it's cool to bag on Microsoft around here, and I'm not terribly fond of them myself anymore, but I'm not going to let myself be deluded about what one can be capable of on their software. You almost certainly have competitors building software on an MS platform and you should not make the mistake of assuming they're doomed from the start.
If Microsoft could call Windows 'Open Source' I have no doubt they would. Instead, they call it Shared Source (through their Shared Source Initiative, surprisingly enough).
Microsoft themselves don't consider it Open Source. The people that essentially invented the phrase itself don't consider it Open Source. I don't know why anyone else would.
I'm really not. Windows is closed-source in that the source is not readily available - nothing to do with "Free"ness. Agreed that Java is a good example.
> Given that the Windows source code is nowhere near as hard to obtain as you seem to think
Perhaps it's easier than I'm aware. To my knowledge, the access routes are all through the Shared Source programmes, and they have specific eligibility requirements: http://www.microsoft.com/en-us/sharedsource.
So I expect we're just disagreeing about the extent to which code must be "open" to count as "Open" - I'd posit it being available for public access, but I could be convinced if it were available to all customers.
> I would contrast this with Adobe Photoshop as an example of very-Closed, Non-Free software.
Fair enough - there are examples of "more closed" software.
> You almost certainly have competitors building software on an MS platform and you should not make the mistake of assuming they're doomed from the start.
I'm certainly not making the assumption that using closed-source software is always a bad decision. There are obvious benefits to using open source, but it's not always possible, and in many cases doesn't make much difference. But I can't get behind the argument that Windows is "Open Source" in any meaningful sense - even Microsoft describes it as "shared"!