Tag Archives: Advertising

The Saga of Sun RPC

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/27/sun-rpc.html

I first became aware of the Sun RPC license in mid-2001, but my email
archives from the time indicate the issue predated my involvement with
it; it’d been an issue of consideration since 1994. I later had my
first large email thread “free-for-all” on the issue in
April 2002, which was the first of too many that I’d have before it was
all done. In December 2002,
the Debian
bug was filed
, and then it became a very public debate. Late last
week, it
was finally resolved
. It now ranks as the longest standing Free
Software licensing problem of my career. A cast of dozens deserve credit
for getting it resolved.

Tom “spot” Callaway does
a good job summarizing
the recent occurrences on this issue
(and by recent, I mean since
2005 — it’s been going long enough that five years ago is
“recent”), and its final resolution. So, I won’t cover that
recent history, but I encourage people to read Spot’s summary. Simon
Phipps, who worked on this issue during his time as the Chief Open
Source Officer of
Sun, also
wrote about his work on the issue
. For my part, I’ll try to cover
the “middle” part of the story from 2001-2005.

So, the funny thing about this license is everyone knew it was Sun’s
intention to make it Free Software. The code is so old, it dates back
to a time when the drafting of Free Software licenses weren’t well
understood (old-schoolers will, for example, remember the annoying
advertising clause in early BSD licenses). Thus, by our modern
standards, the Sun RPC license does appear on its face as trivially
non-Free, but in its historical context, the intent was actually clear,
in my opinion.

Nevertheless, by 2002, we knew how to look at licenses objectively and
critically, and it was clear to many people that the license had
problems. Competing legal theories existed, but the concerns of Debian
were enough to get everyone moving toward a solution.

For my part, I checked in regularly during 2002-2004 with Danese Cooper
(who was, effectively, Simon Phipps’ predecessor at Sun), until I was
practically begging her to pay attention to the issue. While I could
frequently get verbal assurances from Danese and other Sun officials
that it was their clear intention that glibc be permitted to include the
code under the LGPL, I could never get something in writing. I had a
hundred other things to worry about, and eventually, I stopped worrying
about it. I remember thinking at the time: well, I’ve notes on all
these calls and discussions I’ve had with Sun people about the license.
Worst case scenario: I’ll have to testify to this when Sun sues some
Free Software project, and there will be a good estoppel
defense.

Meanwhile, around early 2004, my friend and colleague at
FSF, David “Novalis”
Turner
took up the cause in earnest. I think he spent a year or two
as I did: desperately trying to get others to pay attention and solve
the problem. Eventually, he left FSF for other work, and others took up
the cause, including Brett Smith (who took over Novalis’ FSF job), and,
by that time, Spot was also paying attention to this. Both Brett and
Spot worked hard
to get
Simon Phipps attention on it, which finally happened
. But around
then began that long waiting period while Oracle was preparing to buy
Sun. It stopped almost anything anyone wanted to get done with Sun, so
everyone just waited (again). It was around that time that I decided I
was pretty sure I never wanted to hear the phrase: “Sun RPC
license” again in my life.

Meanwhile, Richard Fontana had gone to work for Red Hat, and his
self-proclaimed pathological obsession with Free Software (which can
only be rivaled by my own) led him to
begin discussing
the Sun RPC issue again
. He and Spot were also doing their best
negotiating with Oracle to get it fixed. They took us the last miles of
this marathon, and now the job is done.

I admit that I feel of some shame that, in recent years, I’ve had such
fatigue about this issue — a simple one that should’ve been
solved a decade and a half ago — that, since 2008, I’ve done
nothing but kibitz about the issue when people complained. I also
didn’t believe that a company as disturbing and anti-Free-Software as
Oracle could ever be convinced to change a license to be
more FaiF. Spot and
Fontana proved me wrong, and I’m glad.

Thanks to everyone in this great cast of characters that made this
ultimately beneficial production of licensing theater possible. I’ve
been honored that I shared the stage in the first few acts, and sorry
that I hid backstage for the last few. It was right to keep working on
it until the job was done. As Fontana
said: Estoppel may be
relevant but never enough; software freedom principle[s] should matter
as much as legal risk.

[the] standard for FaiF can’t
simply be ‘good defense to copyright infringement
likely’
. Thanks to everyone; I’m so glad I no longer have
to wait in fear of a subpoena from Oracle in a lawsuit claiming
infringement of their Sun RPC copyrights.

Musings on Software Freedom for Mobile Devices

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom
For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation
remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream
is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries
that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week
are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project
, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device
and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1)
,
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.
Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article
in
the March
2010 issue
of the Canadian online
journal, The Open Source Business Resource
.)

The New Era of Big Company Forks

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux
, and the discussion
that followed on lwn.net
. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it0. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries1
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

0Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

1Updated:
I originally wrote drivers here,
but Greg
pointed out
that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way
, so I just called
them hardware interface libraries.