The Desktop Summit Wiki Is Full Of Interesting Stuff

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

Just wanted to draw your attention to the Desktop Summit Wiki. If you
are attending the Desktop Summit in Berlin you might find some
interesting information in the Wiki.

Go to the main page of
the Wiki here. You are welcome to edit and add additional information to
the Wiki. To edit the Wiki authenticate with the same credentials you used to
sign up for the conference at the Desktop Summit web site.

See you on friday!

Desktop Summit Announcements, Part II

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/desktop-summit-announce2.html

Read
the first part of the announcements.

And now there are more exciting announcements:

Only 5 days are now left to beginning of the conference. The first event
will already take place on Friday August 5th, at c-base at U/S Jannowitzbrücke,
starting at 4pm. The conference programme itself will begin on Saturday August
6th, 10am (though do come earlier, for registration, if you didn’t register at
the c-base event already!). Note that the primary entrance to the Desktop
Summit is in the north-eastern corner of the main building of Humboldt
University. That’s on Dorotheenstr./Hegelplatz, and not on Unter den
Linden.

See you on Friday at c-base!

GNU Emacs Developers Will Fix It; Please Calm Down

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/07/29/emacs.html

fabsh was the first to
point me at a
slashdot
story that is (like most slashdot stories) sensationalized.

The story, IMO, makes the usual mistake of considering a
GPL violation as an
earth-shattering disaster that has breached the future of software
freedom. GPL
violations vary in degree of the problems they create; most aren’t
earth-shattering.

Specifically, the slashdot story points
to a
thread on the emacs-devel mailing list about a failure to include
some needed bison grammar in the complete and corresponding sources
for Emacs in a few
Emacs releases in the last year or two. As you can see there,
RMS quickly
responded to
call it a grave problem … [both] legally and
ethically, and
he’s asked
the Emacs developers to help clear up the problem quickly.

I wrote nearly two years ago
that one
shouldn’t jump to conclusions and start condemning those who violate the
GPL without investigating further first. Most GPL violations are
mistakes, as this situation clearly was, and I suspect
it will be resolved within a few news cycles of this blog post.

And please, while we all see the snickering-inducing irony of
FSF and its
GNU project violating the GPL, keep in
mind that this is what I’ve typically called a “community
violation”. It’s a non-profit volunteer project that made an
honest mistake and is resolving it quickly. Meanwhile, I’ve a list of
hundreds of companies who are actively violating the GPL, ignoring users
who requested source, and have apparently no interest in doing the right
thing until I open an enforcement action against them. So, please keep
perspective about what how bad any given violation is. Not all GPL
violations are of equal gravity, but all should be resolved, of course.
The Emacs developers are on it.

еКниги

Post Syndicated from RealEnder original https://alex.stanev.org/blog/?p=288

Преди няколко месеца взех назаем електронен четец PocketBook 360 и просто се влюбих в него. Успях за кратко време да наваксам с четенето, много е зарибяващо. В края на краищата се сдобих и с Kindle 3, който обаче не вдява от човешки формати на електронните книги. С помощта на Calibre този проблем се решава лесно, но човешката алчност край няма – исках с няколко клика през програмата да намеря интересуващата ме книга и да я кача на четеца във формат, разбираем от него. Разгледах кода на Calibre и след малко натъманяване вече имах готови разширения, позволяващи търсенето в chitanka.info и e-knigi.net. От последната версия на Calibre 0.8.11, търсачката в chitanka.info  вече е “заводски” интегрирана и можете да я свалите от тук.

Ако някой се сеща какво още му липсва или има други идеи за Calibre, да пише смело, докато още ми се занимава с python 🙂

Desktop Summit Announcements

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/desktop-summit-announce.html

In case you missed them, there have been a couple of exciting announcements
around the Desktop Summit in Berlin, Germany.

And there will be more exciting announcements coming!

See you in 14 days! Oh, and if you still haven’t registered, do so now. It’s free, and if you don’t register you might not get on the WLAN at the conference right-away.

systemd for Administrators, Part IX

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/on-etc-sysinit.html

Here’s the ninth installment
of
my
ongoing
series
on
systemd
for
Administrators:

On /etc/sysconfig and /etc/default

So, here’s a bit of an opinion piece on the /etc/sysconfig/ and
/etc/default directories that exist on the various distributions in
one form or another, and why I believe their use should be faded out. Like
everything I say on this blog what follows is just my personal opinion, and not
the gospel and has nothing to do with the position of the Fedora project or my
employer. The topic of /etc/sysconfig has been coming up in
discussions over and over again. I hope with this blog story I can explain a
bit what we as systemd upstream think about these files.

A few lines about the historical context: I wasn’t around when
/etc/sysconfig was introduced — suffice to say it has been around on Red Hat
and SUSE distributions since a long long time. Eventually /etc/default was
introduced on Debian with very similar semantics. Many other distributions know
a directory with similar semantics too, most of them call it either one or the
other way. In fact, even other Unix-OSes sported a directory like this. (Such
as SCO. If you are interested in the details, I am sure a Unix greybeard of
your trust can fill in what I am leaving vague here.) So, even though a
directory like this has been known widely on Linuxes and Unixes, it never has
been standardized, neither in POSIX nor in LSB/FHS. These directories very much
are something where distributions distuingish themselves from each other.

The semantics of /etc/default and /etc/sysconfig are very
losely defined only. What almost all files stored in these directories have in common
though is that they are sourcable shell scripts which primarily consist of
environment variable assignments. Most of the files in these directories are
sourced by the SysV init scripts of the same name. The Debian
Policy Manual (9.3.2) and the Fedora Packaging
Guidelines suggest this use of the directories, however both distributions
also have files in them that do not follow this scheme, i.e. that do not have a
matching SysV init script — or not even are shell scripts at all.

Why have these files been introduced? On SysV systems services are started
via init scripts in /etc/rc.d/init.d (or a similar directory).
/etc/ is (these days) considered the place where system configuration
is stored. Originally these init scripts were subject to customization by the
administrator. But as they grew and become complex most distributions no longer
considered them true configuration files, but more just a special kind of programs.
To make customization easy and guarantee a safe upgrade path the customizable
bits hence have been moved to separate configuration files, which the init
scripts then source.

Let’s have a quick look what kind of configuration you can do with these
files. Here’s a short incomprehensive list of various things that can be
configured via environment settings in these source files I found browsing
through the directories on a Fedora and a Debian machine:

  • Additional command line parameters for the daemon binaries
  • Locale settings for a daemon
  • Shutdown time-out for a daemon
  • Shutdown mode for a daemon
  • System configuration like system locale, time zone information, console keyboard
  • Redundant system configuration, like whether the RTC is in local timezone
  • Firewall configuration data, not in shell format (!)
  • CPU affinity for a daemon
  • Settings unrelated to boot, for example including information how to install a new kernel package, how to configure nspluginwrap or whether to do library prelinking
  • Whether a specific service should be started or not
  • Networking configuration
  • Which kernel modules to statically load
  • Whether to halt or power-off on shutdown
  • Access modes for device nodes (!)
  • A description string for the SysV service (!)
  • The user/group ID, umask to run specific daemons as
  • Resource limits to set for a specific daemon
  • OOM adjustment to set for a specific daemon

Now, let’s go where the beef is: what’s wrong with /etc/sysconfig
(resp. /etc/default)? Why might it make sense to fade out use of these
files in a systemd world?

  • For the majority of these files the reason for having them simply does not
    exist anymore: systemd unit files are not programs like SysV init scripts
    were. Unit files are simple, declarative descriptions, that usually do not consist of more
    than 6 lines or so. They can easily be generated, parsed without a Bourne
    interpreter and understood by the reader. Also, they are very easy to modify:
    just copy them from /lib/systemd/system to
    /etc/systemd/system and edit them there, where they will not be
    modified by the package manager. The need to separate code and configuration
    that was the original reason to introduce these files does not exist anymore,
    as systemd unit files do not include code. These files hence now are a solution
    looking for a problem that no longer exists.
  • They are inherently distribution-specific. With systemd we hope to encourage
    standardization between distributions. Part of this is that we want that unit files are
    supplied with upstream, and not just added by the packager — how it has usually
    been done in the SysV world. Since the location of the directory and the
    available variables in the files is very different on each distribution,
    supporting /etc/sysconfig files in upstream unit files is not
    feasible. Configuration stored in these files works against de-balkanization of
    the Linux platform.
  • Many settings are fully redundant in a systemd world. For example, various
    services support configuration of the process credentials like the user/group
    ID, resource limits, CPU affinity or the OOM adjustment settings. However, these settings are
    supported only by some SysV init scripts, and often have different names if
    supported in multiple of them. OTOH in systemd, all these settings are
    available equally and uniformly for all services, with the same configuration
    option in unit files.
  • Unit files know a large number of easy-to-use process context settings,
    that are more comprehensive than what most /etc/sysconfig files offer.
  • A number of these settings are entirely questionnabe. For example, the
    aforementiond configuration option for the user/group ID a service runs as is
    primarily something the distributor has to take care of. There is little to win
    for administrators to change these settings, and only the distributor has the
    broad overview to make sure that UID/GID and name collisions do not
    happen.
  • The file format is not ideal. Since the files are usually sourced as shell
    scripts, parse errors are very hard to decypher and are not logged along the
    other configuration problems of the services. Generally, unknown variable
    assignments simply have no effect but this is not warned about. This makes
    these files harder to debug than necessary.
  • Configuration files sources from shell scripts are subject to the execution
    parameters of the interpreter, and it has many: settings like IFS or LANG tend
    to modify drastically how shell scripts are parsed and understood. This makes
    them fragile.
  • Interpretation of these files is slow, since it requires spawning of a
    shell, which adds at least one process for each service to be spawned at boot.
  • Often, files in /etc/sysconfig are used to “fake” configuration
    files for daemons which do not support configuration files natively. This is
    done by glueing together command line arguments from these variable assignments
    that are then passed to the daemon. In general proper, native configuration
    files in these daemons are the much prettier solution however. Command line
    options like “-k”, “-a” or “-f” are not self-explanatory and have a very
    cryptic syntax. Moreover the same switches in many daemons have (due to the
    limited vocabulary) often very much contradicting effects. (On one daemon
    -f might cause the daemon to daemonize, while on another one this
    option turns exactly this behaviour off.) Command lines generally cannot include
    sensible comments which most configuration files however can.
  • A number of configuration settings in /etc/sysconfig are entirely
    redundant: for example, on many distributions it can be controlled via
    /etc/sysconfig files whether the RTC is in UTC or local time. Such an
    option already exists however in the 3rd line of the /etc/adjtime
    (which is known on all distributions). Adding a second, redundant,
    distribution-specific option overriding this is hence needless and complicates
    things for no benefit.
  • Many of the configuration settings in /etc/sysconfig allow
    disabling services. By this they basically become a second level of
    enabling/disabling over what the init system already offers: when a service is
    enabled with systemctl enable or chkconfig on these settings
    override this, and turn the daemon of even though the init system was
    configured to start it. This of course is very confusing to the
    user/administrator, and brings virtually no benefit.
  • For options like the configuration of static kernel modules to load: there
    are nowadays usually much better ways to load kernel modules at boot. For
    example, most modules may now be autoloaded by udev when the right hardware is
    found. This goes very far, and even includes ACPI and other high-level
    technologies. One of the very few exceptions where we currently do not do
    kernel module autoloading is CPU feature and model based autoloading which
    however will be supported soon too. And even if your specific module cannot be
    auto-loaded there’s usually a better way to statically load it, for example by
    sticking it in /etc/load-modules.d so that the administrator can check
    a standardized place for all statically loaded modules.
  • Last but not least, /etc already is intended to be the place for system
    configuration (“Host-specific system configuration” according to FHS). A
    subdirectory beneath it called sysconfig to place system configuration
    in is hence entirely redundant, already on the language level.

What to use instead? Here are a few recommendations of what to do with these
files in the long run in a systemd world:

  • Just drop them without replacement. If they are fully redundant (like the
    local/UTC RTC setting) this is should be a relatively easy way out (well,
    ignoring the need for compatibility). If systemd natively supports an
    equivalent option in the unit files there is no need to duplicate these
    settings in sysconfig files. For a list of execution options you may
    set for a service check out the respective man pages: systemd.exec(5)
    and systemd.service(5).
    If your setting simply adds another layer where a service can be disabled,
    remove it to keep things simple. There’s no need to have multiple ways to
    disable a service.
  • Find a better place for them. For configuration of the system locale or
    system timezone we hope to gently push distributions into the right direction,
    for more details see previous
    episode of this series    .
  • Turn these settings into native settings of the daemon. If necessary add
    support for reading native configuration files to the daemon. Thankfully, most
    of the stuff we run on Linux is Free Software, so this can relatively easily be
    done.

Of course, there’s one very good reason for supporting these files for a bit
longer: compatibility for upgrades. But that’s is really the only one I could
come up with. It’s reason enough to keep compatibility for a while, but I think
it is a good idea to phase out usage of these files at least in new packages.

If compatibility is important, then systemd will still allow you to read
these configuration files even if you otherwise use native systemd unit files.
If your sysconfig file only knows simple options
EnvironmentFile=-/etc/sysconfig/foobar (See systemd.exec(5) for more information about this option.) may be used to import the
settings into the environment and use them to put together command lines. If
you need a programming language to make sense of these settings, then use a
programming language like shell. For example, place an short shell script in
/usr/lib/<your package>/ which reads these files for
compatibility, and then exec‘s the actual daemon binary. Then spawn
this script instead of the actual daemon binary with ExecStart= in the
unit file.

And this is all for now. Thank you very much
for your interest.

Wake up!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/ds-wake-up-call.html

If you plan to attend Desktop Summit in Berlin this year, then please REGISTER NOW!

If you do not register, then this means you will have to wait in the signup
queue at the conference for substantially longer and might miss a talk or two.
You will not get onto the conference WLAN right from the beginning of
the conference (access is authenticated and personalized, only people who sign
up will get access credentials). Your personal badge will not be ready
right-away. If not enough people register we will also have to cut down on
the available catering and the parties. We rely on the registration numbers
to plan, and if you come but don’t sign up before you make it very hard for us
to plan. Registration is free, so what are you waiting for?

I am pretty sure you want to avoid all of this right? For your own benefit
and for the benefit of everybody else attending the conference, go and register
for the conference right-away!

Also, we are still looking for more volunteers for session chairs and
runners at the conference. This is your chance to introduce your favourite Open
Source hacker on stage! Please consider volunteering and read the Call for
Volunteers. Add yourself to the list on the wiki page,
today. If you sign up you’ll earn yourself the gratitude of the GNOME and KDE
communities, and you’ll receive the exclusive team T-shirts!

Thank you!

Project Harmony (and “Next Generation Contributor Agreements”) Considered Harmful

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html

Update on 2014-06-10:While this article is about a
specific series of attempts to “unify”
CLAs and
©AAs into a
single set of documents, the issues raised below cover the gamut of
problems that are encountered in many CLAs and ©AAs in common use
today in
FLOSS
projects. Even though it appears that both Project Harmony and its
reincarnation Next Generation Contributor Agreements have both failed, CLAs
and ©AAs are increasing in popularity among FLOSS projects, and
developers should begin action to oppose these agreements for their
projects.

Update on 2013-09-05: Project Harmony was recently
relaunched under the name the Next Generation of Contributor
Agreements. AFAICT, it’s
been publicly
identified as the same initiative, and
its
funding comes from the same person. I’ve verified that everything I say below still
applies to their current drafts available from the Contributor
Agreements project. I also emailed this comments to the leaders of
that project before it started, but they wouldn’t respond to my policy
questions.

Much advertising is designed to convince us to buy or use of
something that we don’t need. When I hear someone droning on about some
new, wonderful thing, I have to worry that these folks are actually
trying to market something to me.

Very soon, you’re likely to see a marketing blitz for this thing
called Project Harmony (which just released its 1.0 version
of document templates). Even the name itself is marketing: it’s not
actually descriptive, but is so named to market a “good
feeling” about the project before even knowing what it is. (It’s
also
got serious namespace collision,
including with a project already in
the software freedom community.)

Project Harmony markets itself as fixing something that our community
doesn’t really consider broken. Project Harmony is a set of document
templates, primarily promulgated and mostly drafted by corporate
lawyers, that entice developers to give control of their software work
over to companies.

My analysis below is primarily about how these agreements are
problematic for individual developers. An analysis of the agreements in
light of companies or organizations using them between each other may
have the same or different conclusions; I just haven’t done that
analysis in detail so I don’t know what the outcome is.

[ BTW, I’m aware that I’ve failed to provide a
TL;DR version of this article.
I tried twice to write one and ultimately decided that I can’t. Simply
put, these issues are complex, and I had to draw on a decade of software
freedom licensing, policy, and organizational knowledge to fully
articulate what’s wrong with the Project Harmony agreements. I realize that sounds
like a It was hard to write — it should be hard to read
justification, but I just don’t know how to summarize these
Gordian problems in a pithy way. I nevertheless hope developers will
take the time to read this before they sign a Project Harmony agreement,
or — indeed — any CLA or ©AA. ]

Copyright Assignment That Lacks Real Assurances

First of all, about half of Project Harmony is copyright assignment
agreements (
©AAs). Assigning copyright completely gives
the work over to someone else. Once the ©AA is signed, the work
ceases to belong to the assignor. It’s as if that work was done by the
assignee. There is admittedly some value to copyright assignment,
particularly if developers want to ensure that the
GPL or other copyleft is
enforced on their work and they don’t have time to do it themselves.
(Although developers can also designate an enforcement agent to do that on their
behalf even if they don’t assign copyright, so even that necessity is
limited.)

One must immensely trust an assignee organization. Personally, I’ve
only ever assigned some of my copyrights to one organization in my
life: the Free Software Foundation,
because FSF is the
only organization I ever encountered that is institutionally committed
to
DTRT’ing with
copyrights in a manner similar to my personal moral beliefs.

First of
all, as
I’ve written about before, FSF’s ©AA make all sorts of promises
back to the assignor. Second, FSF is institutionally committed
to the GPL and
enforcing GPL in a way
that advances FSF’s non-profit advocacy mission for software freedom.
All of this activity fits my moral principles, so I’ve been willing to
sign FSF’s ©AAs.

Yet, I’ve nevertheless met many developers who refuse to sign
FSF’s ©AAs. While many of such developers like the GPL, they don’t
necessarily agree with the FSF’s moral positions. Indeed, in many
cases, developers are completely opposed to assigning copyright to
anyone, FSF or otherwise. For
example, Linus
Torvalds, founder of Linux, has often stated on record that
he never wanted to do copyright assignments, for several reasons:
[he] think[s] they are nasty and wrong personally, and [he]’d hate all
the paperwork, and [he] thinks it would actually detract from the
development model.

Obviously, my position is not as radical as Linus’; I do think
©AAs can sometimes be appropriate. But, I also believe that
developers should never assign copyright to a company or to an
organization whose moral philosophy doesn’t fit well with their own.

FSF, for its part, spells out its moral position in its ©AA
itself. As
I’ve mentioned elsewhere, and as
Groklaw
recently covered in detail, FSF’s ©AA makes various legally
binding promises to developers who sign it. Meanwhile, Project
Harmony’s ©AAs, while they put forward a few options that look
vaguely acceptable (although they have problems of their own discussed
below), make no such promises mandatory. I have often times pointed
Harmony’s drafters
to the
terms that FSF has proposed should be mandatory in any for-profit
company’s ©AA, but Harmony’s drafters have refused to
incorporate these assurances as a required part of Harmony’s
agreements. (Note that such assurances would still be required for
the CLA options as well; see below for details why.)

Regarding ©AAs, I’d like to note finally that FSF
does not require ©AAs for all
GNU packages.
This confusion is so common that I’d like to draw attention to it, even
thought it’s only a tangential point in this context. FSF’s ©AA is
only mandatory, to my knowledge, on those
GNU packages where either (a)
FSF employees developed the first versions or (b) the original
developers themselves asked to assign copyright to FSF, upon
their project joining GNU. In all other cases, FSF assignment is
optional. Some GNU projects, such
as GNOME, have their
own positions regarding ©AAs that differ radically from FSF’s.
I seriously doubt that companies who adopt Project Harmony’s agreement
will ever be as flexible on copyright assignment as FSF, nor will any of
the possible Project Harmony options be acceptable to GNOME’s existing
policy.

Giving Away Rights to Give Companies Warm Fuzzies?

Project Harmony, however, claims that the important part isn’t its
©AA, but its Contributor License Agreement
(CLA). To
briefly consider the history of Free Software CLAs, note that
the Apache CLA was
likely the first CLA used in the Free Software community. Apache
Software Foundation has always been heavily influenced by IBM and other
companies, and such companies have generally sought the “warm
fuzzies” of getting every contributor to formally assent to a
complex legal document that asserts various assurances about the code
and gives certain powers to the company.

The main point of a CLA (and a somewhat valid one) is to ensure that
the developers have verified their right to contribute the code under
the specified copyright license. Both the Apache CLA and Project
Harmony’s CLA go to great length and verbosity to require developers
to agree that they know the contribution is theirs. In fact, if a
developer signs one of these CLA’s, the developer makes a formal
contract with the entity (usually a for-profit
company) that the developer knows for sure that the contribution is
licensed under the specified license. The developer then takes on all
liability if that fact is in any way incorrect or in dispute!

Of course, shifting away all liability about the origins of the code is
a great big “warm fuzzy” for the company’s lawyers. Those
lawyers know that they can now easily sue an individual
developer for breach of contract if the developer was wrong
about the code. If the company redistributes some developer’s code and
ends up in an infringement suit where the company has to pay millions of
dollars, they can easily come back and sue the
developer0. The company would argue in
court that the developer breached the CLA. If this possible outcome
doesn’t immediately worry you as an individual developer
signing a Project Harmony CLA for your
FLOSS contribution, it should.

“Choice of Law” & Contractual Arrangement Muddies Copyright Claims

Apache’s CLA
doesn’t have a choice of law clause, which is preferable in my opinion.
Most lawyers just love a “choice of law” clause for
various reasons. The biggest reason is that it means the rules that
apply to the agreement are the ones with which the lawyers are most
familiar, and the jurisdiction for disputes will be the local
jurisdiction of the company, not of the developer. In addition, lawyers
often pick particular jurisdictions that are very favorable to their
client and not as favorable to the other signers.

Unfortunately, all of Project Harmony’s drafts include a
“choice of law” clause1. I expect that the drafters will
argue in response that the jurisdiction is a configuration variable.
However, the problem is that the company decides the binding of
that variable, which almost always won’t be the binding that an
individual developer prefers. The term will likely be
non-negotiable at that point, even though it was configurable in the
template.

Not only that, but imagine a much more likely scenario about the CLA:
the company fails to use the outbound license they promised. For
example, suppose they promised the developers it’d be
AGPL‘d forever
(although, no such option actually exists in Project Harmony, as
described below!), but then the company releases proprietarized
versions. The developers who signed the CLA are still copyright
holders, so they can enforce under copyright law, which, by itself,
would allow the developers to enforce under the laws in whatever jurisdiction suits
them (assuming the infringement is happening in that jurisdiction, of
course).

However, by signing a CLA with a “choice of law” clause,
the developers agreed to whatever jurisdiction is stated in that CLA.
The CLA has now turned what would otherwise be a mundane copyright
enforcement action operating purely under the developer’s local copyright law into a contract
dispute between the developers and the company under the chosen
jurisdiction’s laws. Obviously that agreement might include AGPL and/or GPL by reference,
but the claim of copyright infringement due to violation of GPL is now
muddied by the CLA contract that the developers signed, wherein the
developers granted some rights and permission beyond GPL to the
company.

Even worse, if the developer does bring action in a their own
jurisdiction, their own jurisdiction is forced to interpret the laws of
another place. This leads to highly variable and confusing results.

Problems for Individual Copyright Enforcement Against Third-Parties

Furthermore, even though individual developers still hold the
copyrights, the Project Harmony CLAs grant many transferable rights and
permissions to the CLA recipient (again, usually a company).
Even if the reasons for requiring that were noble, it
introduces a bundle of extra permissions that can be passed along to
other entities.

Suddenly, what was once a simple copyright enforcement action for a
developer discovering a copyleft violation becomes a question: Did
this violating entity somehow receive special permissions from the
CLA-collecting entity? Violators will quickly become aware of this
defense. While the defense may not have merit (i.e., the CLA recipient
may not even know the violator), it introduces confusion. Most legal
proceedings involving software are already confusing enough for courts
due to the complex technology involved. Adding something like this will
just cause trouble and delays, further taxing our already minimally
funded community copyleft enforcement efforts.

Inbound=Outbound Is All You Need

Meanwhile, the whole CLA question actually is but one fundamental
consideration: Do we need this? Project Harmony’s answer is clear: its
proponents claim that there is mass confusion about CLAs and no
standardization, and therefore Project Harmony must give a standard set
of agreements that embody all the options that are typically used.

Yet, Project Harmony has purposely refused to offer the simplest and
most popular option of all, which my colleague Richard Fontana (a lawyer
at Red Hat who also opposes Project
Harmony) last year
dubbed inbound=outbound. Specifically, the default agreement
in the overwhelming majority of FLOSS projects is simply this: each
contributor agrees to license each contribution using the project’s
specified copyright license (or a license compatible with the project’s
license).

No matter what way you dice Project Harmony, the other contractual
problems described above make true inbound=outbound impossible because
the CLA recipient is never actually bound formally by the project’s
license itself. Meanwhile, even under its best configuration, Project
Harmony can’t adequately approximate inbound=outbound. Specifically,
Project Harmony attempts to limit outbound licensing with its §
2.3 (called Outbound License). However, all the copyleft
versions of this template include a clause that say: We [the CLA
recipient] agree to license the Contribution … under terms of the
… licenses which We are using on the Submission Date for the
Material. Yet, there is no way for the contributor to
reliably verify what licenses are in use privately by the entity
receiving the CLA. If the entity is already engaged in, for example, a
proprietary
relicensing business model at the Submission Date, then the
contributor grants permission for such relicensing on the new
contribution, even if the rest of § 2.3 promises copyleft. This is
not a hypothetical: there have been many cases where it was unclear
whether or not a company was engaged in proprietary relicensing, and
then later it was discovered that they had been privately doing so for
years. As written, therefore, every configuration of Project Harmony’s
§ 2.3 is useless to prevent proprietarization.

Even if that bug were fixed, the closest Project Harmony gets to
inbound=outbound is restricting the CLA version to “FSF’s list of
‘recommended copyleft licenses’”. However, this
category makes no distinction between
the AGPL and GPL,
and furthermore ultimately grants FSF power over relicensing (as FSF can
change its
list of recommended copylefts at will). If the contributors are
serious about the AGPL, then Project Harmony cannot
assure their changes stay AGPL’d. Furthermore,
contributors must trust the FSF for perpetuity, even more
than already needed in the -or-later options in the existing
FSF-authored licenses. I’m all for trusting the FSF myself in most
cases. However, because I prefer plain AGPLv3-or-later for my code,
Project Harmony is completely unable to accommodate my licensing
preferences to even approximate an AGPL version of inbound=outbound
(even if I ignored the numerous problems already discussed).

Meanwhile, the normal, mundane, and already widely used
inbound=outbound practice is simple, effective, and doesn’t mix in
complicated contract disputes and control structures with the project’s
governance. In essence, for most FLOSS projects, the copyright license
of the project serves as the Constitution of the project, and doesn’t
mix in any other complications. Project Harmony seeks to give warm
fuzzies to lawyers at the expense of offloading liability, annoyance,
and extra hoop-jumping onto developers.

Linux Hackers Ingeniously Trailblazed inbound=outbound

Almost exactly 10 years ago today, I recall distinctly attending
the USENIX
2001 Linux BoF
session. At that session, Ted Ts’o
and I had a rather lively debate; I claimed that FSF’s ©AA assured
legal certainty of the GNU codebase, but that Linux had no such
assurance. (BTW, even I was confused in those days and thought
all GNU packages required FSF’s ©AA.) Ted explained, in his usual
clear and bright manner, that such heavy-handed methods shouldn’t be
needed to give legal certainty to the GPL and that the Linux community
wanted to find an alternative.

I walked away skeptically shaking my head. I remember thinking: Ted
just doesn’t get it. But I was wrong; he did get it. In
fact, many of the core Linux developers did. Three years to the month
after that public conversation with
Ted, the
Developer’s Certificate of Origin (DCO) became the official required
way to handle the “CLA issue” for Linux and
it remains
the policy of Linux today. (See item 12 in Linux’s
Documentation/SubmittingPatches file.)

The DCO,
in fact, is the only CLA any FLOSS project ever needs! It implements
inbound=outbound in a simple and straightforward way, without giving
special powers over to any particular company or entity. Developers
keep their own copyright and they unilaterally attest to their right to
contribute and the license of the contribution. (Developers can even
sign a ©AA with some other entity, such as the FSF, if they wish.)
The DCO also gives a simple methodology (i.e.,
the Signed-off-by: tag) for developers to so attest.

I admit that I once scoffed at the (what I then considered
naïve) simplicity of the DCO when compared to FSF’s ©AA.
Yet, I’ve been since convinced that the Linux DCO clearly accomplishes
the primary job and simultaneously fits how most developers like to
work. ©AA’s have their place, particularly when the developers
find a trusted organization that aligns with their personal moral code
and will enforce copyleft for them. However, for CLAs, the Linux DCO
gets the important job done and tosses aside the pointless and
pro-corporate stuff.

Frankly, if I have to choose between making things easy for developers
and making them easy for corporate lawyers, I’m going to chose the
former every time: developers actually write the code; while, most of
the time, company’s legal departments just get in our way. The FLOSS
community needs just enough
CYA stuff to get by; the DCO
shows what’s actually necessary, as opposed to what corporate
attorneys wish they could get developers to do.

What about Relicensing?

Admittedly, Linux’s DCO does not allow for relicensing wholesale of the
code by some single entity; it’s indeed the reason a Linux switch to GPLv3
will be an arduous task of public processes to ensure permission to make
the change. However, it’s important to note that the Linux
culture believes in GPLv2-only as a moral foundation and
principle of their community. It’s not a principle I espouse; most of my
readers know
that my
preferred software license is AGPLv3-or-later. However, that’s the
point here: inbound=outbound is the way a FLOSS community
implements their morality; Project Harmony seeks to remove community
license decision-making from most projects.

Meanwhile, I’m all for the “-or-later” brand of relicensing
permission; GPL, LGPL and AGPL have left this as an option for community
choice since GPLv1 was
published in late 1980s. Projects declare
themselves GPLv2-or-later or LGPLv3-or-later, or
even (GPLv1-or-later|Artistic)
(ala Perl 5) to identify their culture and relicensing permissions.
While it would sometimes be nice to have a broad post-hoc relicensing
authority, the price for that’s expensive: abandonment of community
clarity regarding what terms define their software development
culture.

An Anti-Strong-Copyleft Bias?

Even worse, Project Harmony remains biased against some of the more
fine-grained versions of copyleft culture. For
example, Allison
Randal, who is heavily involved with Project Harmony, argued
on Linux
Outlaws Episode 204 that Most developers who contribute
under a copyleft license — they’d be happy with any copyleft
license — AGPL, GPL, LGPL. Yet there
are well
stated reasons why developers might pick GPL rather than LGPL.
Thus, giving a for-profit company (or non-profit that doesn’t
necessarily share the developers’ values) unilateral decision-making
power to relicense GPL’d works under LGPL or other weak copyleft
licenses is ludicrous.

In its 1.0 release, Project Harmony attempted to add a “strong
copyleft only” option. It doesn’t actually work, of course, for
the various reasons discussed in detail above. But even so, this
solution is just one option among many, and is not required as a default
when a project is otherwise copylefted.

Finally, it’s important to realize that
the GPLv3,
AGPLv3, and LGPLv3 already offer a “proxy option”; projects
can name someone to decide the -or-later question at a later time.
So, for those projects that use any of the set { LGPLv3-only,
AGPLv3-only, GPLv3-only, GPLv2-or-later, GPLv1-or-later, or
LGPLv2.1-or-later }, the developers already have mechanisms to
move to later versions of the license with ease — by specifying a
proxy. There is no need for a CLA to accomplish that task in the GPL
family of licenses, unless the goal is to erode stronger copylefts into
weaker copylefts.

This is No Creative Commons, But Even If It Were, Is It Worth
Emulation?

Project Harmony’s proponents love to compare the project
to Creative Commons, but the
comparison isn’t particularly apt. Furthermore, I’m not convinced the
FLOSS community should emulate the
CC license suite wholesale,
as some of the aspects of the CC structure are problematic when imported
back into FLOSS licensing.

First of
all, Larry
Lessig (who is widely considered a visionary) started the CC
licensing suite to bootstrap a Free Culture movement that modeled on the
software freedom movement (which he spent a decade studying). However,
Lessig made some moral compromises in an attempt to build a bridge to
the “some rights reserved” mentality. As such, many of the
CC licenses — notably those that include the non-commercial (NC)
or no-derivatives (ND) terms — are considered overly restrictive
of freedom and are
therefore shunned
by Free Culture activists
and
software freedom advocates alike.

Over nearly decade, such advocates have slowly begun to convince
copyright holders to avoid CC’s NC and ND options, but CC’s own
continued promulgation of those options lend them undue legitimacy.
Thus, CC and Project Harmony make the same mistake: they act amorally in
an attempt to build a structure of licenses/agreements that tries to
bridge a gulf in understanding between a
FaiF community and those
only barely dipping their toe in that community. I chose the word
amoral, as
I often do, to note a situation where important moral principles
exist, but the primary actors involved seek to remove morality from the
considerations under the guise of leaving decision-making to the
“magic of the marketplace”. Project Harmony is repeating
the mistake of the CC license suite that the Free Culture community has
spent a decade (and counting) cleaning up.

Conclusions

Please note that IANAL and
TINLA. I’m just a
community- and individual-developer- focused software freedom policy
wonk who has some grave concerns about how these Project Harmony
Agreements operate. I can’t give you a fine-grained legal analysis,
because I’m frankly only an amateur when it comes to the law, but
I am an expert in software freedom project policy. In that
vein — corporate attorney endorsements notwithstanding — my
opinion is that Project Harmony should be abandoned entirely.

In fact, the distinction between policy and legal expertise actually
shows the root of the problem with Project Harmony. It’s a system of
documents designed by a committee primarily comprised of corporate
attorneys, yet it’s offered up as if it’s a FLOSS developer consensus.
Indeed, Project Harmony itself was initiated
by Amanda
Brock, a for-profit corporate attorney for Canonical, Ltd, who is
remains involved in its
drafting. Canonical,
Ltd. later hired Mark Radcliffe (a big law firm attorney,
who has
defended
GPL violators)
to draft the alpha revisions of the document, and Radcliffe remains
involved in the process. Furthermore, the primary drafting process was
done secretly in closed meetings dominated by corporate attorneys
until the documents were almost complete; the process was not made
publicly open to the FLOSS community until April 2011. The 1.0
documents differ little from the drafts that were released in April
2011, and thus remain to this day primarily documents drafted in secrecy
by corporate attorneys who have only a passing familiarity with software
freedom culture.

Meanwhile,
I’ve asked
Project Harmony’s advocates many times who is in charge of Project
Harmony now, and no one can give me a straight answer. One is left to
wonder who decides final draft approval and what process exists to
prevent or permit text for the drafts. The process which once was in
secrecy appears to be now in chaos because it was opened up too late for
fundamental problems to be resolved.

A few developers are indeed actively involved in Project Harmony. But
Project Harmony is not something that most developers requested; it was
initiated by companies who would like to convince developers to
passively adopt overreaching CLAs and ©AAs. To me, the whole
Project Harmony process feels like a war of attrition to convince
developers to accept something that they don’t necessarily want with
minimal dissent. In short, the need for Project Harmony has not been
fully articulated to developers.

Finally, I ask, what’s really broken here? The industry has been
steadily and widely adopting GNU and Linux for years. GNU, for its
part, has FSF assignments in place for much of its earlier projects, but
the later projects
(GNOME,
in particular) have either been against both ©AA’s and CLA’s
entirely, or are mostly indifferent to them and use inbound=outbound.
Linux, for its part, uses the DCO, which does the job of handling the
urgent and important parts of a CLA without getting in developers’ way
and without otherwise forcing extra liabilities onto the developers and
handing over important licensing decisions (including copyleft weakening
ones) to a single (usually for-profit) entity.

In short, Project Harmony is a design-flawed solution looking for a
problem.

Further Reading

0Project Harmony
advocates will likely claim to their § 5, “Consequential Damage
Waiver” protects developers adequately. I note that it
explicitly leaves out, for example, statutory damages for copyright
infringement. Also, some types of damages cannot be waived (which is why
that section shouts at the reader TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW). Note my discussion of jurisdictions in the main text
of this article, and consider
the fact that the CLA recipient will obviously select a jurisdiction where
the fewest possible damages can be waived. Finally, note that the OR
US part of that § 5 is optionally available, and surely corporate
attorneys will use it, which means that if they violate the agreement,
there’s basically no way for you to get any damages from them, even if
they their promise to keep the code copylefted and fail.

1Note:
Earlier versions of this blog post conflated slightly “choice of
venue” with “choice of law”. The wording has been
cleared up to address this problem. Please comment or email me if you
believe it’s not adequately corrected.

systemd for Developers II

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

It has been way too long since I posted the first
episode of my systemd for Developers series. Here’s finally the
second part. Make sure you read the first episode of the series before
you start with this part since I’ll assume the reader grokked the wonders
of socket activation.

Socket Activation, Part II

This time we’ll focus on adding socket activation support to real-life
software, more specifically the CUPS printing server. Most current Linux
desktops run CUPS by default these days, since printing is so basic that it’s a
must have, and must just work when the user needs it. However, most desktop
CUPS installations probably don’t actually see more than a handful of print
jobs each month. Even if you are a busy office worker you’ll unlikely to
generate more than a couple of print jobs an hour on your PC. Also, printing is
not time critical. Whether a job takes 50ms or 100ms until it reaches the
printer matters little. As long as it is less than a few seconds the user
probably won’t notice. Finally, printers are usually peripheral hardware: they
aren’t built into your laptop, and you don’t always carry them around plugged
in. That all together makes CUPS a perfect candidate for lazy activation:
instead of starting it unconditionally at boot we just start it on-demand, when
it is needed. That way we can save resources, at boot and at runtime. However,
this kind of activation needs to take place transparently, so that the user
doesn’t notice that the print server was not actually running yet when he tried
to access it. To achieve that we need to make sure that the print server is
started as soon at least one of three conditions hold:

  1. A local client tries to talk to the print server, for example because
    a GNOME application opened the printing dialog which tries to enumerate
    available printers.
  2. A printer is being plugged in locally, and it should be configured and
    enabled and then optionally the user be informed about it.
  3. At boot, when there’s still an unprinted print job lurking in the queue.

Of course, the desktop is not the only place where CUPS is used. CUPS can be
run in small and big print servers, too. In that case the amount of print jobs
is substantially higher, and CUPS should be started right away at boot. That
means that (optionally) we still want to start CUPS unconditionally at boot and
not delay its execution until when it is needed.

Putting this all together we need four kind of activation to make CUPS work
well in all situations at minimal resource usage: socket based activation (to
support condition 1 above), hardware based activation (to support condition 2),
path based activation (for condition 3) and finally boot-time activation (for
the optional server usecase). Let’s focus on these kinds of activation in more
detail, and in particular on socket-based activation.

Socket Activation in Detail

To implement socket-based activation in CUPS we need to make sure that when
sockets are passed from systemd these are used to listen on instead of binding
them directly in the CUPS source code. Fortunately this is relatively easy to
do in the CUPS sources, since it already supports launchd-style socket
activation, as it is used on MacOS X (note that CUPS is nowadays an Apple
project). That means the code already has all the necessary hooks to add
systemd-style socket activation with minimal work.

To begin with our patching session we check out the CUPS sources.
Unfortunately CUPS is still stuck in unhappy Subversion country and not using
git yet. In order to simplify our patching work our first step is to use
git-svn to check it out locally in a way we can access it with the
usual git tools:

git svn clone http://svn.easysw.com/public/cups/trunk/ cups

This will take a while. After the command finished we use the wonderful
git grep to look for all occurences of the word “launchd”, since
that’s probably where we need to add the systemd support too. This reveals scheduler/main.c
as main source file which implements launchd interaction.

Browsing through this file we notice that two functions are primarily
responsible for interfacing with launchd, the appropriately named
launchd_checkin() and launchd_checkout() functions. The
former acquires the sockets from launchd when the daemon starts up, the latter
terminates communication with launchd and is called when the daemon shuts down.
systemd’s socket activation interfaces are much simpler than those of launchd.
Due to that we only need an equivalent of the launchd_checkin() call,
and do not need a checkout function. Our own function
systemd_checkin() can be implemented very similar to
launchd_checkin(): we look at the sockets we got passed and try to map
them to the ones configured in the CUPS configuration. If we got more sockets
passed than configured in CUPS we implicitly add configuration for them. If the
CUPS configuration includes definitions for more listening sockets those will
be bound natively in CUPS. That way we’ll very robustly listen on all ports
that are listed in either systemd or CUPS configuration.

Our function systemd_checkin() uses sd_listen_fds() from
sd-daemon.c to acquire the file descriptors. Then, we use
sd_is_socket() to map the sockets to the right listening configuration
of CUPS, in a loop for each passed socket. The loop corresponds very closely to
the loop from launchd_checkin() however is a lot simpler. Our patch so far looks like this.

Before we can test our patch, we add sd-daemon.c
and sd-daemon.h
as drop-in files to the package, so that sd_listen_fds() and
sd_is_socket() are available for use. After a few minimal changes to
the Makefile we are almost ready to test our socket activated version
of CUPS. The last missing step is creating two unit files for CUPS, one for the
socket (cups.socket), the
other for the service (cups.service). To make things
simple we just drop them in /etc/systemd/system and make sure systemd
knows about them, with systemctl daemon-reload.

Now we are ready to test our little patch: we start the socket with
systemctl start cups.socket. This will bind the socket, but won’t
start CUPS yet. Next, we simply invoke lpq to test whether CUPS is
transparently started, and yupp, this is exactly what happens. We’ll get the
normal output from lpq as if we had started CUPS at boot already, and
if we then check with systemctl status cups.service we see that CUPS
was automatically spawned by our invocation of lpq. Our test
succeeded, socket activation worked!

Hardware Activation in Detail

The next trigger is hardware activation: we want to make sure that CUPS is
automatically started as soon as a local printer is found, regardless whether
that happens as hotplug during runtime or as coldplug during
boot. Hardware activation in systemd is done via udev rules. Any udev device
that is tagged with the systemd tag can pull in units as needed via
the SYSTEMD_WANTS= environment variable. In the case of CUPS we don’t
even have to add our own udev rule to the mix, we can simply hook into what
systemd already does out-of-the-box with rules shipped upstream. More
specifically, it ships a udev rules file with the following lines:

SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"
SUBSYSTEM=="usb", KERNEL=="lp*", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"

This pulls in the target unit printer.target as soon as at least
one printer is plugged in (supporting all kinds of printer ports). All we now
have to do is make sure that our CUPS service is pulled in by
printer.target and we are done. By placing WantedBy=printer.target
 line in the [Install] section of the service file, a
Wants dependency is created from printer.target to
cups.service as soon as the latter is enabled with systemctl
enable. The indirection via printer.target provides us with a
simple way to use systemctl enable and systemctl disable to
manage hardware activation of a service.

Path-based Activation in Detail

To ensure that CUPS is also started when there is a print job still queued
in the printing spool, we write a simple cups.path that
activates CUPS as soon as we find a file in /var/spool/cups.

Boot-based Activation in Detail

Well, starting services on boot is obviously the most boring and well-known
way to spawn a service. This entire excercise was about making this unnecessary,
but we still need to support it for explicit print server machines. Since those
are probably the exception and not the common case we do not enable this kind
of activation by default, but leave it to the administrator to add it in when
he deems it necessary, with a simple command (ln -s
/lib/systemd/system/cups.service
/etc/systemd/system/multi-user.target.wants/ to be precise).

So, now we have covered all four kinds of activation. To finalize our patch
we have a closer look at the [Install] section of cups.service, i.e.
the part of the unit file that controls how systemctl enable
cups.service and systemctl disable cups.service will hook the
service into/unhook the service from the system. Since we don’t want to start
cups at boot we do not place WantedBy=multi-user.target in it like we
would do for those services. Instead we just place an Also= line that
makes sure that cups.path and cups.socket are
automatically also enabled if the user asks to enable cups.service
(they are enabled according to the [Install] sections in those unit
files).

As last step we then integrate our work into the build system. In contrast
to SysV init scripts systemd unit files are supposed to be distribution
independent. Hence it is a good idea to include them in the upstream tarball.
Unfortunately CUPS doesn’t use Automake, but Autoconf with a set of handwritten
Makefiles. This requires a bit more work to get our additions integrated, but
is not too difficult either. And
this is how our final patch looks like, after we commited our work and ran
git format-patch -1 on it to generate a pretty git patch.

The next step of course is to get this patch integrated into the upstream
and Fedora packages (or whatever other distribution floats your boat). To make
this easy I have prepared a
patch for Tim that makes the necessary packaging changes for Fedora 16, and
includes the patch intended for upstream linked above. Of course, ideally the
patch is merged upstream, however in the meantime we can already include it in
the Fedora packages.

Note that CUPS was particularly easy to patch since it already supported
launchd-style activation, patching a service that doesn’t support that yet is
only marginally more difficult. (Oh, and we have no plans to offer the complex
launchd API as compatibility kludge on Linux. It simply doesn’t translate very
well, so don’t even ask… ;-))

And that finishes our little blog story. I hope this quick walkthrough how to add
socket activation (and the other forms of activation) to a package were
interesting to you, and will help you doing the same for your own packages. If you
have questions, our IRC channel #systemd on freenode and
our mailing
list are available, and we are always happy to help!

Identi.ca Weekly Summary

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/07/04/identica-weekly.html

Identi.ca Summary, 2011-06-26 through 2011-07-04

What’s This “…And the Rest” Crap!?!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/28/gilligans-island.html

Famously,
the Gilligan’s
Island theme song, in its first season, left out mentioning
the Professor and Mary Ann characters by name, simply including
…And the Rest in that lyric where their names later
were heard. Mystery Science Theater 3000 even spoofed this issue
during
screening of This Island Earth, in which the
actor Russell
Johnson (The Professor) appeared. When Johnson first appears on
screen while viewing This Island Earth, MST3K’s Mike says
over the film: Hey, what’s this …And the Rest
Crap!?!. Indeed, what’s that all about?

Screenshot of MST3K The Movie, watching This Island Earth, as Rusell Johnson appears on screen.

Anyone would get easily annoyed if they’ve contributed some work but,
when credit is giving, they were just relegated into … and the
rest. Anyone who is thrown into that group would assume their contribution
is somehow also not important,
or that the contributions of the credited are somehow better.

Some Free Software projects websites, however, often relegate many of their
contributors to being And the Rest, just like The Professor and
Mary Ann in their first season of Gilligan’s Island. This is a mistake that ought to be
addressed when it occurs.

The example of this problem that was recently brought to my attention
was on Fedora Project’s website.
At the bottom of all of the pages of Fedora’s website,
there’s © 2011 Red Hat, Inc. and others. I’ve dubbed this a
“Gilligan’s Island copyright notice” because, while Red Hat
is probably a copyright holder some of Fedora, Red Hat employees are
also fond of pointing out how many contributors they have from outside
Red Hat. Yet, with regard to the website, those contributors aren’t
considered important enough to appear in the copyright notice. They’re
secondary characters that Red Hat is indicating don’t matter that much:
like The Professor and Mary Ann in Gilligan’s Island‘s first
season.

However, the solution for this problem isn’t completely clear.
Obviously, listing all the copyright holders at the bottom of every web
page is completely unreasonable. In projects themselves, we usually
have a CREDITS or COPYRIGHT file that has everyone’s notice collected,
but rarely is every copyright notice put in the single files of the project. Perhaps
website could do the same. Certainly, Gilligan’s Island copyright
notices can’t continue; they relegate everyone but the main entity into a
supporting character role, when in fact, in Free Software projects,
everyone should be equal.

I’ve been discussing
discussing this issue
on identi.ca lately with Richard Fontana of Red Hat, and
he’s started
a thread on Fedora list about this. I hope that it gets resolved
soon, and I’m grateful to Fontana for addressing this issue.

It’s worth noting that a few examples of other distributions, such
as Debian, Arch
Linux, and Ubuntu, are even worse
in this regard, because they list only a few authors (or a single
corporate entity) that may or may not have all the copyright on the
project and the website; they don’t do the minimal … and the Rest. For example, Debian’s copyright notice
says: Copyright © 1997-2011 SPI. Such notices
are even worse than Gilligan’s Island Copyright Notices,
because they fail to even acknowledge at all that a diversity of
contributors are present and hold copyrights. Note that
there’s
a long-standing
Debian bug on this issue (and the related issue of poor licensing of
the site).

I suppose Gilligan’s Island Copyright Notices are better than marking
the work as an organization’s own when in fact there has been no
assignment of copyright. Still, I think Free Software projects should
take more care on this issue. As is noted in
the GNOME
Foundation Guidelines on Copyright Assignment (which I co-authored),
many developers want to see their “name in lights” under the
copyright notice when they contribute to a project. It’s important that
we give them that opportunity.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close