Bobulate

Just a touch of compliance today. If I wanted to do real compliance engineering, I would turn to gpl-violations.org (in Europe, and please note they are still looking for a new webmaster) or to Brad Kuhn/SFLC (in North America) to do the actual engineering and checking of product. But here’s a mostly happy story.

I spotted the LG NAS N2R1 at a local webshop. Two drives, DVD burner, UPnP, bla bla. Not something I need, but it struck me that that’s exactly the kind of device that does poorly in compliance — ships with Linux and busybox, no sources. So with my usual assumption of malice in place, I went looking. While the firmware downloads for the device (say from LG’s Dutch site) do not mention corresponding source code, the file is clearly and unashamedly a Linux image: a .zip containing a .bin which is actually a .tar containing a .tgz which is the result of tar czf – / on a Debian installation. Somehow I expected a firmware update to be a little more sophisticated than that, you know?

No README or other indications of the licenses in the firmware, but when I downloaded the users manual for the device, imagine my surprise to find pages 159-164 filled with license information: which parts of the firmware are covered by GPLv2, GPLv3, LGPL, other liceses, and a compilation of copyright notices and BSD variants. There’s a written offer for a CD with sources in the users manual. Pretty good, all in all — although of course one might consider checking that the sources are the complete corresponding sources for each firmware version.

But this brings me to a mystery point in the GPLv2. You may distribute versions of the Program in object code (section 3) under the terms of section 1 and 2 provided you offer the source code in some way. So — since this firmware is clearly distribution in object form — we need to check if the conditions are satisfied. The source code offer is ok. But what does “under the terms of Sections 1 and 2 above” mean? Section 1 is about verbatim copies of source code; section 2 is about modified versions (which might be understood to include object form). I guess the question comes down to this: does the condition in section 1, “give any other recipients of the Program a copy of this License along with the Program” apply to distribution in object form, or not?

Valentine’s day is approaching, and if you love Free Software, show some of that love. Send a bug report (a well-written one). Add to API documentation (someone was complaining about that on the dot). Update a wiki page.

The Free Software Foundation Europe encourages you to show your appreciation for your (fellow) friendly neighbourhood Free Software contributor. Hugs show up with distressing frequency in the KDE world, as does beer. I’ve gone out of my way to thank folks who have written useful software for me, and I’d like to recommend you to do it too.

A long time ago, in elementary school — and a primary purpose of elementary school is socialization — the words we used were “warm fuzzies” and “wet blankets” to describe different ways of interacting with people. Wet blankets tend to hang around a long time; so spread some love instead.

(Maybe this is just cover for an upcoming “ten things in KDE4 use that I can’t decide whether they’re bugs or just design decisions that I don’t like” blog post, who knows?) (Also, in spite of Tom Albers, I’m not going to be at the Dutch KDE launch event — other commitments)

I’m still sick. I still can’t hear properly, nor breathe, so as FOSDEM draws nearer (where I would man the FSFE booth, attend a few talks, and promulgate a business-friendly selection of Free Software licensing topics) I’m forced to re-evaluate whether I can go there at all: no, I am not going to FOSDEM. I’ll miss Paul’s bits on PIMping the KDE desktop, which is a particular shame. I’ll miss Michael Meeks, with whom I was looking forward to chatting about copyright assignment. I’ll miss Vincent Untz and the Dutch GUADEC team. I’ll miss Claudia and the KDE gang. I’ll miss the OSOL guys. I’ll miss the cute lovable blue Postgres elephant. And the weird devices at the OpenBSD stand. I could go on.

Instead, I’m going to stay home, eat lots of oranges, sleep a lot and hope for a better future. One where I can actually hold a conversation without phlegming anyone to death.

On a totally unrelated note, I’m reading “de telduivel”, a book on mathematics for kids by H.M. Enzensberger (English title “the number devil”, but the book is originally in German). It’s a fun book, and this time I’m actually reading it to the kids. Their minds do wander when we get to topics like fib(n)^2+fib(n+1)^2=fib(2n+1), but it’s inspiring for me as well. It’s been a long time since I sat down to try to do a little proof on paper, and since I don’t have to talk or breathe very hard to do math, it’s fun!

Like many folks, I’ll be going to FOSDEM this weekend, in Brussels. Thomas Koch posts his whole weekend schedule — gosh, that’s ambitious. I know I never get around to attending one tenth of the talks I might intend to see, simply because there’s too many people to talk to, things to demonstrate, chats to have and random other interesting things to do. Given the state of my health, I think I’m going to remove “excessive amounts of beer” from my list-of-interesting-things, but I’m still looking forward to Brussels Cheese during the social hours. Isabel Drost is giving a talk on Hadoop — that’s one I might actually make a point of attending, because otherwise I’m never going to understand any of her blog posts. I guess like I’m tedious about licensing, she’s tedious about map-reduce. We’ll see.

For most of the weekend you will find me at the FSFE stand near the front entrance. I hope it’s less freezing cold than down the other end of the hall where the KDE stand is, traditionally. I’ll be available for legal and licensing talk, mostly. Governance? Patents? All ears. For technical stuff I will need to escape from the watchful eye of my handler, Hugo Roy, and covertly discuss bits and bytes.

The Theodor Heuss Foundation (German site, but the Wikipedia article is probably more informative), named after Germany’s first post-war president, is a foundation established to remember the political achievements of Theodor Heuss as an example for social commitment, moral courage and the dedication to fostering democracy. The foundation seeks “to bring attention to something, which has to be done and shaped in our democracy, without being finished” (Carl Friedrich v. Weizsäcker, 1965).

The foundation awards a yearly prize and medal to persons of high standing and organisations, which are groundbreaking in these areas of social commitment and the fostering of democracy.

This year the prize has been awarded to Oxfam and to FSFE. The FSFE press release is available (also in German, French, Italian, Dutch and Greek, thanks to our wonderful and dedicated translation teams). In these complicated days, it feels — to me, at least — a little weird to be side-by-side with an organization like Oxfam. They are helping rebuild Haiti. Providing direct support, like water and shelter; “helpin’ people with skin“, as Granny Weatherwax might say. The FSFE helps with skin, too, (for instance with licensing advice, workshops, and promotion booths at events), but for far more abstract goals. Which isn’t to say that Free Software does not help: some Free Software is really useful in a disaster.

It might feel a little weird in the current context, but it is an honor and a privilege.

I recently wrote about the FreeType license and its double license and why it was necessary. It’s an interesting situation (for FreeType itself) because there’s the GPLv2 and a second Free Software license involved — the FTL, which is basically a 3-clause BSD license with attribution required.

Often, though, when we talk about dual licensed we mean a situation where one license is a Free Software license and the other is a fully proprietary one. Bear in mind that the 3-clause BSD license allows proprietization as long as you satisfy the attribution clause and the license distribution clause, so it’s not a world of practical difference, but one of intent. The suit filed around Palm’s PDF viewer on the Pre illustrates the effect differences of intent can have.

One way you can look at dual-licensed software is that you have “the usual license” (which in our context is a Free Software license, probably some version of the GPL) and that for some users who cannot abide by the terms of that Free Software license, you sell exceptions. Richard Stallman writes on the subject — I found it via groklaw, where also one of the first comments uses the phrase “selling indulgences,” which I think is much more evocative.

So the point is that if you are the copyright holder — the sole copyright holder, because you need to have the right to re-license the code — then you can sell an indulgence to someone who cannot abide by the Free Software terms, but whom you consider worthy to use the software nonetheless. Yes, that’s plenty subjective. My phrasing is also slightly wrong, because you don’t have to be the sole holder: there are other ways of ensuring that you can grant the indulgence even with multiple rightsholders (a contract or license grant would do). In any case: you can do this for specific reasons while still supporting and producing Free Software.

This is also RMS’s pragmatic point: while the FSF does not follow this practice, that doesn’t mean others cannot while still being “ok”. And I think that’s good news for GPL’ed libraries out there. For users of GPL libraries, bear in mind that intent matters, and that the GPLv3 offers a grace period that the GPLv2 does not — and that might be important when dealing with entities whose intents are not entirely clear.

The terms of service of a website vary from the stupid to the sensible, from short to very lengthy. The Facebook terms, for instance, have been re-worked in an attempt to be plain English and are very wordy indeed — but not stupid. No, stupid is a website with terms saying “This file may not be downloaded from this site.” Imagining (if you have any technical knowledge at all) how someone can come up with that is likely to leave you with a sprained hindbrain. Not recommended.

Now, it’s sensible to read the terms of use of a website; but not necessarily mandatory. Often there’s a checkbox saying “yes, I have read the Terms and Conditions” (with a link to the T&C). You can still check that without actually having read the legalese. Perhaps a setup where you must click on three randomly chosen highlighted terms in the T&C text before you can continue would improve matters? In any case, you don’t necessarily have to read the T&C, so have you really accepted them? Ars Technica reports on a recent court decision that says that the terms are enforceable even if you haven’t read them. There’s some limitations there, on the reasonableness of the terms and I imagine that a lot depends on how the T&Cs are used. Via Ars you can end up at two different reports at TechDirt, one for enforceable and one for non-enforceable. In other words, the jury (ha!) is still out on this one, but it’s worth keeping in mind when designing a site with a click-through agreement.

The FSFE sites have no user agreement (this is something we should fix, actually, since we both provide a service and publish user content). KDE’s UserBase has Guidelines and a code of conduct, which don’t cover all the bases, but it’s a start. Gitorious has something that looks a lot more like traditional terms of service — one might argue at some point whether not-reading those terms allows one to escape from the choice of venue, in light of the two court decisions listed above.

The FreeType library is released under a dual license: you can choose either the FTL (FreeType License) or the GPL, version 2. That means that a software stack that uses FreeType has to be license-compatible with one or the other (or both). In cases where the rest of the software stack also allows choices, this can be slightly complex. You end up with a combinatorial explosion of licenses — in theory, if not in practice.

But why is a choice necessary, anyway?

At issue is the “attribution clause”. This is common in the BSD family of licenses: the clauses usually say that you must attribute or credit the authors in the documentation accompanying the (binary distribution of the) software. Let’s look at the attribution clause of the FTL itself:

Redistribution in binary form must provide a disclaimer that states that the software is based in part of the work of the FreeType Team, in the distribution documentation. We also encourage you to put an URL to the FreeType web page in your documentation, though this isn’t mandatory.

OK, that’s fine. You can do that, by adding exactly that to your documentation. It’s not an onerous licensing requirement. But it is part of the license and must remain part of the license. This collides with the GPL version 2 because that license demands that the entire derivative work be licensed as GPL version 2 — that’s clause 2b, and the explanation in clause 2, and clause 6. Clause 6 in particular adds “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” And the attribution clause is exactly a restriction that is not allowed by the GPLv2: the license demands that you put something in the documentation, the GPL version 2 does not allow you to add that demand to the license of the whole, end of story.

Well, it would be end of story except that two efforts in the realm of license compatibility have happened: FreeType itself is also available under the GPL version 2, so if you really want to you can apply the GPLv2 to your program and be done with it (this is good for Free Software, but one could argue that it drops the permissiveness of the BSD-style license because now you can’t produce a proprietary, binary version and satisfy the license through attribution). And on the GPL side, the GPL version 3 has clause 7b which specifically allows distribution under the GPL version 3 with an additional restriction of the form

b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it;

This is just called an additional restriction because that’s the language of the GPL. Attribution in the documentation is, like I said earlier, hardly an onerous restriction. Well .. maybe. That’s something we’ll come to some other day. In any case, it means you can write your software under the terms of the GPL version 3, then add FreeType to it under the terms of the FTL and release the whole under the GPL version 3 with an additional restriction.

To return to my earlier consideration of KDE license policies: there’s nothing there that makes it impossible to have GPLv3-or-later code in there license-wise, because you can make compatible choices. But that’s a very small sample, and KDE policy remains otherwise.

I have been invoked by John Layt to explain some bits of the KDE licensing policy. It’s related to my recent writing on copyright assignment in the sense that it discusses reasons for picking particular licenses and how licenses interact. The back story is the KDE Licensing Policy, which lays down which licenses are acceptable in the various parts of the KDE platform technologies and applications. Roughly, the libraries need to be liberally licensed (which means they can be taken proprietary or shipped with otherwise closed devices — a common choice of GUI libraries nowadays). More concretely: (LGPL 2.1+) or (LGPL 2.1 or LGPL 3 or later approved) or BSD or MIT or X11. The idea is that you can either go for any version of LGPL from 2.1 onwards, or only selected versions of the LGPL which have been approved by the membership of KDE e.V. (if you don’t want to give a blanket permission to the FSF to update the license terms) or something very liberal.

You must offer the choice, though: you cannot put just the LGPL 2.1 on there: it must be “or later”. You also cannot just put LGPL 3 on there. It must be “version 2.1 or version 3 or any later version approved by the membership.” That’s KDE policy. There is a technical (well, licensing-technical) reason for this as well, and that is license compatibility.

The issue of compatibility is more pronounced in applications, where we also allow GPL variations similar to the LGPL variations mentioned above. The reason is that the GPL version 3 is incompatible with the GPL version 2. As long as there is GPL version 2-only code somewhere in the software stack, we must be able to license the software under something compatible with that license — and that means the application code must be available under GPLv2 (or something else, but not GPLv3-only). Let’s take a look at the licenses used in libraries in a typical KDE application. I’ll use Konqueror on Kubuntu 9.04 as an example, with ldd providing the list of libraries. Here’s just a partial list:

LGPLv2 libacl.so.1
LGPLv2+ libattr.so.1
PD libaudio.so.2
BSD libbz2.so.1.0
LGPLv2+ libc.so.6
LGPLv2+ libdl.so.2
MIT libexpat.so.1
X11 libfontconfig.so.1
FTL, GPL libfreetype.so.6
LGPLv2+ libgthread-2.0.so.0
MIT libICE.so.6
LGPLv2+ libkdecore.so.5
BSD libpcre.so.3
zlib libpng12.so.0
LGPLv2+ libQtCore.so.4
LGPLv2+ libuuid.so.1

Now, it’s important to choose at the moment of running, a license for each component such that the whole is compatible. For each component there must be a concrete choice made. So for libfreetype I could choose the GPL (I guess it’s version 2 only then, but the Debian copyright file gave me no additional information and I’m too lazy right now to look it up), and then all the other choices I make need to be GPLv2 compatible. And now you see the problem looming: if I choose GPLv2 for the Freetype part, then I can’t mix in any GPLv3-only components. Or conversely, when you put in GPLv3 code into a KDE application, you are forcing GPLv3-compatible choices in the rest of the stack.

I don’t see any GPLv3 incompatible components in this listing, but that doesn’t mean there are none anywhere in the stack, ever. So we don’t want to force the choice for GPLv3 by including GPLv3-only code. For the purpose of risk avoidance we have the policy requiring licensing as GPLv2-or-later so that we can, if need be, choose the GPLv2 version to remain compatible with GPLv2-only compatible libraries. So it’s basically us keeping license compatibility with software components using older licenses. But it’s uncomfortable to me, because at some point we might end up in a jam with license versions as other parts of the software stack migrate (although very unlikely with all the liberally-licenses software in the stack).

A little while back, Michael Meeks published a lengthy piece about copyright assignment (not nearly as lengthy as the articles he links to on untangling Wittgenstein’s net). Go on, read it (Michael’s stuff, not the net). It’s worth your time. When you get to the bottom, follow the link to Dave Neary’s take on assignment as well.

I’m going to take the time to respond to Michael and Dave with two different hats on: my FSFE hat (work-work, where I do legal and licensing stuff in the Freedom Task Force) and my KDE hat (volunteer work, where I have hacked on various bits and pieces for over a decade). This isn’t an entirely independent article on assignment, but looks at their comments on it. First off: there’s no right answer. Just like I say during my licensing talks at conferences: it (licensing or copyright assignment) is a choice that needs to be made, and that choice needs to be compatible with your goals, your morals, your business needs (if any), your sense of community (if any) and your desire to deal with administrative details.

One or two points of fact, though: the FSF does not require assignment — not for all GNU projects, at least. For some, yes. I made this exact same mistake at the GNU hacker’s meeting in Gothenburg last month. After all, it’s easy to find articles stating that the FSF requires assignment — even on the FSF site — and not so easy to find ones that do not. After all, it’s hard to search for the absence of a document. Andy Wingo can probably point out some.

Qt is still subject to a contributor agreement, but it is not a copyright assignment, but rather a license — in other words, the original author retains the copyright but grants the Qt organization (that is, Nokia Oy) a very broad copyright license (including sublicensing) and a patent license (for patents covered by the contribution). There’s some pretend remuneration. There’s little in the way of protection offered to the contributor, but I think it would take some far-fetched scenarios to find a patent danger in there (but do comment on their existence).

Michael’s examination of assignment forms (including Sun’s SCA) is missing one form that is used in Europe (and elsewhere), and that is FSFE’s Fiduciary License Agreement (FLA). This is a copyright assignment form — no patents involved, which makes some sense because there’s no software patents as such in Europe — that assigns those assignable rights to a Fiduciary, and then licenses those rights back. The assignable rights vary a little by jurisdiction (and Europe has lots of them), so that makes the form a little bit longer than it might otherwise be. In addition, there are variations as to whether you can assign future work or not — things like that.

(1) Subject to the provision of § 2, Beneficiary assigns to FSFE the Copyright in computer programs and other copyrightable material world-wide, or in countries where such an assignment is not possible, grants an exclusive licence, including, inter alia:

Here the FSFE is the Fiduciary. The Fiduciary is a party you trust to handle the copyright responsibly. By default you own the copyright — and I assume you trust yourself to do the right thing with licensing on the work you do for yourself — and the rights (most of them, anyway) are assigned to your estate. Presumably you trust your executors to do the right thing as well.

That actually leads into one of the reasons that you might want to think about copyright assignment — or at least about what happens with your code and the rights to your code when you’re no longer actively involved with the Free Software projects you contribute to. It happens — people drop out, no longer want to participate, or indeed pass away. Copyright assignment is one way to manage the risk (and possibly administrative burden) attached to something long-lasting like copyright.

Back to the FLA: the effect of clause 1 is that the Fiduciary gets control over the rights to display, reproduce, distribute, create modified or derived works and to allow third parties to do so. While re-licensing isn’t explicitly in there, the authorization to third parties implies it. There needs to be an exclusive license so that the Fiduciary knows they are the one party who may act as if they hold the rights. So once the Fiduciary has the rights, what happens?

(2) FSFE grants to Beneficiary a non-exclusive, worldwide, perpetual and unrestricted licence in the Software. This right’s [and licence’s] scope shall encompass and include all the rights [and licences] specified in § 1. Furthermore, FSFE grants to Beneficiary additional nonexclusive, transferable license to use, reproduce, redistribute and make available the Software as needed for releases of the Software under other licences. This re-transfer shall not limit the scope of FSFE’s exclusive licence in the Software and FSFE’s rights pursuant to §1.

You get it all back and can continue to license, sublicense, modify, etc. the work. In other words, you can continue to behave almost as if it were still your copyright. This is important because the Fiduciary wants to support the use of the software as much as possible. So you’re even free to create a derivative work and make it available under another license. I have not considered whether it would be possible to release it under a proprietary license — there might be some tricky interactions between the assignment and the re-assignment.

This FSFE FLA is available under a license that allows modification, so you can take the FLA and modify it for your own purposes. KDE has done so. The KDE FLA adds some restrictions to what the Fiduciary is allowed to do in terms of relicensing, but these clauses were added after some lengthy deliberation.

In any case, an FLA is an adaptable mechanism for assigning copyright to a Fiduciary — some party you trust. Just having the tool available doesn’t mean much, though: there are issues of policy as well. To return to the beginning: some projects / organizations have a policy of requiring assignment (though some instrument). Others do not. KDE is unusual in that it makes it possible to assign copyright to the organization, but does not require contributors to do so.

So let’s carry on with Michael’s comments.

To whom are you assigning it? This is a very important question — because you need to trust the fiduciary. Michael points out that a non-profit (association or foundation, with a constitution written to support particular goals) is probably a better Fiduciary than a corporation. The reason for that is relatively straightforward: money. You can buy a company, buying a non-profit is much more difficult. Not impossible, mind you. The FSFE acts as Fiduciary for a few projects. KDE e.V. acts for its own project. When asked, I tend to advise finding an existing trusted party (like FSFE or KDE e.V. or perhaps the Linux Foundation) who is willing to act as Fiduciary (FSFE takes it case-by-case, KDE e.V. is probably most interested in KDE-technology related projects, and I can’t speak for the Linux Foundation but they strike me as a potential partner). Setting up your own organization is possible, but has some costs. Those are costs in filing and administration, in setting up meetings, and providing long-term viability to the organization.

An assignment document should have an escape clause if the Fiduciary turns out not to be faithful (fides is Latin for faithful, more-or-less). The FSFE assignment has such a termination (or auto-revert) clause. So does the KDE one. So does the FSF’s assignment. Michael points out a few others, and such a clause should be seen as an additional form of risk-mitigation

Benefits and risks: Note well that “single owner” and “re-licensing” are listed as both a benefit and a risk. Which is as it should be: a single copyright holder also means a single point of failure (in terms of a take-over) while multiple holders means many points of failure (in terms of necessary re-licensing or negotiation). But a single copyright holder means success because it can manage negotiations, sublicensing, re-licensing and assets (in the sense of “your software has value to its users” even if not monetized) and multiple copyright holders is a success because of its resilience in the face of take-overs and flexibility in accomodating different viewpoints.

Again, it depends on what you think is most important and how you weigh the risks. I like the KDE e.V. approach with a non-profit association that holds a fair amount of the rights — but nowhere near all of them, on any part of the code — and then multiple individual (and corporate) rightsholders. That makes it both resilient and possible to go to court saying “we (KDE e.V.) represent a 30% stake in the copyright in this work”.

That last item relates to “defending the code.” There simply haven’t been enough cases of license enforcement to say whether a centralized copyright holder is useful or not. Harald (through gpl-violations.org) is very successful in enforcement in Europe, but he has rights (including assigned copyright!) to some well-defined and popular pieces of the Linux kernel which are fairly easy to detect. Besides which, not every developer wants to get involved in this stuff, so it might be difficult to find any individual developer to enter into a copyright enforcement suit.

On re-licensing I would add that “license tourism” by a Fiduciary should be avoided, perhaps by wording in the FLA, perhaps in the constitution of the Fiduciary. You don’t want to start with (say) the GPL and end up with the code under something totallylargely incompatible (Artistic). So once again: you need to trust the Fiduciary and set up some policy to make sure it all works.

Barriers to entry: This is, in fact, a biggie. It depends on the community creating the software whether asking or requiring assignment will be a barrier or not. I can imagine that in an established loosely-knit community of individual developers (read: the KDE community) introducing assignment is both scary and seen as a barrier to entry. That’s why you could choose the optional-assignment route, for partial centralization. In a corporate led project, assignment may be much less of a barrier. In mixed settings, I think optional-assignment or a really darn good explanation is needed (an explanation that I won’t be able to provide here, as it depends very much on individual circumstance).

Dave writes very briefly: he refers to assignment as a “superfluous barrier to entry”. I disagree with that — it can be superfluous, or, given explanation and circumstances, can be quite necessary. For a project with a community of individuals with no monetization of the software itself planned and an established brand and a broad scope (e.g. desktop projects) it probably is the former.

It’s at this point — in listing items under barriers to entry — that I feel Michael is lacking clarity. There’s a number of problems listed, in the moral, social and organizational spheres, all of which may influence the influx of contributions and affect user uptake of the software. However, I don’t see how these are specific to copyright assignment. When thinking of participating in a project, “the paralysis of uncertainty” can strike for any of a number of reasons. Licensing? Trademarks? Maybe the project is run by complete jerks only I haven’t realized it yet? Perhaps Mr. Knightly does feel affection for Jane Fairfax, and merely dissembles to poor Harriet Smith as a cover? [Sorry, I’ve been reading Jane Austen’s Emma and it will lead to any number of conspiracy theories.] The same applies to corporate unwillingness and scarcity: these are not issues that are particularly brought to a head by copyright assignment, but always exist in open collaborative projects.

The “death of trust” (gosh, isn’t that a melodramatic title) touches on two issues: the trust expressed (or lack thereof) by demanding an agreement beforehand and the issue of recognition when rights have been assigned. The former can be a real barrier to entry — but that was Dave’s point. The latter is easy to deal with, and indeed should be dealt with, by identifying individuals where that makes sense. For instance, my contributions to KPilot (since deceased) should be administered like so in the copyright header in the source files:

Copyright [year] KDE e.V. [contact email]
Author: Adriaan de Groot

The reason for still listing individual authors even after assignment is because of moral rights — pesky non-assignable, non-transferrable, non-heritable (I think) rights. Plus, it’s a means of giving recognition (if so desired) while correctly stating where the copyright (or exploitation rights) resides.

Carrying on to the end — from here until the Recommendations at the end of Michael’s piece I have trouble understanding what the problem is, unless it’s “do not assignments to untrusted parties who have an incentive to proprietize” — we find the Recommendations. Sensible recommendations, by and large. I especially appreciate the suggestion of a proxy for approving license updates — I had not seen that before. But all in all, it comes down to a very old Dilbert punchline: “try identifying the problem, then solving it.” That means considering the role you play (contributor, manager) and the style of contributions to the software and intentions for future growth.