If they can make it work and well integrated, that would be great. The Samba integration on OSX Server is, IMHO, extremely subpar. I had problems with file permissions and ownership getting set correctly. And that's just for fileserving, which samba has had downpat for years, not things like having it be a DC in a AD setup. I know what the options are to have samba do what I want, but there is no place in the lowest-common-denominator-of-file-sharing-service-configuration GUI to set them. And you really want to avoid hand editing the GUI maintained configuration files because they get overwritten.
"Extremely subpar" may be overly charitable from my experience. We had constant problems that have pretty much disappeared since we replaced it with a machine running Windows Server 2008 R2.
My biggest gripe was discovering that for a user foo, you can't just give the user permission to access a file on a network share through the GUI, you must also make sure that foo can access the file at the Unix level. Potentially I guess if they're building from the ground up they can get better integration, though I'm skeptical of their ability to do better than Samba.
"Extremely subpar" may be overly charitable from my experience.
I like to say that anyone who thinks all Apple products are designed well and work as you expect means that person has never used OSX Server.
My biggest gripe was discovering that for a user foo, you can't just give the user permission to access a file on a network share through the GUI, you must also make sure that foo can access the file at the Unix level.
In some sense, this is the way samba works (it uses file system permissions for user share mode, once they've been authenticated, unless you override it with things like the force user, force group, or force mode parameters -- which you can't effectively set on OSX). Unfortunately, since the GUI hides actual samba configuration from you, you never find this out.
To this I say, "good riddance." Samba is a pretty horrible implementation of a pretty horrible protocol. It was originally built by systems administrators, so I'd say that the system is more "accreted" (like a stalactite) rather than really designed. Samba is incredibly hard to extend and maintain and the primary developers are more wankerish and ideologically motivated than commercial vendors would like. Primarily for these reasons, but also for licensing reasons, EMC, NetApp, other storage vendors, Oracle, and now Apple have all switched over to private implementations. I believe Sun's effort started long before protocol documentation was available from Microsoft, but the Samba developers do deserve credit for doing some incredibly painful reverse engineering, even if that reverse engineering is sometimes incomplete.
I had been under the impression that the concept/implementation was fine, until Microsoft started diddling with the system in order to mess them around.
Specifically: wasn't Samba based on a 'clean room' implementation of some Microsoft protocol or something like that? And when it took off Microsoft were in the middle of their 'kill Linux in the enterprise at all costs' jihad and so they kept changing the protocol that the Samba guys were trying to interface/interact with?
In a word, no. Microsoft could not change the protocol because it still had to support the hundreds of millions of Microsoft Windows clients out in the field. With Vista, Microsoft cleaned up the protocol a bit (SMB2), but it was the Samba team's paranoid fantasy that this somehow applied to them. Really, it was a long-overdue revision which helped performance tremendously.
While the Samba team had a huge task, this does not excuse the extremely crappy implementation over the years: corrupt TDBs, lack of change notify, no native ACL support, oplock crashes due to the non-asynchronous, single threaded nature of each smbd, horrible Winbind scalability problems, domain join bugs, no real named pipe abstraction layer, no alternate data stream support, etc. And the code is just horrible to look at.
Cifs is implemented at a lower level in the stack than Samba; the primary upshot of this from my perspective is that you can only export a files in a single file system using cifs. If you have one file system mounted on a path within another, or symlinks that cross file systems, they will appear as empty directories or broken files, respectively. Given that a major reason for using ZFS is the ease with which you can use multiple file systems with different configurations all drawing from the same storage pool, this is a pretty severe drawback.
The flipside is that you get coherent oplock and sharemode locking with NFS and local accesses, reasonable ACL/identity management solution across all protocols, efficient support for file change notifications, etc. For these reasons I consider the in-kernel solution to be far superior feature wise as well as performance wise.
Oplocks are an optimization I'm not in much need of; 100MB/sec transfers do just fine. That sharemode locking is by and large ignored I consider an advantage of Samba, as in my personal environment, I do not care if some program wants to exclude readers or writers, I prefer to make those choices. I don't have any applications that treat files on a file share as a multi-user database like the era of Paradox etc.; those days are long gone.
I think ACLs are a bug, not a feature. They are too complex to administer both correctly and efficiently; a capability-oriented approach would be better, but that's fantasy, alas. Again, POSIX permission bits do just fine for my use cases.
From my point of view it's the single biggest drawback of OpenSolaris (and descendants) as storage servers, but I see no fundamental reason why it couldn't be fixed; it simply wasn't high enough up Sun's list of priorities.
> "[Samba] is a portable, user space application, and is actively supported on Solaris. [on the other hand] The Solaris CIFS service is a native kernel implementation; a first-class citizen of the Solaris operating system"
I used it within OpenSolaris and the real pain is that you have to set up entirely new NFS ACL's that relate to the user writing otherwise files won't be readable from within Solaris as that user, or if it is a shared directory they aren't readable by the outside world and the files are written to disk but no longer visible from the outside world over the network.
Yes. In general any time you want to access the same file system by multiple different methods, the permissions issue gets rather hairy, but from the point of view of an Apple CIFS server, some well considered finesse in the GUI could be a big help in managing that complexity. In the case of OpenSolaris, it's at least worth mentioning that so long as you do only want to treat a file system as being a share for CIFS clients, it does work just beautifully.
Apple's filesystems already support native NTFS ACLs, so I expect that the permissions issues will be no worse than current NTFS/POSIX interop, which is indeed hairy. The best you can do is support the POSIX case very well and the all-ACL case very well.
i have lately been writing a simple "samba" client for iOS (https://github.com/38leinaD/tango) and after that experience i must say to the developer doing the samba replacement at apple: poor bastard; you are in for a world of pain!
It is really a horrible protocol where you can see how it evolved and was extended from windows version to version...
Setting up a working file server with basic authentication is almost enough to confirm this. There might be valid reasons for all of the configuration options, but the avarage user will never need more than 10% of them.
The GPL has done a lot of good, but I think it is rather hobbled by being tied so intimately to the concept of 'linking', which has a very clear technical meaning when talking about C/C++, but becomes a lot fuzzier when applied to other languages.
This was fine back when all software was written in C/C++... except that was of course never the case.
Nothing prevents redistribution, v3 seems to be equal to v2 in all the code sharing requirements. The two big-ticket additions seem to be the prevention of "tivoization" by having to distribute the keys to sign software to run on the device you distribute with GPLv3 software in it, and the requirement that if you grant some users a license to one of your patents you're granting that to every user of the GPLv3 software you distribute.
One reason Apple would care is it is now shipping a bunch of locked down hardware (the iDevices). Although those probably don't run Samba right now they may have set up a general policy to not have that risk.
A bigger problem may be licenses to other people's patents. Suppose Apple distributes Samba, and suppose someone NOT Apple owns a patent that Samba infringers. That party sues Apple, and it becomes clear to Apple that they are going to lose. Let's also assume Apple's Samba has some changes, so it is not 100% identical to the upstream.
It looks like GPLv3 only gives Apple the option of stopping distributing Samba, or of finding a way to get a patent license that covers everyone who obtains a copy of Samba that can be traced back to Apple. The latter could get very expensive.
I don't see how anybody could read the GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html) and not come away confused. It's awkward as hell. And then there's this part:
> I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?
> You cannot incorporate GPL-covered software in a proprietary system.
...followed by a series of ifs-and-buts that include completely vague terms like "at arms length".
MacOS X is a proprietary system. It includes support for Windows file sharing. Assuming that Samba was used for this, does this mean that MacOS was not incorporating Samba? Or does it mean that Apple was in violation? Or does it mean that somehow Apple was meeting one of the vague requirements for separation between Samba and MacOS?
(I'm not raising this as a question of differences between GPL v2 and GPL v3.)
Given the case histories involving the GPL so far, I could see Apple's legal team advising Apple to put as much distance between them and the GPL as possible. Non-compliance due to one gray area or another could force Apple to release tons of proprietary source code.
I think that shrugging this situation off with "well, that's their decision" is completely disingenuous. Yes, it's their decision to make, but they will most certainly decide in a particular way as a direct result of the situation they're looking at.
<i>Non-compliance due to one gray area or another could force Apple to release tons of proprietary source code.</i>
No, it cannot. Anyone who repeats this FUD is revealing he has no understanding of the issues. The GPL may not be exceedingly clear, but this is entirely an issue of copyright law. Maybe they will be forced to stop distributing something until they replace a component, and maybe they could be forced to pay damages, but there is no mechanism that the GPL could force them to release anything they didn't want to.
> Cisco settled the case six months later agreeing ... to make source code of FSF programs freely available on its website.
Granted, that last one doesn't sound all that bad.
Given that the GPL does compel the release of source code for derivative works, and given that one of the FSF's tactics in lawsuit settlements is to ask for the release of source code, let's not go misapplying the FUD label, OK?
edit: I don't mean that to sound snarky. Rather, I'd like to see less "Bah, that's just FUD", and more explanation and clarity when responding to people's concerns about the GPL.
Those companies settled because they wanted to continue distributing their products as is. Hence, they released source in order to be allowed to do that.
They could have instead replaced the GPL code with non-GPL code, possibly paid some damages, and been done with the matter with their source remaining secret.
Settlements are agreements. No-one was forced to release source code, which is the language you used. It was their choice - they could have held out if they had wanted to.
You can't force a GPL violator to release source. All you can do is offer them a deal where they release the source in exchange for less/no monetary damages.
IANAL, and I don't claim to have any specific knowledge of the GPL v3 vs. v2--however, my guess is that Apple employs at least a decent legal team who has concluded that the changes in GPLv3 may include language that could force them to open source more of OS X than they're comfortable with.
Or, it may be completely unrelated to GPLv3 and Apple simply no longer wishes to "walk a fine line" in this particular area.
The part about cryptographic keys. It makes it so code signing on the iOS version of the MacOSX kernel would have to have public keys (the anti-tivoization provisions of GPLv3).
Well they can't link it against anything proprietary. Presumably they want to link into Finder in some way or into some of their other filesystem APIs.
...and they have mostly left it in this case. Fine; but lets not pretend open-source GPL projects are significant to the world at large; they are backroom projects with no future.
Upvoted, as I agree with you philosophically, that the GPL is not exactly a corporate developer's best friend.
However, neither Solaris nor Apple are typical corporations in terms of using licensed 3rd party code; given the terms the GPL poses, wouldn't you expect to see more smaller companies, or companies that operate primarily on the web to adopt GPL'd projects?
What are the chances that the new service is actually samba-tng (http://wiki.samba-tng.org/doku.php/start) ? That would be at least interesting. Otherwise - good luck to them replicating what samba project learned over the last 20 years. A new implementation has slim chances of being compatible with systems in the wild.
It is free to be used commercially, if you write it, pay for it, or keep its derived works open source. The only thing GPLv3 keeps you from doing is closed-source commercialization against the wishes of the author.
This seems eminently reasonable to me. If you want to allow people to do closed-source commercial projects with your code, BSD license it.
It feels kind of like a semantic game to call free software "commercial." Do you really believe that, in general, consumer software that you essentially have to surrender the copyright to is commercially viable? Are many people actually going to pay for something that's available for free with literally no added benefit?
(I am, of course, ignoring support here, because support is really a separate product that could even be provided by a third party.)
GPL does nothing to prevent you from selling software. Look what Sleepycat did. Just GPL your code, and put an enterprise-grade price tag on a non-GPL commercial license.
The only people affected by the GPL are people who want to sell software they didn't write. It's hard for me to get worked up about that: the overwhelming majority of all commercial software is more restrictive.
I don't think it's fair to call a program that links against a library for some subset of its functionality "selling software they didn't write." I believe Firefox uses zlib and libpng, but I don't think most people would call Firefox a version of zlib or libpng.
Anyway, I'm not saying that people shouldn't be able to license their software under the GPL. If you don't want me using your code, that's your right. But if they do GPL it, from my POV as a potential user of the code, it might as well be closed-source. Thus I object to the statement "It is free to be used commercially," when it is actually free for any other use but impractical for commercial use. (Even in your Sleepycat example, it was the non-GPL version that they used in their commercial pursuits.)
Help me understand what you're saying. If I write a library, you are free not to use it. My code, my terms, right? That's how commercial licensing works. How does GPL harm that dynamic? Or, should the party with more source code lines dictate terms to the party with fewer?
I think I must be saying this very clumsily. I'll try to sum it up explicitly.
I'm OK with the existence of GPL software. I like it when people use a more permissive license, but your code is yours to do with what you will. What bothers me is what people say about the GPL, because I think it's misleading.
There is this common idea in the free software community that it is not hostile to commercial software. That's what I don't like. If people came out and said, "Yeah, my GPL source code has very severe restrictions that make it unsuitable for integration in commercial software," I would agree and wish them happy coding. But they don't say that. They use the misleading banner of "free," and even try to deny that it's incompatible with commercial software.
Based on all the evidence I've seen, I believe commercial software pretty much has to be offered under a proprietary license in 99% of cases. The GPL says I can't do that if I use so much as one line of GPL code written by somebody else. That means that using GPL code in my software renders it unsaleable.
So, when you said, "It is free to be used commercially … if you keep its derived works open source," I objected to that. If you can only release your software under the GPL, you're probably not going to make a lot of money selling it — it strains the definition of "commercial." You can't even use the Sleepycat model, where there's a GPL version and a commercial one.
It's your right to put your software under that license. But I think it's important for people to understand that it completely shuts out commercial use, even if the commercial use is largely original. We shouldn't downplay that.
The GPL is clearly designed to be hostile to a certain type of software deployment strategy.
But not because that software is being sold, or because it is profitable, or corporate, or big-business, or commercial or any of those things. It is hostile because it is "proprietary" and that (in the FSF's opinion) tilts the power balance too far towards the vendor, allowing all sorts of abuses.
Where I think you are getting confused is that some of those abuses are highly profitable and so those are the most visible successes to you.
But people like to sum this complicated area up as the GPL being "anti-business" or not "business-friendly", which is highly misleading. You'll note that quite a lot of non-software businesses are quite happy to use GPL code since a) they are not in the business of selling proprietary code and b) proprietary code gives too much power to the vendor. There's plenty of room for businesses to supply GPL software to these companies.
I think that you are misrepresenting what I've said. Businesses using GPL software are irrelevant to what I was talking about. My comments have been about selling software for a living, and only about that. (Just to clarify, I am also not talking about providing support for software or making customizations to software. Those are separate kinds of businesses from software products.)
On that topic: Whether or not the GPL was designed to be hostile to commercial software, it is hostile to commercial software in the real world. I don't know of a single piece of GPL software that makes decent revenue on its own.
I think the core of it is your very narrow definition of "commercial" to mean selling shrinkwrapped, off-the-shelf software to large numbers of anonymous clients. I have no real problem with small, or one man development shops trying to do that just like I have no problem with musicians trying to make a living from their home studio. I just think reality, and making a living, might dictate that they go out and build relationships with customers rather than cling to a business model that only made sense for a shockingly short period of time. I can see why they might dislike the GPL or P2P software and the many changes they bring but if their only argument is "but I'd prefer to make lots of money, and not change the way I work, why do I have to choose?" then I'm not sure I've got the sympathy to spare, particularly if the changes mean more, better, and cheaper stuff for me and everyone else.
It's unfortunate if you happen to be the mythical lone inventor that all the laws that patent trolls thrive on was supposed to benefit. They were the collateral damage caused by something that was supposed to benefit society through you, and as patent laws get reformed you'll be the collateral damage caused by something intended to benefit society by curtailing them.
The other elephant in the room is web apps, which the GPL has no power over. There are plenty of people selling that software for a living while building on GPL code. If you're trying to sell desktop apps then you're now more and more competing with them. Again, the GPL has changed the environment you compete in whether you wanted it to or not, and this time it's worse competition because it's more profitable.
For me, this question is mainly practical. If indie developers could put out GPL software and make good money from it without requiring the support infrastructure of a megacorp, I would think that was the bee's knees and I would promote that business model like crazy. I just don't think it's generally possible. I'm not familiar with SourceFire's story, but a look at their site seems to suggest the "Enterprise tech support company" model. I'll have to look closer.
How could it possibly benefit indie developers to give up more of their rights? The rights held back by the GPL --- for the developer --- are almost exactly those those required by companies to commercialize software. I'm vociferous about the GPL entirely because it enables developers to profit from their labor. The GPL is anathema to megacorps. That's why you dual-license, and charge out the wazoo for the corp-friendly license.
You really, really, really need re-evaluate your take on this. GPL is the most indie-friendly of the licenses. There's a valid gripe against it: it fractures the open source community into "people who can use GPL code" and "people who can't use GPL code". But that has nothing to do with commercialization. Once you BSD license something, it is extraordinarily difficult to commercialize the code itself.
Way back when, I wanted to hack sleepycat db support into a closed source third party platform that had an extension API. It would have taken a bit of code, and a dll load.
Not my application, I didn't have source for it, and I was willing to release my extension as GPL. Sleepycat didn't
see it my way and wanted something like 10k/year and a maintenance agreement for the right to do the code and release it a GPL.
So, to sum up, the GPL prevented me from writing and releasing GPLd code.
I disagree. Some people want to sell to consumers, not corporations. Corporations will buy non-GPL licenses so they can redistribute on their own terms, but consumers won't because they don't intend to redistribute in the first place. It's hard to sell GPL software to consumers because as soon as someone sees it's going well, they'll rush in to sell cheaper versions of the same product, and soon it will devolve into something that's not really worth the time. I would love to see a GPL-like license that kept the code accessible and modifiable, but restricted distribution to a subset of persons approved by the copyright owner (i.e., licensed). This would actually make it viable to sell OSS to consumers. While the real GPL may be better and freer, I think that such a license would be a net benefit as it could result in much wider availability of code for programs that people run, which would be a win even if the distribution conditions were more stringent.
Yes, but I can do that if I'm using your BSD-licensed contributions. That's why we're saying that, from the perspective of a commercial software vendor, BSD ensures more freedom.
GPL is significantly more free than closed-source commercial.
Two groups of people are negatively impacted by the GPL.
First, people who want to ship closed-source versions of code they didn't write in exchange for money, against the will of the package author. Hard to feel sorry for these people.
Second, people with BSD/MIT/Apache licensed open source project who want to make it possible for other people to ship closed-source versions of their code for money. A valid concern, but a pragmatic one, not an ideological one. BSD gives away "too much"; GPL holds back "too much". There's no happy medium.
Let's take the ideological cast off this ("freedom", "commercial", "semantic games"). The issue here is simple and practical.
I'm not asking you to clean my gutters for free. I'm asking you to stop saying you'll clean my gutters for free, but sticking in the fine print "$5000 fee required for access to free gutter service."
To drop the metaphor: I'm not saying that you can't license your code under GPL. If you don't want me using your software, that's your right. By placing the code under GPL, you are communicating that I am not free to use the software as I please. That is, again, your right — all I ask is that you be honest about the fact that use of the code is very much restricted.
If anybody using your code is effectively barred from commercial endeavors, then for people who make money off their software, it does not grant them any more freedom than closed-source code does. To say a license grants freedom because you're free not to use the code is just weird.
Are you looking for someone to say "never use the BSD license" so you can argue with them? Because nobody's saying that. GPL is an option when you care if people commercialize your work. BSD is an option when you don't.
That's really oversimplifying. For example, if I write a full Photoshop clone that links to a third-party library to support some obscure graphics format, you'd have to be out of your mind to say the whole program is a derivative of that library — but that's how the GPL sees it. In GPL World, all of our programs are forks of libc.
This problem is so significant that no major Linux distro puts its system libraries under the GPL. It is clear that they believe the GPL would interfere with more than just the freeloading business model.
It's like free speech in a sense. You can focus on the freedoms of the user, or you can focus on the freedoms of the developer, and the two aren't 100% congruent.
I agree with you, for what it's worth. I much prefer the BSDL exactly for reasons like this.
> how can software be truly free (as in freedom) if it's not free to be used commercially?
Ignoring that Free Software is in fact used commercially everyday, it is important to realize that certain freedoms must be restricted in order to preserve overall freedom. Like how your freedom to locate your fist is constrained by the location of my chin. Or how your freedom to stuff a ballot box is constrained by the preservation of a just, fair, democratic election.
While I agree about the problems with the GPL, freedom is such an overloaded term with different meanings having different levels of importance that it is effectively meaningless.
> Presumably, Apple will replace Samba with something that works well for the vast majority of cases.
I doubt it although I wish this becomes true, the protocol is a pain in the ass, even Samba has some quirks, Samba is a very large software (probably millions of lines of code) just to compare.
I just cannot see Apple spending so much time developing this solution only because of their dislike of the GPLv3, sounds dumb to me.
The only thing that came to mind here is that they'll license the protocol/implementation from MS itself. I'm not sure they'd be open to that, but who knows...
The GPL has always included restrictions on how you can use the code and forces you to license the whole as GPL if you derive your own product from a GPL original. GPLv3 advances that into ensuring those freedoms in other cases (patents and locked down hardware).
It's not that you can't commercialize GPL software, it's that while doing so you need to still ensure a set of freedoms for the user. That's the essential part of freedom as defined by the FSF. See the 4 freedoms (http://www.gnu.org/philosophy/free-sw.html).
It took a long time for companies to accept the GPLv2 restrictions when developing products and now some are balking at GPLv3. Google even has a no-GPL policy for anything on the Android userspace.
You can of course disagree with this way of working and prefer something like BSD/MIT licensing instead. I wonder if anyone has done a comparison of how much contribution from commercial entities BSD and GPL projects have generated.
It might be more accurate to call it "freed" software. The goal of the GPL is to uncage domesticated software and let it roam wild forever, never collared again. The people who distribute software in this fashion won't let you put it back in the zoo.
And again, FSF is not saying that users are free to do what they want. You are not free, according to them. They say that software is free, in the sense of the software freedoms. That sentence essentially would only parse to $0 before Stallman came along.
> The obvious question is: why would anyone want to? Presumably, Apple will replace Samba with something that works well for the vast majority of cases.
Using OS X Server as a PDC for Windows 7 machines is the big ticket reason.
