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

2008-08-16 Bradley M. Kuhn

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.)

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

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

2008-08-16 Bradley M. Kuhn

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

Scott,

2008-08-12 Lennart Poettering

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/apple-development-platform.html

in
contrast to what you say the Apple audio stack (CoreAudio) is far less
streamlined that it might appear on first sight. The different APIs that make
up the Apple audio stack are far more redundant than you might think. Also,
they are different in programming style, and you can list at least as many
seperate components for different areas of audio with different API/naming
styles as you just did for the Linux audio stack.

Listing two components of the Linux audio stack that are considered
obsolete these days, and listing one item twice doesn’t really help making your
post unassailable.

Having said that, yes, our Linux audio stack is still chaotic,
redundant, badly documented and incomplete. You are very welcome to help fixing
this. But just doing a bit PR and sticking a single name on the sum of it all doesn’t
even touch the real problems we have with the audio APIs on Linux.

Free software development is in its very essence distributed. The fact that
our APIs sometimes appear a bit higgledy-piggledy is probably just an
inevitable consequence of this.

String Pools

2008-07-26 Lennart Poettering

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

In part 2.4.3 of Ulrich Drepper’s excellent How To Write Shared
Libraries (which unfortunately is a bit out-of-date these days) Ulrich
suggests replacing arrays of constant strings by a single concatenated string
plus an index lookup table, to avoid unnecessary relocations during startup of
ELF programs. Maintaining this string pool is however troublesome,
it is hard to read and difficult to edit. In appendix B Ulrich
lists an example C excerpt which contains some code for simplifying the
maintaining of such strings pools, after an idea from Bruno Haible. In my
opinion however that suggestion is not that much simpler, and requires
splitting off the actual strings into a seperate source file. Ugly!

Some Free Software uses string pools to speed up relocation, e.g. GTK+.
Some development tools like gperf
contain support for string pools.

All solutions for string pool maintaining I could find on the Internet were not exactly
beautiful. Either they were completely manual, manual plus a validity checking
tool, or very very cumbersome. Googling around I was unable to find a satisfactory tool for this purpose^[1].

After Diego Petteno complained about
my heavy use of arrays of constant strings in libatasmart I sat down to
change the situation, and wrote strpool.c,
a simple parser for a very, very minimal subset of C, written in plain ANSI C.
It looks for two special comment markers /* %STRINGPOOLSTART% */ and
/* %STRINGPOOLSTOP% */, moves all immediate strings between those
markers into a common string pool and rewrites the input with the strings
replaced by indexes. Code accessing those strings must use the
special _P() macro. With these minimal changes to a
source file, passing it through strpool.c will automatically rewrite
it to a string-poolized version. The nice thing about this is that the
necessary changes in the source are minimal, and the code stays compilable with
and without passing it through the strpool.c preprocessor.

Here’s an example. First the original non-string-poolized version:

static const char* const table[] = {
	"waldo",
	"uxknurz",
	"foobar",
	"fubar"
};

static int main(int argc, char* argv[]) {
	printf("%s\n", table[2]);
	return 1;
}

For later use with strpool.c we change this like this:

#ifndef STRPOOL
#define _P(x) x
#endif

/* %STRINGPOOLSTART% */
static const char* const table[] = {
	"waldo",
	"uxknurz",
	"foobar",
	"fubar"
};
/* %STRINGPOOLSTOP% */

static int main(int argc, char* argv[]) {
	printf("%s\n", _P(table[2]));
	return 1;
}

When passed through strpool.c this will be rewritten as:

/* Saved 3 relocations, saved 0 strings (0 b) due to suffix compression. */
static const char _strpool_[] =
	"waldo\0"
	"uxknurz\0"
	"foobar\0"
	"fubar\0";
#ifndef STRPOOL
#define STRPOOL
#endif
#ifndef _P
#define _P(x) (_strpool_ + ((x) - (const char*) 1))
#endif

#ifndef STRPOOL
#define _P(x) x
#endif

/* %STRINGPOOLSTART% */
static const char* const table[] = {
	((const char*) 1),
	((const char*) 7),
	((const char*) 15),
	((const char*) 22)
};
/* %STRINGPOOLSTOP% */

static int main(int argc, char* argv[]) {
	printf("%s\n", _P(table[2]));
	return 1;
}

All three versions can be compiled directly with gcc. However, the version
that was passed through strpool.c compresses the number of
relocations for the table array from 4 to 1. Which isn’t much of a
difference, but the larger your tables are the more relevant the difference in
the number of necessary relocations gets.

A more realistic example is atasmart.c which after being preprocessed with strpool.c looks like this. In this specific example the number of necessary startup relocations goes down from > 100 to 9.

I am note sure if the parser is 100% correct, but it works fine with all sources I tried. It even does suffix compression like gcc does for normal strings too.

Footnotes

[1] Or maybe I just suck in googling? Anyone has a suggestion for such a tool?

PulseAudio 0.9.11 released

2008-07-24 Lennart Poettering

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

I just relased PulseAudio 0.9.11.

It’s an awesome release. To learn more about why, read the linked email, and this and maybe this blog story.

When Will Hosting Sites Allow AGPLv3 Code?

2008-07-23 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/07/23/agplv3-hosting.html

At the OSCON Google Open Source Update, Chris Dibona
reiterated his
requirement to see significant adoption
before code.google.com will host AGPLv3 projects (his
words). I asked him to tell us how tall we in the AGPLv3 community
need to be to ride this ride, but unfortunately he reiterated only
the bar of “significant adoption”. I therefore am
redoubling my efforts to encourage projects to switch to the AGPLv3, and
for our community to build a list of AGPLv3’d projects, so that we can
convince them.

Chris argues that including AGPLv3 would encourage
of license
proliferation. On their surface, his arguments seem to be valid. I don’t
like license proliferation, either. Indeed, I have been a proponent of
reducing license proliferation since around 2000 — long before it was
fashionable, and when the OSI itself was the primary purveyor of license
proliferation. I’m very glad that everyone has gotten on the same page
about this, and would certainly not want to change my position now that
we’ve reached consensus.

However, AGPLv3
is not an example of license proliferation for three reasons. First,
AGPLv3 is a license published by an organization (my old
employers, the FSF) that has a 24 year
history of publishing — indeed, inventing — the
most popular and major licenses available in the FLOSS world. To
compare them to (as some have) Nokia,
who published
merely a vanity license with an OSI rubber stamp is simply not a
valid comparison.

Second, the history of AGPL itself shows that proliferation is not at
work
here. AGPL
was first drafted and published in early 2002, and has been in
constant use since then. It filled a niche for users who were clamoring for a specific license to address a clear concern related to software freedom. I grant that the license is adopted by a small
community, but GPL itself started with minimal interest (i.e., only in
the GNU project). Also, licenses that are “GPL plus various
special exceptions” that deal with tightly confined areas are,
similar to AGPLv3, of interest to only small groups currently. There is
no reason to reject a license that has a strong level of interest in a
small community, particularly if it is — as GPL+exceptions and
AGPLv3 are — compatible with existing licenses like GPLv3. In
these cases, we should understand the reasons its user community picks
it. In the APGLv3 case, the license addresses important FLOSS
principles
under serious study by our community.
Any license that is actually redundant couldn’t pass this test; AGPLv3
can.

Finally, the AGPLv3 is the outcome of a public process in which Google
itself (as well as many others) participated. Indeed, it was the
original intent of the GPLv3 drafters to include the Affero clause in
the GPLv3 itself. The committees (on which Google served) convinced
RMS and other drafters to not include the clause, and that is why it was
put into a separate license. We must consider the fairness issue: some
members of the community asked us to not include the Affero clause in
GPLv3; others wanted it. The parts of the community who didn’t want the
clause should be accepting of the idea that another publicly-audited
license to address this concern should be published for the slighted
community.

Therefore, in this post, I am asking for help: will someone maintain a
website that specifically tracks AGPLv3 adoption (as opposed to other
sites that try to track everything)? I was going to do it myself, but
since I’m the author of the Affero clause and a primary advocate in
AGPLv3 adoption, I think it would better if someone else did it. Please
email me if you are interested in this volunteer task. I’ll update this
post once we have a team of folks willing to work on this.