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.
It would be interesting to know what made them choose that OS. Is it because FreeBSD was better adapted to their needs or because unlike Linux they wouldn't be forced to contribute back to the enormous pile of work that they inherit ? I hope it's the first one and that we'll soon see commits from Sony flowing in.
FreeBSD and Netbsd are often chosen due to the more permissive licensing agreements. They allow the revised platform to be fully commercial and proprietary. Another example would be Juniper's JunOS.
What's interesting is that while Juniper's software is proprietary, they've still contributed patches and funded dedicated upstream development. This is something enabled by not being required to share more than what they're comfortable with sharing.
Sure, but there are lots more companies that have contributed patches and funded dedicated upstream development for the Linux kernel, in part because they knew that their competitors couldn't just take it and release a proprietary product built on top of it without revealing their changes.
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 giving two entirely separate reasons for why it makes sense for you to contribute patches upstream:
* 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.
Right, I am giving to separate reasons. The thing is, the second is a real benefit, but it's hard to convince my boss of it, because he winds up being afraid that we'll be releasing technology that our competitors could use.
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.
I guess that he works on something SaaS, web probably, where you aren't distributing the software, so there you are not obligued to release your modification.
It's not really clear that Linux's market position is thanks to the GPL, or because Linux was able to move ahead in the marketplace while BSDs were encumbered by the AT&T lawsuit at a most critical point in time, or some other facet of history.
Not just Juniper, either. Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license.
> Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license.
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.
Two answers come to mind about that. First, according to wikipedia, the PS4 has been in development since 2008 -- long before FreeBSD 9.0 was released -- so the "enjoy updates to master" argument would have applied during the development cycle even if not after the product is released. Second, even if they're dealing with a mostly static platform, I'm sure there would be some changes -- in hardware, replacing components with newer/cheaper ones, and in software, patching security vulnerabilities -- so there would still be some incentive to make merging easy (although not as much as if they were continuing development, to be sure).
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.
The even greater success of GPL as a license is that it not only makes sense to contribue back, but you have to. This is much more efficient for good contributions flowing from everywhere. The fact that good non-GPL alternatives like BSD exist kind of destroys it though.
At my company we use and contribute back to projects with BSD-like licenses. When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code, and will use an alternative project with a BSD-like license if it looks like the code is getting to be a key part if a system that we may need to enhance.
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.
> When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code
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.
I'd wager that there are a lot of in-house re-implementations of GPL software because the license isn't permissive enough. I think the fact that good non-GPL alternatives exist supports my hypothesis; given the choice between GPL and reinvent the wheel, it's feasible for someone to take the latter path.
Companies using GPLed software also don't have to share more than they're comfortable with sharing, or they would not be doing it. They are just comfortable with a bit more than other companies.
Everyone talks about licensing but nobody talks about technology. DTrace is something you'd want on such a device. We know that Sony is interested in DTrace, they ported to the PSP a few years back.
Speaking of which -- for those of you who haven't ever seen or used DTrace, I stumbled across a fantastic little tutorial yesterday which really opened my eyes as to just how useful DTrace can be for developers:
For Linux, there's actually SystemTap which has some features than DTrace according to [1].
Sadly, I believe it's only on Fedora/RHEL/CentOS currently.
I don't think it has anything to do with the will to contribute something back.
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?
I would care if they were present. But I have no positive evidence that my computer is infected by any of that. I don't need to manually scan through C code to feel safe. Just like I don't have to watch my food being prepared to be sure it isn't being poisoned.
Windows is not closed source. It's proprietary software, but the source code (especially for embedded operating systems and custom hardware projects) is readily available.
Windows is, by any reasonable definition, closed-source. It is possible (in some cases) to gain access to parts of the source code if you're an OEM, partner or large customer - but this is true of almost any software project, and such code is by no means readily-available.
If Windows doesn't count as closed-source software, then nothing does.
It would seem that you're conflating open source with free software. It is not the case that we can call all programs with readily available source code "Free Software", so we need an ability to make a distinction.I don't agree with Richard Stallman on a lot of things, but the necessity for a distinction between Free and Open is one of them. Frequently, people say "Open Source" when they mean "Free Software", and certain corporations say "Open Source" hoping you'll think "Free Software".
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.
> It would seem that you're conflating open source with free software
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"!
Open Source has a fairly well accepted definition that comes from the Open Source Initiative.
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 have seen cases where the source files used to generate critical libraries had gotten lost by the company developing them. They continued to use the object files to link against them.
Actually, for the specific purpose that you're speaking of, I think yes, it does contradict your statements. If you were building a game console, you could probably get nearly immediate access to the Windows source code. They have it such that you can compile Windows with the kernel modules of your choosing, specifically for use in embedded hardware scenarios. And it's actually configurable to run on ARM, not just x86.
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.
Why would any public company make anonymous donations? Isn't it going to become public anyway via public accounting? I'm not familiar with U.S. law in this regard.
Apple doesn't make many public donations as a matter of policy. Steve Jobs was famously against publicly declared donations – he thought it was hypocritical, stole credit from the recipients and diminished the concept of selfless giving.
2. It should steal credit form the recipient. The money is what makes charities work, more than the work in itself.
3. What's so great about selfless giving? If donations can increase by publishing the donor's name, so be it! Is there even a single downside to selfish giving? Money is money, no matter the intent.
1. Usually people like to pretend they're giving money to charities to fix some world problem and not to improve their status. Doing that while donating non-anonymously is hypocritical.
2. Are you saying it doesn't matter who you give your money to, because it's the money that matters and not how it's spent? Surely you see how that is wrong.
3. Selfish giving encourages donating to popular charities, not ones with the highest impact. Thus money is wasted when an inefficient (or downright harmful) charity gets popular, as people donate to signal status instead of trying to improve the world.
I'm guessing at someone else's motives here. These aren't necessarily my feelings...
> 1. I don't see how it would be hypocritical.
If you loved giving, you'd give everything you owned. To stand up and say "I love to give" when you have no intention of giving 100% to charity is hypocritical. You don't love to give, you're just buying attention.
> 2. It should steal credit form the recipient. The money is what makes charities work, more than the work in itself.
Depending on the charity, it's the people who donate their time that are the valuable ones. In any case, giving half a percent of your annual income is hardly backbreaking labor. To the obscenely wealthy, its often just a tax write-off. It's valuable to the charity but less of a sacrifice than others are making. You're getting re-rewarded for your wealth, while others who are poorer are giving more (as a percentage) and receiving less. Hardly a charitable distribution of gratitude.
> 3. What's so great about selfless giving? If donations can increase by publishing the donor's name, so be it! Is there even a single downside to selfish giving? Money is money, no matter the intent.
Jobs was a Buddhist and selfless giving without receiving anything in return is considered a valuable trait to Buddhists (true humility). Otherwise it's not giving, it's more receiving.
He became religious with some Asiatic religion before he came up with his theory on donations. And there was here in HN a post about how his family did donatelots of money.
A public company is not required to disclose its individual donations except insofar as they would be material to making an investment decision. The bar for that is tremendously high for a company like Apple or Sony relative to the size of any such donation.
Not saying it applies in this case, but one reason might be religious belief. Certain parts of the bible discourage
seeking attention for charitable acts.
1 "Take heed that you do not do your charitable deeds before men, to be seen by them. Otherwise you have no reward from your Father in heaven. 2 Therefore, when you do a charitable deed, do not sound a trumpet before you as the hypocrites do in the synagogues and in the streets, that they may have glory from men. Assuredly, I say to you, they have their reward. 3 But when you do a charitable deed, do not let your left hand know what your right hand is doing, 4 that your charitable deed may be in secret; and your Father who sees in secret will Himself reward you openly.
It reminded me that 3 years ago Sony started working with GNUStep to add touch support and build their SNAP platform, they put the project on hold/cancelled it not long after it became public, but you can still see the code at: https://github.com/deliciousrobots/gnustep-gui-sony/
GameOS on the PS3 is Sony proprietary AFAIK. OtherOS was traditionally Linux but glevand the hacker (not glevand the SCE employee) got FreeBSD running as well. The hypervisor (lv1) is a modification of the IBM reference hypervisor.
Keep in mind that the final software for the console can differ from the OS that the development kit is running.
The Playstation 2 development kit was running Red Hat Linux and shipped with a custom system software once it was released.
The Playstation 3 development kit was also running Red Hat Linux, but it shipped with CellOS, an operating system that has supposedly been branched off of FreeBSD during development.
This article doesn't cite a source. I'd be interested to see more information.
(The article also claims that you could install Windows on your PS3, which I never tried but I'm reasonably certain would not in any way actually work).
The devkit will be unlockable — but that's not interesting. What bootloader the devkit runs has no relation to what the final console will (and I expect that will be locked down, even if it allows other OSes).
Isn't the point that it has to be locked down? I get the impression that one of the merits of a gaming system is how well it protects unauthorized copying of game titles (seen from the game developers' point of view).
Actually, the point was to prevent unauthorized self-publishing...
This is what doomed the market in 1983, people made so much shovelware and shipped to actual stores, that when someone arrived on a store and grabbed a random title, it was 99% of chance of it being utter crap, thus people stopped going to stores.
Nintendo that came up with the idea to just outright make hard as possible for people to self-publish games, going to the extent of even limiting large publishers amount of allowed games per year.
Thanks to indie renaissance this is being relaxed now, but not too much... Companies are still scared by the prospect of repeating 1983 or repeating iTunes (that has thousands of shovelware games and discoverability outright suck)
Worst case scenario, someone will rip out the rom chip and reverse engineer whatever kind of efi or acpi firmware they are using and solder their own in.
People get mad crazy with video game consoles like that.
Correct me if I'm wrong, but isn't this just for the dev tools? I think the actual OS will be something different (although I assume some sort of Linux Kernel).
That seems pretty unlikely. The Mac OS X core operating system Darwin is also based off FreeBSD, but there's a whole lot on top of the core OS that they don't have in common, so Mac programs are not very easily ported.
Correct. A SELF file is just an ELF-ish header with crypto abilities that wraps a normal ELF file. Many fields are duplicated... some are checked for validity while a different copy is actually used! ;-)
I'd say chances are pretty slim. They are only using the FreeBSD kernel. It's the stuff on top (graphics libraries, input handling) that really matters.
not strictly the FreeBSD kernel but the rather the BSD emulation layer ( which is quite a significant chunk of xnu ) on top of the Mach "microkernel" ( which until Mach 2.5 still ran in the kernel - Mach 3.0 moved the BSD emulation out to userspace). the "BSD emulation" started with 4.3 BSD and kept in sync with its successors but seems to have diverged quite a bit lately.
PS3 also used a BSD fork (called CellOS or something like this). I would have been impressed if they had they own embedded low footprint OS. Forking BSD and "eating" a lot of RAM for the OS in a game console is hardly interesting.
Seems like its common for Japanese consumer electronics companies to use FreeBSD as a base. For example the Panasonic plasma TVs of recent years contain FreeBSD.
