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.

systemd Status Update

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/systemd-update.html

It has been a while since my original
announcement of systemd. Here’s a little status update, on what
happened since then. For simplicity’s sake I’ll just list here what we
worked on in a bulleted list, with no particular order and without
trying to cover this comprehensively:

  • systemd has been accepted as Feature for Fedora 14, and as it
    looks right now everything worked out nicely and we’ll ship F14 with
    systemd as init system.
  • We added a number of additional unit types: .timer for
    cron-style timer-based activation of services, .swap exposes
    swap files and partitions the same way we handle mount points, and
    .path can be used to activate units dependending on the
    existance/creation of files or fill status of spool directories.
  • We hooked systemd up to SELinux: systemd is now capabale of
    properly labelling directories, sockets and FIFOs it creates according
    to the SELinux policy for the services we maintain.
  • We hooked systemd up to the Linux auditing subsystem: as first
    init system at all systemd now generates auditing records for all
    services it starts/stops, including their failure status.
  • We hooked systemd up to TCP wrappers, for all socket connections
    it accepts.
  • We hooked systemd up to PAM, so that optionally, when systemd runs
    a service as a different user it initializes the usual PAM session
    setup and teardown hooks.
  • We hooked systemd up to D-Bus, so that D-Bus passes activation
    requests to systemd and systemd becomes the central point for all
    kinds of activation, thus greatly extending the control of the
    execution environment of bus activated services, and making them
    accessible through the same utilities as SysV services. Also, this
    enables us to do race-free parallelized start-up for D-Bus services
    and their clients, thus speeding up things even further.
  • systemd is now able to handle various Debian and OpenSUSE-specific
    extensions to the classic SysV init script formats natively, on top of
    the Fedora extensions we already parse.
  • The D-Bus coverage of the systemd interface is now complete,
    allowing both introspection of runtime data and of parsed
    configuration data. It’s fun now to introspect systemd with gdbus
    or d-feet.
  • We added a systemd
    PAM module    , which assigns the processes of each user session to
    its own cgroup in the systemd cgroup tree. This also enables reliable
    killing of all processes associated with a session when the user logs
    out. This also manages a secure per-user /var/run-style directory
    which is supposed to be used for sockets and similar files that shall
    be cleaned up when the user logs out.
  • There’s a new tool systemd-cgls,
    which plots a pretty process tree based on the systemd cgroup
    hierarchy. It’s really pretty. Try it!
  • We now have our own cgroup hierarchy beneath
    /cgroup/systemd (though is will move to /sys/fs/
    before the F14 release).
  • We have pretty code that automatically spawns a getty on a serial
    port when the kernel console is redirected to a serial TTY.
  • systemctl got beefed up substantially (it can even draw
    dependency graphs now, via dot!), and the SysV compatiblity
    tools were extended to more completely and correctly support what was
    historically provided by SysV. For example, we’ll now warn the user
    when systemd service files have changed but systemd was not asked to
    reload its configuration. Also, you can now use systemd’s native
    client tools to reboot or shut-down an Upstart or sysvinit system, to
    facilitate upgrades.
  • We provide a reference
    implementation     for the socket activation and other APIs for nicer
    interaction with systemd.
  • We have a pretty complete set of documentation
    now, some
    of it     even extending to areas not directly related to systemd
    itself.
  • Quite a number of upstream packages now ship with systemd service
    files out-of-the-box now, that work across all distributions that have
    adopted systemd. It is our intention to unify the boot and service
    management between distributions with systemd, and this shows fruits
    already. Furthermore a number of upstream packages now ship our
    patches for socket-based activation.
  • Even more options that control the process execution environment
    or the sockets we create are now supported.
  • Earlier today I began my series of blog stories on systemd
    for administrators    .
  • We reimplemented almost all boot-up and shutdown scripts of the
    standard Fedora install in much smaller, simpler and faster C
    utilities, or in systemd itself. Most of this will not be enabled in
    F14 however, even though it is shipped with systemd upstream. With
    this enabled the entire Linux system gains a completely new feeling as
    the number of shells we spawn approaches zero, and the PID of the
    first user terminal is way < 500 now, and the early boot-up is
    fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE
    and Debian and distilled from this a list of functionality that makes
    up the early boot process and reimplemented this in C, if possible
    following the bahaviour of one of the existing implementations from
    these three distributions. This turned out to be much less effort than
    anticipated, and we are actually quite excited about this. Look
    forward to the fruits of this work in F15, when we might be able to
    present you a shell-less boot at least for standard desktop/laptop
    systems.
  • We spent some time reinvestigating the current syslog logic, and
    came up with an elegant and simple scheme to provide /dev/log
    compatible logging right from the time systemd is first initialized
    right until the time the kernel halts the machine. Through the wonders
    of socket based activation we first connect the /dev/log
    socket with a minimal bridge to the kernel log buffer (kmsg)
    and then, as soon as the real syslog is started up as part of the
    later bootup phase, we dynamically replace this minimal bridge by the
    real syslog daemon — without losing a single log message. Since one
    of the first things the real syslog daemon does is flushing the kernel
    log buffer into log files, all logged messages will sooner or later be
    stored on disk, regardless whether they have been generated during
    early boot, late boot or system runtime. On top of that if the syslog
    daemon terminates or is shut down during runtime, the bridge becomes
    active again and log output is written to kmsg again. The same applies
    when the system goes down. This provides a simple an robust way how we
    can ensure that no logs will ever be lost again, and logging is
    available from the beginning of boot-up to the end of
    shut-down. Plymouth will most likely adopt a similar scheme for initrd
    logging, thus ensuring that everything ever logged on the system will
    properly end up in the log files, whether it comes from the kernel,
    from the initrd, from early-boot, from runtime or shutdown. And if
    syslogd is not around, dmesg will provide you with access to
    the log messages. While this bridge is part of systemd upstream, we’ll
    most likely enable this bridge in Fedora only starting with F15. Also
    note that embedded systems that have no interest in shipping a full
    syslogd solution can simply use this syslog bridge during the entire
    runtime, and thus making the kernel log buffer the centralized log
    storage, with all the advantages this offers: zero disk IO at runtime,
    access to serial and netconsole logging, and remote debug access to
    the kernel log buffer.
  • We now install autofs units for many “API” kernel virtual file
    systems by default, such as binfmt_misc or
    hugetlbfs. That means that the file system access is readily
    available, client code no longer has to manually load the respective
    kernel modules, as they are autoloaded on first access of the file
    system. This has many advantages: it is not only faster to set up
    during boot, but also simpler for applications, as they can just
    assume the functionality is available. On top of that permission
    problems for the initialization go away, since manual module loading
    requires root privileges.
  • Many smaller fixes and enhancements, all across the board, which
    if mentioned here would make this blog story another blog
    novel. Suffice to say, we did a lot of polishing to ready systemd for
    F14.

All in all, systemd is progressing nicely, and the features we have
been working on in the last months are without exception features not
existing in any other of the init systems available on Linux and our
feature set already was far ahead of what the older init
implementations provide. And we have quite a bit planned for the
future. So, stay tuned!

Also note that I’ll speak about systemd at LinuxKongress
2010 in Nuremberg, Germany. Later this year I’ll also be speaking
at the Linux
Plumbers Conference in Boston, MA. Make sure to drop by if you
want to learn about systemd or discuss exiciting new ideas or features
with us.

systemd for Administrators, Part 1

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/systemd-for-admins-1.html

As many of you know, systemd is the new
Fedora init system, starting with F14, and it is also on its way to being adopted in
a number of other distributions as well (for example, OpenSUSE). For administrators
systemd provides a variety of new features and changes and enhances the
administrative process substantially. This blog story is the first part of a
series of articles I plan to post roughly every week for the next months. In
every post I will try to explain one new feature of systemd. Many of these features
are small and simple, so these stories should be interesting to a broader audience.
However, from time to time we’ll dive a little bit deeper into the great new
features systemd provides you with.

Verifying Bootup

Traditionally, when booting up a Linux system, you see a lot of
little messages passing by on your screen. As we work on speeding up
and parallelizing the boot process these messages are becoming visible
for a shorter and shorter time only and be less and less readable —
if they are shown at all, given we use graphical boot splash
technology like Plymouth these days. Nonetheless the information of
the boot screens was and still is very relevant, because it shows you
for each service that is being started as part of bootup, wether it
managed to start up successfully or failed (with those green or red
[ OK ] or [ FAILED ] indicators). To improve the
situation for machines that boot up fast and parallelized and to make
this information more nicely available during runtime, we added a
feature to systemd that tracks and remembers for each service whether
it started up successfully, whether it exited with a non-zero exit
code, whether it timed out, or whether it terminated abnormally (by
segfaulting or similar), both during start-up and runtime. By simply
typing systemctl in your shell you can query the state of all
services, both systemd native and SysV/LSB services:

[root@lambda] ~# systemctl
UNIT                                          LOAD   ACTIVE       SUB          JOB             DESCRIPTION
dev-hugepages.automount                       loaded active       running                      Huge Pages File System Automount Point
dev-mqueue.automount                          loaded active       running                      POSIX Message Queue File System Automount Point
proc-sys-fs-binfmt_misc.automount             loaded active       waiting                      Arbitrary Executable File Formats File System Automount Point
sys-kernel-debug.automount                    loaded active       waiting                      Debug File System Automount Point
sys-kernel-security.automount                 loaded active       waiting                      Security File System Automount Point
sys-devices-pc...0000:02:00.0-net-eth0.device loaded active       plugged                      82573L Gigabit Ethernet Controller
[...]
sys-devices-virtual-tty-tty9.device           loaded active       plugged                      /sys/devices/virtual/tty/tty9
-.mount                                       loaded active       mounted                      /
boot.mount                                    loaded active       mounted                      /boot
dev-hugepages.mount                           loaded active       mounted                      Huge Pages File System
dev-mqueue.mount                              loaded active       mounted                      POSIX Message Queue File System
home.mount                                    loaded active       mounted                      /home
proc-sys-fs-binfmt_misc.mount                 loaded active       mounted                      Arbitrary Executable File Formats File System
abrtd.service                                 loaded active       running                      ABRT Automated Bug Reporting Tool
accounts-daemon.service                       loaded active       running                      Accounts Service
acpid.service                                 loaded active       running                      ACPI Event Daemon
atd.service                                   loaded active       running                      Execution Queue Daemon
auditd.service                                loaded active       running                      Security Auditing Service
avahi-daemon.service                          loaded active       running                      Avahi mDNS/DNS-SD Stack
bluetooth.service                             loaded active       running                      Bluetooth Manager
console-kit-daemon.service                    loaded active       running                      Console Manager
cpuspeed.service                              loaded active       exited                       LSB: processor frequency scaling support
crond.service                                 loaded active       running                      Command Scheduler
cups.service                                  loaded active       running                      CUPS Printing Service
dbus.service                                  loaded active       running                      D-Bus System Message Bus
[email protected]                            loaded active       running                      Getty on tty2
[email protected]                            loaded active       running                      Getty on tty3
[email protected]                            loaded active       running                      Getty on tty4
[email protected]                            loaded active       running                      Getty on tty5
[email protected]                            loaded active       running                      Getty on tty6
haldaemon.service                             loaded active       running                      Hardware Manager
[email protected]                            loaded active       running                      sda shock protection daemon
irqbalance.service                            loaded active       running                      LSB: start and stop irqbalance daemon
iscsi.service                                 loaded active       exited                       LSB: Starts and stops login and scanning of iSCSI devices.
iscsid.service                                loaded active       exited                       LSB: Starts and stops login iSCSI daemon.
livesys-late.service                          loaded active       exited                       LSB: Late init script for live image.
livesys.service                               loaded active       exited                       LSB: Init script for live image.
lvm2-monitor.service                          loaded active       exited                       LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
mdmonitor.service                             loaded active       running                      LSB: Start and stop the MD software RAID monitor
modem-manager.service                         loaded active       running                      Modem Manager
netfs.service                                 loaded active       exited                       LSB: Mount and unmount network filesystems.
NetworkManager.service                        loaded active       running                      Network Manager
ntpd.service                                  loaded maintenance  maintenance                  Network Time Service
polkitd.service                               loaded active       running                      Policy Manager
prefdm.service                                loaded active       running                      Display Manager
rc-local.service                              loaded active       exited                       /etc/rc.local Compatibility
rpcbind.service                               loaded active       running                      RPC Portmapper Service
rsyslog.service                               loaded active       running                      System Logging Service
rtkit-daemon.service                          loaded active       running                      RealtimeKit Scheduling Policy Service
sendmail.service                              loaded active       running                      LSB: start and stop sendmail
[email protected]:22-172.31.0.4:36368.service  loaded active       running                      SSH Per-Connection Server
sysinit.service                               loaded active       running                      System Initialization
systemd-logger.service                        loaded active       running                      systemd Logging Daemon
udev-post.service                             loaded active       exited                       LSB: Moves the generated persistent udev rules to /etc/udev/rules.d
udisks.service                                loaded active       running                      Disk Manager
upowerd.service                               loaded active       running                      Power Manager
wpa_supplicant.service                        loaded active       running                      Wi-Fi Security Service
avahi-daemon.socket                           loaded active       listening                    Avahi mDNS/DNS-SD Stack Activation Socket
cups.socket                                   loaded active       listening                    CUPS Printing Service Sockets
dbus.socket                                   loaded active       running                      dbus.socket
rpcbind.socket                                loaded active       listening                    RPC Portmapper Socket
sshd.socket                                   loaded active       listening                    sshd.socket
systemd-initctl.socket                        loaded active       listening                    systemd /dev/initctl Compatibility Socket
systemd-logger.socket                         loaded active       running                      systemd Logging Socket
systemd-shutdownd.socket                      loaded active       listening                    systemd Delayed Shutdown Socket
dev-disk-by\x1...x1db22a\x1d870f1adf2732.swap loaded active       active                       /dev/disk/by-uuid/fd626ef7-34a4-4958-b22a-870f1adf2732
basic.target                                  loaded active       active                       Basic System
bluetooth.target                              loaded active       active                       Bluetooth
dbus.target                                   loaded active       active                       D-Bus
getty.target                                  loaded active       active                       Login Prompts
graphical.target                              loaded active       active                       Graphical Interface
local-fs.target                               loaded active       active                       Local File Systems
multi-user.target                             loaded active       active                       Multi-User
network.target                                loaded active       active                       Network
remote-fs.target                              loaded active       active                       Remote File Systems
sockets.target                                loaded active       active                       Sockets
swap.target                                   loaded active       active                       Swap
sysinit.target                                loaded active       active                       System Initialization

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

221 units listed. Pass --all to see inactive units, too.
[root@lambda] ~#

(I have shortened the output above a little, and removed a few lines not relevant for this blog post.)

Look at the ACTIVE column, which shows you the high-level state of
a service (or in fact of any kind of unit systemd maintains, which can
be more than just services, but we’ll have a look on this in a later
blog posting), whether it is active (i.e. running),
inactive (i.e. not running) or in any other state. If you look
closely you’ll see one item in the list that is marked maintenance
and highlighted in red. This informs you about a service that failed
to run or otherwise encountered a problem. In this case this is
ntpd. Now, let’s find out what actually
happened to ntpd, with the systemctl status
command:

[root@lambda] ~# systemctl status ntpd.service
ntpd.service - Network Time Service
	  Loaded: loaded (/etc/systemd/system/ntpd.service)
	  Active: maintenance
	    Main: 953 (code=exited, status=255)
	  CGroup: name=systemd:/systemd-1/ntpd.service
[root@lambda] ~#

This shows us that NTP terminated during runtime (when it ran as
PID 953), and tells us exactly the error condition: the process exited
with an exit status of 255.

In a later systemd version, we plan to hook this up to ABRT, as soon as
this enhancement request is fixed. Then, if systemctl
status shows you information about a service that crashed it will
direct you right-away to the appropriate crash dump in ABRT.

Summary: use systemctl and systemctl
status as modern, more complete replacements for the traditional
boot-up status messages of SysV services. systemctl status
not only captures in more detail the error condition but also shows
runtime errors in addition to start-up errors.

That’s it for this week, make sure to come back next week, for the
next posting about systemd for administrators!

Dear Lazy Web,

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/lenovo-laptop-codes.html

does anybody know how to decode those Lenovo ThinkPad model IDs? I am
interested in the T410s. For example, there’s the model NUK3AGE, and there’s
NUHFXGE, and there’s NUHYXGE. Some web sites claim NUK3AGE has Nvidia graphics,
others claim VGA is Intel-only. Some web sites claim it has a touch screen,
others say the contrary. The Lenovo web site isn’t helpful to figure out the
differences between the models and what the feature set of the various models
really is. I figured out the GE suffix indicates a german keyboard, but what
about the remaining code? Anybody knows how to decypher those IDs or knows a
reliable source explaining their feature set?

Love,

Lennart

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

Considerations For FLOSS Hackers About Oracle vs. Google

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

Many have already opined about the Oracle v. Google lawsuit filed last
week. As you might expect, I’m not that worried about what company sues
what company for some heap of cash; those sort of for-profit wranglings
just aren’t what concerns me. Rather, I’m focused on what this event
means for the future of software freedom. And, I think even at this
early stage of the lawsuit, there are already a few lessons for the Free
Software community to learn.

Avoid Single-Company-Controlled Language Infrastructure

Fourteen months ago, before the Oracle purchase of Sun,
I wrote
about the specific danger of language infrastructure developed by a
single for-profit patent-holding entity (when such infrastructure is
less than 20 years old). In that blog post, I wrote:

[Some] might argue that with all those patents consolidated [in a single
company], patent trolls will have a tough time acquiring patents and
attacking FaiF
implementations. However, while this can sometimes be temporarily true,
one cannot rely on this safety. Java, for example, is in a precarious
situation now. Oracle is not a friend to Free Software, and soon will
hold all Sun’s Java patents — a looming threat to FaiF Java
implementations … [A]n Oracle attack on FaiF Java is a possibility.

I’m sorry that I was right about this, but we should now finally learn
the lesson: languages like Java and C# are dangerous. Single companies
developed them, and there are live, unexpired patents that can easily be
used in a group to attack FaiF implementations. Of course, that doesn’t
mean other language infrastructures are completely safe from patents,
but I believe there is greater relative risk of a system with patent
consolidation at a single company.

It also bears repeating the point I made
on Linux
Outlaws last July: this doesn’t mean the Free Software community
shouldn’t have FaiF implementations of all languages. In fact,
we absolutely should, because we do want developers who are
familiar with those languages to bring their software over to GNU/Linux
and other Free Software systems.

However, this lawsuit proves that choosing some languages for newly
written Free Software is dangerous and should be avoided, especially
when there are safer choices like C, C++, Python, and Perl0. (See
my blog
post from last year for more on this subject.)

Never Let Your Company File for Patents on Your Work

James Gosling is usually
pretty cryptic in his non-technical writing, but I think if you read
carefully, it seems to me
that Gosling
regrets that Oracle now holds his patents on Java. I know developers
get nice bonuses if they let their company apply for patents on their
work. I also know there’s pressure in most large companies to get more
patents. We, as developers, must simply refuse this. We invent
this stuff, not the suits and the lawyers who want to exploit our work for
larger and larger profits. As a community of developers and computer
scientists, we must simply refuse to ever let someone patent our work. In
a phrase: just say no.

Even if you like your company today, you never know who will own those
software patents later. I’m sure James Gosling originally never
considered the idea that a company as revolting as Oracle would have
control of everything he’s invented for the last two decades. But they
do, and there’s nothing Gosling can do about what’s done with his work
and “inventions”. Learn from this example; don’t let your
company patent your work. Instead, publish online to establish prior
art as quickly as possible.

Google Is Not Merely a Pure Free Software Distributor

Google
has worked hard to cast themselves as innocent,
Free-Software-producing victims. That’s good PR because it’s true, but
it’s also not telling the whole
truth. Google
worked hard to make sure Android was completely Apache-2.0 (or even more
permissively) licensed (except for Linux, of course). There was
already plenty
Java stuff
available under the GPL that Google could have used. Sadly, Google was
so allergic to GPL for Android/Linux that they even avoided LGPL’d
components like uClibc
and glibc (in favor of
their own
permissively-licensed C library based on a BSD version).

Google’s reason for permissive-only licensing for “everything but
the kernel” was likely a classic “adoption is more important
than software freedom” scenario. Google wants Android/Linux in as
many phones as possible, and wants to eliminate any
“barrier” to such adoption, even if such a
“barrier” would defend software freedom.

This new lawsuit would be much more interesting if Google had chosen
GPL and/or LGPL for Android. In fact, if I fantasize about being
empowered to design a binding, non-financial settlement to the lawsuit,
the first item on my list would be a relicense of all future
Android/Linux systems under GPL and/or LGPL. (Basically, Google would
license only enough under LGPL to allow proprietary applications, and
license all the rest as GPL, thus yielding the same licensing
consequences as GNU/Linux and GNOME). Then, I’d have Oracle explicitly
license all its patents under GPL and/or LGPL
compatible licenses that would permit Android/Linux to continue
unencumbered, but under
copyleft. (BTW, Mark
Wielaard has a blog post that discussed more about the issue of
GPL’d/LGPL’d Java implementations and how they relate to this
lawsuit.)

I realize that’s never going to happen, but it’s an interesting thought
experiment. I am of course opposed to software patents, and I certainly
oppose companies like Oracle that produce almost all proprietary
software. However, I can at least understand the logic of Oracle not
wanting its software patents exercised in proprietary software. I think
a trade off, whereby all software patents are licensed freely and
royalty-free only for use in copylefted software is a reasonable
compromise. OTOH, knowing Oracle, they could easily have plans to
attack copyleft implementations too. Thus, we must assume they won’t
accept this reasonable compromise of “royalty-free licensing for
copyleft only”. That brings me to my next point of FaiF hackers’
concern about this lawsuit.

Never Trust a Mere Patent Promise; Demand Real Patent Licenses

I wrote after Bilski
that patent
promises just aren’t enough, and this lawsuit is an example of why.
I presume that Oracle’s lawyers have looked carefully as the various
promises and assurances that Sun made about its Java patents and have
concluded Oracle has good arguments for why those promises don’t apply
to Android. I have no idea what those arguments are, but rarely do
lawyers file a lawsuit without very good arguments already prepared. I
hope Oracle’s lawyers’ arguments are wrong and they lose. But, the fact
that Oracle even has a credible argument that Android/Linux doesn’t
already have a patent license shows again that patent promises are just
not enough.

Miguel de Icaza
used this
opportunity to point out how the Microsoft C# promises are
“better” by comparison, in his opinion.
But, Brett Smith at
FSF already found huge holes in those Microsoft promises that haven’t
been fixed. In fact, any company making these promises always tries
to hide as much nasty stuff as it can, to convince the users that they
are safe from patent aggression when they really aren’t. That’s why the
Free Software community must demand simple, clear, and permanent
royalty-free patent licenses for all patents any
company might hold. We should accept nothing less. As mentioned above,
those licenses could perhaps require that a certain Free Software
copyright license, such as GPLv3-or-later, be used for any software that
gets the advantage of the license. (i.e., I can certainly understand if
companies don’t want to accidentally grant such patent licenses to their
proprietary software competitors).

Indeed, it’s particularly important that the licenses
cover all patents and those possibly exercised in future
improvements in the software. This lawsuit has clearly shown that even
if patent pools exist for some subsets of patents for some subsets of
Free Software, patent holders will either use other patents for
aggression, or they’ll assert patents in the patent pools against Free
Software that’s not part of the pool. In essence, we must assume that
any for-profit company will become a patent troll eventually
(they always do), and therefore any cross-licensing pools that don’t
include every patent possible for any possible Free Software will always
be inadequate. So, the answer is simple: trust no
software-patent-holding company unless they give an explicit
GPLv3-compatible license for all their patents.

We Must End Software Patents

The failure of the Bilski case to end software patents in the USA means
much work lies ahead to end software patents.
The End
Software Patents Wiki has some good stuff about this case as well as
lots of other information related to software patents. There are now
heavily funded for-profit corporate efforts that seek to convince the
Free Software community
that patent
reform is enough. But, it’s not! For example, if you see
presenters at
FLOSS
conferences claiming to have solutions to patent problems, ask them if their
organization opposes all software patents, and ask them if their funders
license all their patents freely for GPLv3-or-later software
implementations. If you hear the wrong answers, then their motives and
mission are suspect.

Finally, I’d like to note that, in some sense, these patent battles
help Free Software, because it may actually teach companies that the
expense of having software patents is not worth the risk of patent
lawsuits. It’s possible we’ve reached a moment in history where it’d be
better if the Software Patent Cold War becomes a full Software Patent
Nuclear War. Software freedom can survive that “nuclear
winter”. I sometimes think that in the Free Software community,
we may find ourselves left with just two choices: fifty more years of
Patent Cold War (with lots of skirmishes like this one), or ten years of
full-on patent war (after which companies would beg Congress to end
software patents). Both outcomes are horrible until they’re resolved,
but the latter would reach resolution quicker. I often wonder which one
is the better long term for software freedom.

But, no matter what happens next, the necessary position is: all software
patents are bad for software freedom. Any entity that supports anything
short of full abolition of software patents is working against software
freedom.

0I originally had PHP listed here,
but jwildeboer
argued that Zend Technologies, Ltd. might be a problem for PHP in
the same way Oracle is for Java and Microsoft for C#. It’s true that
Zend is a software patent holder and was involved in the development
of later PHP versions. I don’t think the single-company-controlled
software patent risks with PHP are akin to those of Java and C#, since
Zend Technologies isn’t the only entity involved in PHP’s development,
but certainly the other languages listed are likely preferable to
PHP.

The collective thoughts of the interwebz