pbsdp

If users don't want to run binaries for which source isn't available, they are under no obligation to do so, and can simg choose to use binaries for which source is provided; no so-called ethical "right" to source code access is violated, as the source once released remains open source.

You don't need the GPL for that; just provide the source code for your software. If users actually care about having the code, they can use your binary for which code exists.

If they don't care, they can use proprietary software, or proprietary extensions that make your software better.

Either way, the user has full control over their choice of software, and nobody's actions can make your original open source code disappear.

The GPL is really about enforcing your ideals onto other people's code if it happens to be reliant on yours. That's a legit quid pro quo for a license, but it has jackall to do with freedom or user rights.

Users already have that right with liberally licensed open source code. If they don't want to use proprietary extensions for which they can't acquire the source, that's fine; nobody is forcing them to.

How can you violate rights of end users? Your open source code hasn't disappeared. End users can still use it, copy it; and share it.

If end users don't want to use proprietary extensions to open source code, they don't have to. The original code doesn't just disappear.

The license grants rights and imposes limitations. One of those limitations prevents users from mixing code freely.

Users already had the right to not use proprietary products; what the GPL has actually done is to take away their right to use your code with a proprietary product.

As such, you've granted users fewer rights as compared to liberal open source licenses, not more.

Those rights are already secured in pepetuity. Your code, once released as opensource, is always opensource.

If users don't want to use code that contains proprietary modifications to your code, nobody is forcing them to -- your opensource code hasn't disappeared.

If those users don't want to use code that isn't released liberally, they don't have to. So what are you actually securing for them? It's not freedom, they already have the freedom to not use proprietary software.

I'm not really sure what you could possibly expect after MS spent most of the natural lifetime of this industries senior developers' behaving badly.

The GPL does offer a deal, but its dishonest to call it 'freedom'.

Users of proprietary software have the choice and can decline, too. Since users dont need it to protect their freedom, why is the GPL necessary if not to restrict freedom?

I'm a user, and I want to use your library in my product. The GPL limits my freedom.

> According to many, including the FSF, GNU, Stallman and myself, increasing access to the source code for everyone is increasing freedom.

Once released freely, the source code never stops being free, so I don't really know what they're talking about in terms of "freedom". MIT licensed code is almost infinitely free, it will never stop being free, and nobody can take it away from you.

It seems to me that they're interested in forcing other people's source code to be free.

The peon actively chose to work there and participate in Microsoft's attempts to dismantle any competition in any field they enter through highly questionable tactics.

VirtualBox, IDA Pro, Google Earth (in fact, everything from Google that uses Qt), EAGLE (PCB software), OpenSCAD, QGIS ...

I've literally never been fooled by a Qt app -- a Mac user can spot that hot mess from a mile away. It's not just a matter of visual layout and UX, although that matters and always falls somewhere between subtly or completely wrong.

The controls also tend to lag at weird times, behave slightly strangely, demonstrate unusual font metrics, etc. The apps tend to exhibit bugs related to menu bar event handling, window management, on and on, and crash more than any other apps I use daily.

This isn't a huge surprise given that Cocoa is designed to be the first and only gatekeeper between events, the OS, UI controls, and Cocoa's main event loop, and most of what makes Mac apps a Mac app has to do with the APIs and integration that you lose first-class access to once you deploy Qt -- that includes 'simple' things like UI layout metrics, which Qt has to re-implement.

I abandoned almost all those Qt apps on my list above. I even dropped EAGLE, despite being "native", in favor of Altera on Windows, which I paid a hefty premium for in no small part because it wasn't a pile of broken UX, Windows or not.

I still use IDA Pro, but the minute http://www.hopperapp.com/ can replace my IDA Pro usage, I'll switch in a heartbeat.

I have. It used to use X11, I saw even more complaints then.

There aren't any competitors, however, so people use Mathematica.

I use high-end expensive that are Qt-only too, but I would gladly switch if there were other options, because Qt is buggy, uses non-intuitive non-standard UI, exhibits poor performance due to impedance mismatches between the Mac and Qt event/threading models, and ultimately decreases overall utility of the UX.

Nobody on OS X wants a Qt app. If you have any solid competition in the market from a company willing to produce a native app, you'll lose to them.

No wonder you're having issues on OS X.

> All with the same binary installers.

So you integrate with the user's desktop environment, using standard local widgets, theming, integration with UX guidelines, local library dependencies, etc?

Or are you shipping a Qt app with your own dependencies included? If so, Qt is pretty notoriously buggy on OS X (and rightfully disliked by most users as it stands outside all platform conventions), perhaps explaining some of your complaints.

The kernel. Everything else from libc on up was rewritten, and under Google's control. The Play store is hardly in AOSP, much less their new IntelliJ-based development stack.

Your management hasn't really changed. I grew up with MS in the 80s and 90s -- I'm not quick to forgive a monopoly that set the whole industry back by 10 years.

Earnestly and dedicatedly inducing people to break their contractual obligations, fall afoul of local hotel regulations, and make life suck a little more for their neighbors.

They're not nice people.

Can you imagine writing desktop software for Linux? Inconsistent APIs, API breakage, ABI breakage, sizable variances between distributions, multiple desktops UI implementations, and you may as well just forget about mobile.

I'm not justifying Apple's ever increasing shift towards enacting strict constraints on their platform developers, but the comparison with Linux is pointless.

I will also note that I'm not a 'webdev', but I am a destkop and server-side software developer. I came to OS X by way of IRIX/Solaris Desktops -> Linux/FreeBSD Desktops -> Mac OS X 10.0.

My preference isn't borne of ignorance, although I think Linux's failings have a lot to do with ignorance from Linux/GNU developers about how the professional development world produces a coherent platform.

I would be convinced if Canonical:

- Dropped the entire Linux desktop software stack.

- Wrote a well-integrated top-down designed set of frameworks that provided a consistent API for desktop software, with binary-level ABI compatibility across major releases of the operating system.

- Promoted and encouraged the distribution of standalone applications that included all their dependencies, including distribution via an app store.

- Dropped the use of package management for anything other than OS components, especially for managing application dependencies.

- Leveraged their well-designed set of frameworks to advance the state of the art and simplify the lives of developers, making it easier to ship "great software" for their platform as compared to others.

As it is right now, Linux is a cess pool of poorly maintained, unstable, poorly designed, rapidly shifting crap. There's almost no centralized vision, and what centralized vision does exist is almost entirely co-opted and captured by massive ubernerds that don't seem to understand the first thing about producing a viable platform that end-user application developers would want to target.

What Canonical has done is put lipstick on a pig; it's not enough to throw money at making the operating system acceptably attractive to just end users.

> And what's the point of comparing the performance of an Apple only, commercial program, to a free and open source multi-platform program.

If I have a Mac and need to virtualize things, 'free and open source' doesn't really matter.

> iCloud+Core Data on the other hand allows custom conflict resolution on the clients.

The new APIs in iOS 7 do, but then you lose all the value of "transparent distributed store" and it winds up being a pretty sizable hassle.

First of all, why would I want to run X applications?

That said, let's say I do -- so I download and double-click the MacPorts installer, and then run 'port install' to install an X11 app from a binary package.

Not that I'd want to.

It's not possible to seamlessly/transparently/asynchronously synchronize data; conflict resolution must be done.

If this was possible, iCloud+CoreData would have worked, and Oracle/PostgreSQL/etc would be shipping transparent, ACID, horizontally scalable RDMS.

That's actually how I feel about Linux; it's a social monoculture and nobody seems to care a whit about anyone that isn't an ubernerd that wants to fiddle endlessly with a poorly designed/integrated OS.

The Mac doesn't need package management, I don't know why you're insistent on it. The App Store isn't package management, it's just one way to download sandboxed apps.

This is the ridiculous opposite of "just works".