Tag Archives: Copyright

Welcome (Finally!) to the GCC Runtime Library Exception

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/27/gcc-exception.html

For the past sixteen months, I participated in a bit of a “mini-GPLv3
process” among folks at the FSF, SFLC, the GNU Compiler Collection
Steering Committee (GCC SC), and the GCC community at large. We’ve been
drafting an important GPLv3 license exception (based on a concept by
David Edelsohn and Eben Moglen, that they invented even before the
GPLv3 process itself started).
Today, that
GCC Runtime Library Exception for GPLv3 went into production
.

I keep incessant track of my hours spent on various projects, so I have
hard numbers that show I personally spent 188 hours — a full month
of 40-hour weeks — on this project. I’m sure my colleagues
have spent similar amounts, too. I am proud of this time, and I think
it was absolutely worthwhile. I hope the discussion gives you a flavor
of why FLOSS license exception drafting is both incredibly important and
difficult to get right without the greatest of care and attention to
detail.

Why GPL Exceptions Exist

Before I jump into discussion of this GCC Runtime Library exception,
some background is needed. Exceptions have been a mainstay of copyleft
licensing since the inception of the GNU project, and once you’ve seen
many examples over many years, they become a standard part of FLOSS
licensing. However, for the casual FLOSS developer who doesn’t wish to
be a licensing wonk (down this path lies madness, my friends, run
screaming with your head covered!), exceptions are a rare discovery in a
random source file or two, and they do not command great attention. An
understandable reaction, but from a policy perspective, they are an
essential part of the copyleft system.

From the earliest days of the copyleft, it was understood that copyleft
was a merely a strategy to reach the goal of software freedom. The GPL
is a tool that implements this strategy, but like any tool, it doesn’t
fit every job.

In some sense, the LGPL was the earliest and certainly the most widely
known “GPL exception”. (Indeed, my friend Richard Fontana
came up with the idea to literally make LGPL an exception to
GPLv3, although in the v2 world, LGPLv2 was a fully separate license
from GPLv2.) Discussions on why the LGPL exists are beyond the scope of
this blog post
(although I’ve
written about them before
). Generally speaking, though, LGPL is
designed to be a tool when you don’t want the full force of copyleft for
all derivative works. Namely, you want to permit the creation of some
proprietary (or partly proprietary) derivative works because allowing
those derivations makes strategic sense in pursuing the goal of software
freedom.

Aside from the LGPL, the most common GPL exceptions are usually what we
generally categorize as “linking exceptions”. They allow
the modifier to take some GPL’d object code and combine it in some way
with some proprietary code during the compilation process. The simplest
of these exceptions is found when you, for example, write a GPL’d
program in a language with only a proprietary implementation, (e.g.,
VisualBasic) and you want to allow the code to combine with the
VisualBasic runtime libraries. You use your exclusive right as
copyright holder on the new program to grant downstream users,
redistributors and modifiers the right combine with those proprietary
libraries without having those libraries subject to copyleft.

In essence, copyleft exceptions are the scalpels of copyleft. They
allow you to create very carefully constructed carve-outs of permission
when pure copyleft is too blunt an instrument to advance the goal of
software freedom. Many software freedom policy questions require this
fine cutting work to reach the right outcome.

The GCC Exception

The GCC Exception (well, exceptions, really) have
always been a particularly interesting and complex use of a copyleft
exception. Initially, they were pragmatically needed to handle a
technological reality about compilers that interacts in a strange way
with copyright derivative works doctrine. Specifically, when you
compile a program with gcc, parts of GCC itself, called the runtime
library (and before that, crt0), are combined directly with your program
in the output binary. The binary, therefore, is both a derivative work
of your source code and a derivative work of the runtime library. If
GCC were pure GPL, every binary compiled with GCC would need to be
licensed under the terms of GPL.

Of course, when RMS was writing the first GCC, he realized immediately
this licensing implication and created an exception to avoid this.
Versions of that exception has been around and improved since the late
1980s. The task that our team faced in late 2007 was to update that
exception, both to adapt it to the excellent new GPLv3 exceptions
infrastructure (as Fontana did for LGPLv3), and to handle a new policy
question that has been kicking around the GCC world since 2002.

The Plugin Concern

For years, compiler experimentalists and researchers have been
frustrated by GCC. It’s very difficult to add a new optimization to GCC
because you need quite a deep understanding of the codebase to implement
one. Indeed I tried myself, as a graduate student in programming
languages in the mid-1990s, to learn enough about GCC to do this, but
gave up when a few days of study got me nowhere. Advancement of
compiler technology can only happen when optimization experimentation
can happen easily.

To make it easy to try new optimizations out, GCC needs a plugin
architecture. However, the GCC community has resisted this because of
the software freedom implications of such an architecture: if plugins
are easy to write, then it will be easy to write out to disk a version
of GCC’s internal program representation (sometimes called the
intermediate representation, or IR). Then, proprietary programs could
be used to analyze and optimize this IR, and a plugin could be used to
read the file back into GCC.

From a licensing perspective, such an optimizing proprietary program
will usually not be a derivative work of GCC; it merely reads and writes
some file format. It’s analogous to OpenOffice reading and writing
Microsoft Word files, which doesn’t make it a derivative of Word by any
means! The only parts that are covered by GPL are the actual plugins to
GCC to read and write the format, just as OpenOffice’s Word reader and
writer are Free Software, but Microsoft Word is not.

This licensing implication is a disaster for the GCC community. It
would mean the advent of “compilation processes” that were
“mixed”, FaiF and proprietary. The best, most difficult and
most interesting parts of that compilation process — the
optimizations — could be fully proprietary!

This outcome is unacceptable from a software freedom policy
perspective, but difficult to handle in licensing. Eben Moglen, David
Edelsohn, and a few others, however, came up with an innovative idea:
since all binaries are derivative of GCC anyway, set up the exception so
that proprietary binary output from GCC is permitted only when the
entire compilation process involves Free Software. In other words, you
can do these proprietary optimization plugins all you want, but if you
do, you’ll not be able to compile anything but GPL’d software with
them!

The Drafting and the Outcome

As every developer knows, the path from “innovative idea”
to “working implementation” is a long road. It’s just as
true with licensing policy as it is with code. Those 188 hours that
I’ve spent, along with even more hours spent by a cast of dozens, have
been spent making a license exception that implements that idea
accurately without messing up the GCC community or its licensing
structure.

With jubilation today, I link to
the announcement
from the
FSF
, the
FAQ and Rationale for the exception
and
the final
text of the exception itself
. This sixteen-month long cooperation
between the FSF, the SFLC, the GCC SC, and the GCC community has
produced some fine licensing policy that will serve our community well
for years to come. I am honored to have been a part of it, and a bit
relieved that it is complete.

LGPL’ing of Qt Will Encourage More Software Freedom

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library
. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption
. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license
to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file
, and encourage other projects
to follow that example.

GPL, The 2-clause BSD of Network Services

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/09/04/netservices-source-culture.html

Crossposted
with autonomo.us
.
So often, a particular strategy becomes dogma. Copyleft licensing
constantly allures us in this manner. Every long-term software freedom
advocate I have ever known — myself included — has spent
periods of time slipping on the comfortable shoes of belief that
copyleft is the central catalyst for software freedom.

Copyleft indeed remains a successful strategy in maximizing software
freedom because it backs up a community consensus on software sharing
with the protection of the law. However, most people do not comply
with the GPL merely because they fear the consequences of copyright
infringement. Rather, they comply for altruistic reasons: because it
advances their own freedom and the freedom of the people around
them.

Indeed, it is so important to remember that many of the FLOSS
programs we use every day are not copylefted, and do not actually have
any long-term proprietary forks (for me, Subversion, Trac and Twisted come to mind quickly).
Examples like this helped me to again re-eradicate some clouded
thinking about copyleft as central tenant.

With this mindset fresh, Mike Linksvayer and I had an excellent
discussion last month that solidified this connection to network
services, and specifically, the licenses for network services software.
Many GPL’d network service software give no source to users, but that
may have little to do with the authors’ “failure to
upgrade” to the AGPL. In other words, the non-source
availability of network service applications that are otherwise licensed
in freedom is probably unrelated to the lack of network-freedom
provisions in the license.

In fact, more likely, the network service world now mimics the early
days of the BSD licenses. Deployers are “proprietarizing”
by default merely because there is no social effect to encourage
release of modified source. Often, they likely
haven’t considered the complex issues of network service freedom, and
are following the common existing practices. Advent of the GPL
did help encourage software sharing in the community, but the
general change in social standards that accompanied the GPL probably had
a more substantial impact.

Therefore, improved social standards will help improve source sharing
in network services. We need to encourage, and more importantly,
make it easy for network service deployers to make source of
network applications available, regardless of their particular FLOSS
license. No existing non-AGPL FLOSS licenses
prohibit making the source available to network
users. Network providers can and should simply do it voluntarily out
of respect for their users. Developers of network service software,
even if they do not choose the AGPL, should make it easy for the
deployers to give source to their users. I hope to assist in this
regard more directly before the end of 2008.

If The Worst of Us Wins, The Best of Us Surely Will

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/08/16/artistic.html

There has
been much
chatter

and coverage
about the court decision related to the Artistic License decision last
week. Having spent a decade worrying about the Artistic License, I was
surprised and relieved to see this decision.

One of the first tasks I undertook in the late 1990s in the world of
Software Freedom licenses were issues surrounding the Artistic License.
My first Software Freedom community was the Perl one, but my second was
the licensing wonks. Therefore, I walked the line for many years, as I
considered the poor drafting of the Original Artistic License. As the
Perl6 process started in 2000, I chaired the Licensing Committee, and
wrote all of the licensing RFCs
in the Perl6
process
, including
RFC 211, which collected all the historical arguments about bad drafting
of the Artistic License and argued that we change the Artistic License
.

Last year, I was silent about the lower court decision, because I’d
known for years that the Original Artistic License was a poorly drafted
and confusing license. I frankly was not surprised that a court had
considered it problematic. Of course, I was glad for the appeal, and that
there was a widely supported amicus brief arguing that the Artistic
License should be treated appropriately as a copyright license.
However, I had already prepared myself to live with the fact that the my
greatest licensing fears had come true: the most poorly drafted FLOSS
license had been the first for a USA court to consider, and that court had
seen what we all saw — a license that was confusing and could not be
upheld due to lack of clarity.

I was overjoyed last week to see
that the
Federal Circuit ruled
that even a poorly drafted copyright license
like that must be taken seriously and that the copyright
holder could seek remedies under copyright law. Now that I have
seen this decision, I feel confident that the rest of our licenses will
breeze through the courts, should the need arise. We’ve been arguing for
a decade that the Artistic license is problematic, and even Larry Wall
(its author) admitted that his intent wasn’t necessarily to draft a good
license but to inspire people to contact him for additional permissions
outside the GPL. Nevertheless, he drafted a license that the USA courts
clearly see as a valid copyright license. The bottom bar has been set,
and since all our other licenses are much clearer, it will be smooth
sailing here on out.

(Please note, if you are a fan of the Artistic
License, the
Artistic License 2.0
is a much better option and is
recommended. Despite the decision, we should still cease using the
Original Artistic License now that we have 2.0.)

The GPL is a Tool to Encourage Freedom, Not an End in Itself

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/04/10/gpl-not-end-in-itself.html

I was amazed to be involved in yet another discussion recently
regarding the old debate about the scope of the GPL under copyright law.
The debate itself isn’t amazing — these debates have happened
somewhere every six months, almost on cue, since around 1994 or so.
What amazed me this time is that some people in the debate believed that
the GPL proponents intend to sneakily pursue an increased scope for
copyright law. Those who think that have completely misunderstood the
fundamental idea behind the GPL.

I’m disturbed by the notion that some believe the goal of the GPL is to
expand copyrightability and the inclusiveness of derivative works. It
seems that so many forget (or maybe they never even knew) that copyleft
was invented to hack copyright — to turn its typical applications
to software inside out. The state of affairs that software is
controlled by draconian copyright rules is a lamentable reality;
copyleft is merely a tool that diffuses the proprietary copyright
weaponry.

But, if it were possible to really consider reduction in copyright
control over software, then I don’t know of a single GPL proponent who
wouldn’t want to bilaterally reduce copyright’s scope for software. For
example, I’ve often proposed, since around 2001, that perhaps copyright
for software should only last three years, non-renewable, and that it
require all who wished to distribute non-public-domain software to
register the source with the Copyright Office. At the end of the three
years, the Copyright Office would automatically publish that now
public-domain source to the world.

If my hypothetical system were the actual (and only) legal regime for
software, and were equally applied to all software — from the
fully Free to the most proprietary — I’d have no sadness at all
that opportunities for GPL enforcement ended after three years, and that
all GPL’d software fell into the public domain on that tight schedule,
because proprietary software and FLOSS would have the same treatment.
Meanwhile, great benefit would be gained for the freedom of all software
users. In short, GPL is not an end in itself, and I wouldn’t want to
ignore the actual goal — more freedom for software users —
merely to strengthen one tool in that battle.

In one of my favorite films, Kevin Smith’s Dogma, Chris
Rock’s character, Rufus, argues that it’s better to have ideas than
beliefs, because ideas can change when the situation does, but beliefs
become ingrained and are harder to shake. I’m not a belief-less person,
but I certainly hold the GPL and the notion of copyleft firmly in the
“idea” camp, not the “belief” one. It’s
unfortunate that the entrenched interests outside of software are (more
or less) inadvertently strengthening software copyright, too. Thus, in
the meantime, we must hold steadfast to the GPL going as far as is
legally permitted under this ridiculously expansive copyright system we
have. But, should a real policy dialogue open on the reduction software
copyright’s scope, GPL proponents will be the first in line to encourage
such bilateral reduction.

stet and AGPLv3

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2007/11/21/stet-and-agplv3.html

Many people don’t realize that the GPLv3 process actually began long
before the November 2005 announcement. For me and a few others, the GPLv3
process started much earlier. Also, in my view, it didn’t actually end
until this week, the FSF released the AGPLv3. Today, I’m particularly
proud that stet was the first software released covered by the terms of
that license.

The GPLv3 process focused on the idea of community, and a community is
built from bringing together many individual experiences. I am grateful
for all my personal experiences throughout this process. Indeed, I
would guess that other GPL fans like myself remember, as I do, the first
time the heard the phrase “GPLv3”. For me, it was a bit
early — on Tuesday 8 January 2002 in a conference room at MIT. On
that day, Richard Stallman, Eben Moglen and I sat down to have an
all-day meeting that included discussions regarding updating GPL. A key
issue that we sought to address was (in those days) called the
“Application Service Provider (ASP) problem” — now
called “Software as a Service (SaaS)”.

A few days later, on the telephone with Moglen2 one morning, as I stood in my
kitchen making oatmeal, we discussed this problem. I pointed out the
oft-forgotten section 2(c) of the GPL [version 2]. I argued that contrary
to popular belief, it does have restrictions on some minor
modifications. Namely, you have to maintain those print statements for
copyright and warranty disclaimer information. It’s reasonable, in other
words, to restrict some minor modifications to defend freedom.

We also talked about that old Computer Science problem of having a
program print its own source code. I proposed that maybe we needed a
section 2(d) that required that if a program prints its own source to
the user, that you can’t remove that feature, and that the feature must
always print the complete and corresponding source.

Within two months, Affero
GPLv1 was published
— an authorized fork of the GPL to test
the idea. From then until AGPLv3, that “Affero clause”
has had many changes, iterations and improvements, and I’m grateful
for all the excellent feedback, input and improvements that have gone
into it. The
result, the
Affero GPLv3 (AGPLv3) released on Monday
, is an excellent step
forward for software freedom licensing. While the community process
indicated that the preference was for the Affero clause to be part of
a separate license, I’m nevertheless elated that the clause continues
to live on and be part of the licensing infrastructure defending
software freedom.

Other than coining the Affero clause, my other notable personal
contribution to the GPLv3 was management of a software development
project to create the online public commenting system. To do the
programming, we contracted with Orion Montoya, who has extensive
experience doing semantic markup of source texts from an academic
perspective. Orion gave me my first introduction to the whole
“Web 2.0” thing, and I was amazed how useful the result was;
it helped the leaders of the process easily grok the public response.
For example, the intensity highlighting — which shows the hot
spots in the text that received the most comments — gives a very
quick picture of sections that are really of concern to the public. In
reviewing the drafts today, I was reminded that the big red area in
section 1 about “encryption and authorization codes”
is
substantially
changed and less intensely highlighted by draft 4
. That quick-look
gives a clear picture of how the community process operated to get a
better license for everyone.

Orion, a Classics scholar as an undergrad, named the
software stet for its original Latin definition: “let it
stand as it is”. It was his hope that stet (the software) would
help along the GPLv3 process so that our whole community, after filing
comments on each successive draft, could look at the final draft and
simply say: Stet!

Stet has a special place in software history, I believe, even if it’s
just a purely geeky one. It is the first software system in history to
be meta-licensed. Namely, it was software whose output was its own
license. It’s with that exciting hacker concept that I put up today
a Trac instance
for stet, licensed under the terms of the AGPLv3 [ which is now on
Gitorious ]
1.

Stet is by no means ready for drop-in production. Like most software
projects, we didn’t estimate perfectly how much work would be needed.
We got lazy about organization early on, which means it still requires a
by-hand install, and new texts must be carefully marked up by hand.
We’ve moved on to other projects, but hopefully SFLC will host the Trac
instance indefinitely so that other developers can make it better.
That’s what copylefted FOSS is all about — even when it’s
SaaS.

1Actually, it’s
under AGPLv3 plus an exception to allow for combining with the
GPLv2-only Request Tracker, with which parts of stet combine.

2Update
2016-01-06:After writing this blog post, I found
evidence in my email archives from early 2002, wherein Henry Poole (who
originally suggested the need for Affero GPL to FSF), began cc’ing me anew
on an existing thread. In that thread, Poole quoted text from Moglen
proposing the original AGPLv1 idea to Poole. Moglen’s quoted text in
Poole’s email proposed the idea as if it were solely Moglen’s own. Based
on the timeline of the emails I have, Moglen seems to have written to Poole
within 36-48 hours of my original formulation of the idea.

While I do not accuse Moglen of plagiarism, I believe he does at least
misremember my idea as his own, which is particularly surprising, as Moglen
(at that time, in 2002) seemed unfamiliar with the Computer Science concept
of a quine; I had to explain that concept as part of my presentation of my
idea. Furthermore, Moglen and I discussed this matter in a personal
conversation in 2007 (around the time I made this blog post originally) and
Moglen said to me: “you certainly should take credit for the Affero
GPL”. Thus, I thought the matter was thus fully settled back in
2007, and thus Moglen’s post-2007 claims of credit that write me out of
Affero GPL’s history are simply baffling. To clear up the confusion his
ongoing claims create, I added this footnote to communicate unequivocally
that my memory of that phone call is solid, because it was the first time I
ever came up with a particularly interesting licensing idea, so the memory
became extremely precious to me immediately. I am therefore completely
sure I was the first to propose the original idea of mandating preservation
of a quine-like feature in AGPLv1§2(d) (as a fork/expansion of
GPLv2§2(c)) on the telephone to Moglen, as described above. Moglen
has never produced evidence to dispute my recollection, and even agreed
with the events as I told them back in 2007.

Nevertheless, unlike Moglen, I do admit that creation of the final text of
AGPLv1 was a collaborative process, which included contributions from
Moglen, Poole, RMS, and a lawyer (whose name I don’t recall) whom Poole
hired. AGPLv3§13’s drafting was similarly collaborative, and included
input from Richard Fontana, David Turner, and Brett Smith, too.

Finally, I note my surprise at this outcome. In my primary community
— the Free Software community — people are generally extremely
good at giving proper credit. Unlike the Free Software community, legal
communities apparently are cutthroat on the credit issue, so I’ve
learned.

Tools for Investigating Copyright Infringement

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2007/05/08/infringement.html

Nearly all software developers know that software is covered by
copyright. Many know that copyright covers the expression of an idea
fixed in a medium (such as a series of bytes), and that the copyright
rules govern the copying, modifying and distributing of the work.
However, only a very few have considered the questions that arise when
trying to determine if one work infringes the copyright of
another.

Indeed, in the world of software freedom, copyright is seen as a system
we have little choice but to tolerate. Many Free Software developers
dislike the copyright system we have, so it is little surprise that
developers want to spend minimal time thinking about it.
Nevertheless, the copyright system is the foremost legal framework
that governs software1, and we have to
live within it for the moment.

My fellow developers have asked me for years what constitute copyright
infringement. In turn, for years, I have asked the lawyers I worked
with to give me guidelines to pass on to the Free Software development
community. I’ve discovered that it’s difficult to adequately describe
the nature of copyright infringement to software developers. While it
is easy to give pathological examples of obvious infringement (such as
taking someone’s work, removing their copyright notices and
distributing it as your own), it quickly becomes difficult to give
definitive answers in many real world examples whether some particular
activity constitutes infringement.

In fact, in nearly every GPL enforcement cases that I’ve worked on in
my career, the fact that infringement had occurred was never in
dispute. The typical GPL violator started with a work under GPL, made
some modifications to a small portion of the codebase, and then
distributed the whole work in binary form only. It is virtually
impossible to act in that way and still not infringe the original
copyright.

Usually, the cases of “hazy” copyright infringement come up
the other way around: when a Free Software program is accused of
infringing the copyright of some proprietary work. The most famous
accusation of this nature came from Darl McBride and his colleagues at
SCO, who claimed that something called “Linux” infringed
his company’s rights. We now know that there was no copyright
infringement (BTW, whether McBride meant to accuse the GNU/Linux
operating system or the kernel named Linux, we’ll never actually
know). However, the SCO situation educated the Free Software
community that we must strive to answer quickly and definitively when
such accusations arise. The burden of proof is usually on the
accuser, but being able to make a preemptive response to even the hint
of an allegation is always advantageous when fighting FUD in the court
of public opinion.

Finally, issues of “would-be” infringement detection come
up for companies during due diligence work. Ideally, there should be
an easy way for companies to confirm which parts of their systems are
derivatives of Free Software systems, which would make compliance with
licenses easy. A few proprietary software companies provide this
service; however there should be readily available Free Software tools
(just as there should be for all tasks one might want to perform with a
computer).

It is not so easy to create such tools. Copyright infringement is not
trivially defined; in fact, most non-trivial situations require a
significant amount of both technical and legal judgement. Software
tools cannot make a legal conclusion regarding copyright infringement.
Rather, successful tools will guide an expert’s analysis of a
situation. Such systems will immediately identify the rarely-found
obvious indications of infringement, bring to the forefront facts that
need an exercise of judgement, and leave everything else in the
background.

In this multi-part series of blog entries, I will discuss the state of
the art in these Free Software systems for infringement analysis and
what plans our community should make for the creation Free systems
that address this problem.

1 Copyright is the legal
system that non-lawyers usually identify most readily as governing
software, but the patent system (unfortunately) also governs software
in many countries, and many non-Free Software licenses (and a few of
the stranger Free Software ones) also operate under contract law as
well as copyright law. Trade secrets are often involved with software
as well. Nevertheless, in the Software Freedom world, copyright is
the legal system of primary attention on a daily basis.

Chasing A Light

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/chasing-light.html

Last friday I posted a little Lazyweb experiment,
a hunt for information about a certain kind of lamp sold by a street dealer in
Mexico City. A quick followup on the results:

Surprinsingly many people responded, mostly by email, and partly by blog comment.
As it appears I am not the only one who’s looking for this specific type of
lamp. Furthermore, a non-trivial set of Planet Gnome readers actually already
owns one of these devices. Apparently counterfeit versions of this lamp are
sold all around the world by street dealers and on markets.

The lamp seems to be a modified version of the “IQ Light”, a self
assembly lighting system made up of interlocking quadrilaterals. It is
a scandinavian design, by Holger Strøm, 1973. It is nowadays
exclusively distributed by Bald & Bang,
Denmark. The lighting system has a very interesting web site of its own, which even includes an
HOWTO for
assembling these lamps. The Bald & Bang web site has a
very stylish video which also shows how to assemble an IQ lamp.

Fake IQ Light from Mexico

While my mexican specimen and the official design are very similar, they
differ: the mexican design looks – in a way – “tighter” and … better (at
least in my humble opinion). For comparison, please have a look on the photo I took from the mexican version which is shown
above, and on the many photos returned by Google
Images
, or the one from the IQ Light homepage. It
appears as if the basic geometrical form used by the mexican design is somehow
more narrow than the official danish one.

So, where can one buy one of those lamps? Fake and real ones are sold on
eBay
, every
now an then
. The Museum
Store of the New York MoMA
sells the original version for super-cheap $160.
If you search with Google you’ll find many more offers like this one, but all
of them are not exactly cheap – for a bunch of thin plastic sheets. All these
shops sell the danish version of the design, noone was able to point me to a shop
where the modified, “mexican” version is sold.

Given the hefty price tag and the fact that the fake, mexican version looks
better then the original one, I will now build my own lamps, based on the
mexican design. For that I will disassamble my specimen (at least partially)
and create a paper stencil of the basic plastic pattern. I hope to put this up
for download as a .ps file some time next week, since many people
asked for instructions for building these lamps. Presumably the original
design is protected by copyright, hence I will not publish a step-by-step guide
how to build your own fake version. But thankfully this is not even necessary, since the vendor already published a HOWTO and a video for this, online.

Thank you very much for your numerous responses!

Chasing A Light

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/chasing-light.html

Last friday I posted a little Lazyweb experiment,
a hunt for information about a certain kind of lamp sold by a street dealer in
Mexico City. A quick followup on the results:

Surprinsingly many people responded, mostly by email, and partly by blog comment.
As it appears I am not the only one who’s looking for this specific type of
lamp. Furthermore, a non-trivial set of Planet Gnome readers actually already
owns one of these devices. Apparently counterfeit versions of this lamp are
sold all around the world by street dealers and on markets.

The lamp seems to be a modified version of the “IQ Light”, a self
assembly lighting system made up of interlocking quadrilaterals
. It is
a scandinavian design, by Holger Strøm, 1973. It is nowadays
exclusively distributed by Bald & Bang,
Denmark. The lighting system has a very interesting web site of its own, which even includes an
HOWTO for
assembling these lamps. The Bald & Bang web site has a
very stylish video which also shows how to assemble an IQ lamp.

Fake IQ Light from Mexico

While my mexican specimen and the official design are very similar, they
differ: the mexican design looks – in a way – “tighter” and … better (at
least in my humble opinion). For comparison, please have a look on the photo I took from the mexican version which is shown
above, and on the many photos returned by Google
Images
, or the one from the IQ Light homepage. It
appears as if the basic geometrical form used by the mexican design is somehow
more narrow than the official danish one.

So, where can one buy one of those lamps? Fake and real ones are sold on
eBay
, every
now an then
. The Museum
Store of the New York MoMA
sells the original version for super-cheap $160.
If you search with Google you’ll find many more offers like this one, but all
of them are not exactly cheap – for a bunch of thin plastic sheets. All these
shops sell the danish version of the design, noone was able to point me to a shop
where the modified, “mexican” version is sold.

Given the hefty price tag and the fact that the fake, mexican version looks
better then the original one, I will now build my own lamps, based on the
mexican design. For that I will disassamble my specimen (at least partially)
and create a paper stencil of the basic plastic pattern. I hope to put this up
for download as a .ps file some time next week, since many people
asked for instructions for building these lamps. Presumably the original
design is protected by copyright, hence I will not publish a step-by-step guide
how to build your own fake version. But thankfully this is not even necessary, since the vendor already published a HOWTO and a video for this, online.

Thank you very much for your numerous responses!

Cui Bono?

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/cui-bono.html

So, you thought that only Linux users (and other alternative OS zealots)
would benefit from reverse
engineered Windows drivers
? Ha! Far from the truth, it’s the Windows
users themselves
who are benefitting. (Sorry, that link is in German)

Too bad that this specific Windows port actually infringes my copyrights
since it links my GPL’ed code against the non-free inpout32.dll. And the guy who did
that port doesn’t even think it’s necessary to put his email address anywhere.

Cui Bono?

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/cui-bono.html

So, you thought that only Linux users (and other alternative OS zealots)
would benefit from reverse
engineered Windows drivers
? Ha! Far from the truth, it’s the Windows
users themselves
who are benefitting. (Sorry, that link is in German)

Too bad that this specific Windows port actually infringes my copyrights
since it links my GPL’ed code against the non-free inpout32.dll. And the guy who did
that port doesn’t even think it’s necessary to put his email address anywhere.