These things typically start out as a private framework for an iteration of the OS. My guess is that MacRuby will need to hit a nice and stable 1.0 before Apple commits to maintaining it as a built-in public OS X framework. I think it'll happen eventually, though.
There's a big difference between saying "this version of MacRuby is good enough for this particular application", vs. "this version of MacRuby is good enough for all applications".
Once it's added as a public framework to the OS then Apple is committed to maintaining the framework's security, stability, and backward compatibility in perpetuity, or at least for a very long time. OS and platform vendors never make those decisions lightly.
It is an encouraging sign that MacRuby is at a point where Apple is comfortable using it their some of their code.
There is a little difference between using it privately with testing for functions used and releasing to developers in public as a stable, fully tested framework. Apple making it private is pretty much the same as a developer bundling it in an app.
They're under certain obligations of the Ruby license, no? Wikipedia claims MacRuby is "based on Ruby 1.9." Ruby 1.9 is distributed under GPL and the Ruby License, which states:
2. You may modify your copy of the software in any way, provided that
you do at least ONE of the following:
a) place your modifications in the Public Domain or otherwise
make them Freely Available, such as by posting said
modifications to Usenet or an equivalent medium, or by allowing
the author to include your modifications in the software.
b) use the modified software only within your corporation or
organization.
c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided.
d) make other distribution arrangements with the author.
Not sure how this is compatible with "Apple apparently decided to not share MacRuby with other OS X developers" but I do not know much of MacRuby, maybe someone else can weigh in.
This guy isn't complaining about source code or licensing issues.
He's complaining that MacRuby isn't in a shared location, like say libc or some other standard library. He wants to just be able to type 'macruby foo.rb' (or whatever) and have it work an any Apple anywhere, so he doesn't need to distribute his own versions of the library.
Hardly the end of the world. And if apple did include it, then people would just complain that they only had 0.9 instead of 1.1 or whatever.
Anyone who remembers the days of redhat being stuck on a particular python version because all the internal tools used 1.5 might even think it's a good idea to make the system copy private.
If they're using an unmodified copy, then section 3 applies, which means they basically only need to the macruby site somewhere in the docs:
3. You may distribute the software in object code or executable
form, provided that you do at least ONE of the following:
a) distribute the executables and library files of the software,
together with instructions (in the manual page or equivalent)
on where to get the original distribution.
b) accompany the distribution with the machine-readable source of
the software.
c) give non-standard executables non-standard names, with
instructions on where to get the original software distribution.
d) make other distribution arrangements with the author.
The issue is whether MacRuby is part of the public API for OS X. If it were, you could ship a MacRuby app in the Mac App Store without having to include MacRuby itself in your application. But the framework API is currently private, so you can't do that. Of course MacRuby itself is still freely available.
They would be better off shipping MacRuby with their application which is probably why Apple made it private. Now that disk space and bandwidth at this scale is essentially free you are better off testing with the exact bits that will be present at runtime.
What is with people and continually violating the NDA? Especially when they aren't anonymous?
I've seen so many messages from people on Twitter that I follow about what Lion contains, and what it does not. There is a pretty strict NDA in place covering the prerelease software, and there's exactly one forum (well, two, if you count Radar) where you can voice your concerns.
It's a sad state of affairs when people do not care about the contracts that they sign. It'll lead to further secrecy in the future, and it's just disgusting how lax some people are being re: the new OS.
People's laxity towards Apple's NDAs more or less reflects Apple's laxity in deciding whether to declare a piece of software is under NDA. I mean, the iPhone SDK was under one for months after it was released to the public. As one developer put it, "I'm sitting in a public conference session hearing about the iPhone SDK that anyone can view on Apple's website, but I can't talk about what I'm hearing to the guy next to me."
Apple isn't remotely selective in applying NDAs. When anyone can get at the information, there's nothing actually private about it. If there were any kind of secrecy to begin with, people would be more concerned about preserving it.
It's like when folks post to mailing lists with signatures reading "THIS MESSAGE IS CONFIDENTIAL AND ONLY MEANT FOR THE NAMED RECIPIENT." People start to take it less seriously.
> It's like when folks post to mailing lists with signatures reading "THIS MESSAGE IS CONFIDENTIAL AND ONLY MEANT FOR THE NAMED RECIPIENT." People start to take it less seriously.
A perfect analog to the grandparent's point.
What is it with people being lax towards confidentiality notices, especially when they aren't anonymous?
I've seen so many messages from people on mailing lists reading and replying to mail with confidentiality notices. There is pretty strict language covering these confidentiality notices; they often consist of five or more lines of ALL CAPS text that's hard to miss!
It's a sad state of affairs when people do not care about the contracts that they read. It'll lead to further secrecy in the future, and it's just disgusting how lax some people are being re: confidentiality signatures.
> It's a sad state of affairs when people do not care about the contracts that they read.
That's where your analogy fell off the rails. Signing an NDA is a binding agreement, while reading an email footer places one under no obligation whatsoever.
I don't see where Matt Aimonetti is breaking the NDA. He just refers to information someone else posted in public. Considering that someone else had to give him (a core developer of MacRuby) a tip that MacRuby is included in Lion, I would expect that he didn't sign an NDA.
Apple is pretty secretive already. Would it really matter if they got even more secretive? I find myself on the opposite end of the spectrum as you with respect to NDAs. I think it's a sad state of affairs that so many companies today use them to stifle discussion about their up and coming products...or use other legislation or agreements to prevent power users from realizing the full potential of the products they already own (EULAs + DMCA). Are there cases where NDAs make sense? Of course! Is an NDA really an appropriate reason to stifle conversation about an up and coming OS? I personally don't think so. Plus, it's just exciting to talk about new things and leak info and it really doesn't hurt anybody in this case anyway. If anything, it just builds up the fanboy marketing fervor that Apple works off of so well. To say that they are unaware of this effect's existence would be rather strange to me.
As far as being lax about caring for contractual obligations, I think it's a side-effect of living in an overly litigious society where you have to agree to umpteen EULAs a day to get anything done on a computer (and many electronic devices).
For instance, when Apple gives you a copy of Lion it is obligated to give you access to the source of every GPL'ed part of it and you must be free to redistribute it or modified versions. If their NDA prohibits this, they have no right to distribute any GPL'ed code in the first place because they are in violation of the terms of the GPL.
I'm not sure how the GPL covers a particular packaging configuration of a build of something which has GPL'd source. Sure the source can be redistributed, but the binary possibly not. In practice, this is not much of a distinction because you can build the package from the source, but in this case the source probably doesn't have anything in it saying "Apple has built this source code into OSX." What Apple has done is essentially building a binary of MacRuby and installing in a location on the filesystem of a MacOSX Lion install. None of which you could claim that the GPL allows you to by-pass an NDA over.
MacRuby is under the Ruby License. I am not sure it prohibits distributions of binaries without source. If, however, Apple decided to include the latest and greatest version of, say, bash, they would be required to give you redistribution rights along with the source. You could, then, redistribute it (thus giving informations about the next OSX) without violating the NDA.
If Apple forbids you to get the source of their GPL'ed parts and passing this source on to others, they are in violation of the GPL and their own right to distribute it is voided.
Apparently you didn't read what I wrote. Apple cannot prevent you form getting the source code, but the source code does not include information like "the binary will be installed to this location and will be considered a Mac OSX private framework." When something is considered a 'private framework' in OSX it's primarily an install location which does not change the source code as install location is usually a build-time option. Build-time options are not something that is covered by the GPL.
Seems a pity to make developers bloat their app size by including the macruby framework over and over in each one. Users suffer in the end—takes up more disk space.
You're forgetting about the significant overhead imposed by every process having its own copy of the necessary libraries loaded into memory, and having to load those libraries from disk every time an app using those libraries is started. If those apps were all using a version included with the OS, all those pages could be shared between processes and only loaded once.
But maybe people don't care about apps starting fast on their macs anymore, since a lot of them come with SSDs :)
I don't believe you. Apple includes OS standard versions of packages like SQLite and Python, are you of the opinion that developers shouldn't use them?
If they are standard and public and they work, sure. If they're not public and not standard (like MacRuby) then probably not.
I think the GP post was simply referring to the fact that a vast majority of software is 'installed' on the mac. Just drag it to the application folder. And drag it to the trash to uninstall. This almost certainly means you have a bunch of duplicated library files on your computer, but also means each app doesn't have any external dependencies.
As is required to make sure that there is no data loss. Yes, it is a performance loss as well, but it makes it much better with regard to possible crash scenarios.
I always package the full Python interpreter when I release applications because I am guaranteed a specific version and set of libraries. The tradeoff of a few megabytes for stability is a good one regardless of the availability of the framework.
Steve, that's a fair argument but maybe we should let developers decide. If you want to write a simple task bar app, you might not want to embed 30MB worth of extra stuff when your app could just be a few KBs.
In the absence of Apple's cooperation, a standard build of the MacRuby framework could be distributed independently, à la Growl (http://growl.info/). In this way developers could not only drastically reduce the size of their downloads, but also stay as up-to-date as possible. It would certainly seem that the license would permit it:
http://creativecommons.org/licenses/by-nc-nd/3.0/us/
Yes, the App Store rules would prohibit apps with external dependencies such as that one, and at least for self-contained apps distributed through the app store, Apple themselves would be paying for the bandwidth resulting from their own poor decision, so an argument could be made for both ways.
MacRuby allows you to write native Cocoa apps and call C/Objective-C directly without a bridge. Basically, it's an Objective-C replacement using the same runtime but a different language.
Basically, MacRuby is an MRI fork with the object system replaced by the one present in Objective-C (which is pretty similar). Integration is its main strength.
I haven't found much other than cocoa support. Which I can't get too excited about, a simple macruby app that does nothing but open up one window takes nearly 30 seconds to launch on my Core i5 macbook pro...
MacRuby being private doesn't matter if the code is still open-source - just build your own version and ship it. You don't need to use Apple's builtin version.
The flipside of that is actually pretty important too: Apple can rely on their "private" version of Ruby not being randomly updated underneath them because the user wanted to install cool-rails-app-de-jour.
This is pretty important if Apple are planning on using Ruby for important OS tasks.
(and now I'm officially feeling old - who else remembers this exact same argument from over a decade ago? Did the "private" Sun perl binaries catch anyone else out? How many times did I cause myself trouble forgetting to type #!/usr/local/bin/perl instead of #!/usr/bin/perl ?)
The FreeBSD ports install perl under /usr/local anyway, just like almost every other piece of software in the tree. After a while you get used to it, and like the separation of base system from installed software.
You shouldn't be able to update the system's MacRuby (or anything else, for that matter). Doing this is pretty suicidal.
And your old Perl problem is a Python problem for me. Too many Red Hat servers have 2.4 installed where Python is supposed to be. I have to build my own and call it from the /usr/local tree
Since the release of the Mac, Apple has had its share of subservient fans. But it really is sad how Apple has them begging and pleading at this point.
As other commenters have pointed out, somebody somewhere may been under an NDA for this feature of Lion.
So Apple's response could very well be a DMCA takedown of this poor guy's site. Or they may just send the police to his house and seize all his computers like they did the guy from Gizmodo.
IIRC, Apple was never particularly friendly towards free software. They abide by their obligations under the licenses they have to comply with, but not much more.
The only reason they rely and build upon free software is because it saves them some work.
Apple does contribute beyond what is required. They are not required to post their updates to LLVM+clang, but they do. launchd was considered for Ubuntu before they licensed it under Apache (it was under APSL at the time). They didn't have to hire the CUPS dev to work on it. If you go through Apple's OSS listing [1], if it has the APSL license, that's something they released themselves.
> They are not required to post their updates to LLVM+clang, but they do
You open-source the projects you don't consider strategic assets and/or projects that would cost too much or take too long to develop internally. Open-sourcing is a tool - a development model. That's also why NeXT based its OS on Mach and BSD (and licensed Display PostScipt) - because that shortened their time to market and allowed them to build a computer will a full operating system with enough competitive differentiation to survive for some time (and be resurrected later in the form of OSX)
NeXT was very reluctant in sharing their GCC front-end but was eventually forced to comply with the GPL. Apple has no such obligations with LLVM-clang.
MacRuby is a free software project by Apple Inc. Many folks inside and outside of Apple contribute to this great project... -- http://www.macruby.org/contact-us.html
