Single-company free software

Posted Oct 13, 2005 14:58 UTC (Thu) by Duncan (guest, #6647)
In reply to: Single-company free software by nix
Parent article: Single-company free software

> It is definitely annoying to change licenses. [...]
> For projects that haven't used version control
> from inception (and we all know one big example),
> I'd say it's practically impossible to relicense:
> who wrote what?

I agree with the "annoying" part, but I wouldn't say your "big example",
the kernel, is practically impossible to
relicense, /under/ /the/ /right/ /conditions/, granted, not the "community
hostile relicensing" of the article. This of course has
relevance due to the upcoming GPLv3 and the fact that in general, the
kernel is GPLv2 ONLY licensed.

From what I've read, some portions of the kernel are already either
dual-licensed BSD (certainly so with the stuff that originated there) or
otherwise have legal "outs", such as yielding to Linus (or other esteemed
kernel hackers such as Alan Cox) the decision on any relicensing.

Also consider that the sheer volume of current activity is actually rather
astounding to contemplate -- Andrew Morton says in his OLS 2004 keynote
speech (see LWN's July 2004 timeline here:
http://lwn.net/Articles/111882/ , which links the Groklaw transcript ):

"If we look at the changes in the first six months from the release of
2.4.0 and compare that to the changes from the first six months after the
release of 2.6.0, in 2.4 we deleted 22,000 lines and added 600,000 lines.
And in 2.6 we deleted 600,000 lines and added 900,000 lines. In the first
six months. That's 1.5 million lines were changed in a 6.2 million-line
tree, a 64 MB diff in the first six months of the stable kernel. We
changed a quarter of it!"

Now, of course some of those lines were repeat-rewrites, so count more
than once. However, that's focusing on getting code right and moving
forward, not on rewriting. What would happen if they had to focus on
reimplementation?

Well, after the Bitkeeper events earlier this year, we have some idea...
Kernel development almost stopped for a couple weeks to a month, and
slowed for six weeks to two months, while the source control issue was
addressed headon. That happened because the community was forced to
address the issue with one mind, and it was surprisingly effective in
doing so, even in userspace, when their contributions are normally kernel
space.

Of course, the GPLv3 isn't out yet, nor has a complete draft even been
circulated, so we don't know for sure what'll be in it and whether the
kernel folks will decide its worthwhile switching to or not. If they DO
decide to switch, I doubt it'll be the big issue everybody thinks it might
be, for a couple reasons. One, the kernel community has already
demonstrated what happens when something needs to change, IT GETS
CHANGED!! Two, this time, there won't be a big deadline facing them, so
it'll be no problem if it takes years.

Most likely, the first change, after a decision has been reached, will be
to change the licensing guidelines, such that further contributions will
be dual GPLv2/3 licensed unless otherwise stated. After that, few new
submissions will be accepted without a signoff to that effect (altho as
mentioned, BSD licensed would work as well, since GPL can use that without
issue).

Second, a project would be undertaken to attribute specific code, as much
as possible, and get the authors to agree to the change. I've little
doubt most of the major current contributors will do so, or the decision
to switch wouldn't have been made in the first place.

Third, with normal attrition of old code, active assignment where possible
of what's left, and all new code not an issue, a decently conservative
guess would be 1/3 of the code new, and one third directly attribution
traced and relicenced, within say three years. At that point, 2/3 of the
code will be GPL3 licensed without even seriously focused effort being
applied, and the harder task of focusing on the last third can begin. By
four years out, something over 90 percent should have been reached, with
direct but not yet entirely focused effort. Rewriting the remaining 10
percent in a year's time isn't an unreasonable task at all, given the
previously quoted numbers, and the Bitkeeper/GIT switch demonstration of
what the community can do when even a sizable fraction focuses on it. I'd
venture that with focus, that remaining 10% could be successfully tackled
in ~6 months, reasonably, leaving six months on the 5-year mark to tie up
loose ends. Of that five-year timeframe, the six months of intensive
focus might be lost in terms of kernel progress, with slower progress over
the latter two years of high but not intensive focus. All told, it might
be 9-12 months of kernel development time lost, over the five year period.

Would that be worth it? Maybe not, but it's possible, depending on
exactly how the GPLv3 is worded, and what strengths it is found to have
relative to the GPLv2 in terms of a more modern legal framework,
potentially directly addressing patents, and the like. If it's not found
to be worth that, but still found to be worthwhile in general, a longer
term approach may be taken. Five to six years of "new code GPLv3 dual
licensed" together with a corresponding low priority focus on a rewrite
when it comes up policy, and attribution/assignment search, might result
in 80% of the code rewritten or GPLv3 permission given. Likewise doubling
the medium intensity period to two years, could bring that to mid-90's
percentage GPLv3 licensed code, with the last 5-ish percent addressed only
if the legal situation by that point demonstrates that dropping the GPLv2
is worth the trouble. After all, consider how much of the Linux v1 code
is still in the kernel, that's not either public domain or BSD sourced (as
would seem to be the case with at least some of the SCO stuff so far
seen), or easily rewritable using commonly accepted procedures that don't
depend on any of the original copyrighted code. "Kernel progress not
made" as a result, could likely then be reduced to something on the order
of that of the BK/GIT transfer, on the whole, comparable to noise, within
the context of the project over the course of the decade.

So... 5 years to a dual-GPLv2/3 licensed kernel shouldn't be unreasonable.
After that, the GPLv2 stuff can attrite at the normal pace. Nobody will
likely care when the last GPL2 dual licensed code is removed, because it
won't matter (legal developments not overtaking, of course).

All this presupposes, of course, that the GPLv3 is widely accepted within
the community as the "right" thing to do. Should that /not/ be the case,
the transition wouldn't be as smooth, but then again, Linus leads by
consensus and he knows it, and I don't believe anything beyond possibly a
change of the "default license" guideline would occur without without
general consensus within the community, so if that consensus isn't
reached, the problem, by definition, will not occur.

Also of interest here is the "Jeff Merkey" issue. If you recall and as
reported by LWN, he posted some time ago (it's not important enough to
this post for me to look up the details) to the LKML, offering $50,000 for
a BSD licensed kernel snapshot. He was summarily laughed off the list, of
course, but there were two subthreads that sprang up from that.

The first subthread was one that pointed out how undervalued his offer was
-- various generally industry accepted software value estimation methods
conservatively place the value of the kernel well into the single digit
millions of dollars, at minimum, so he was at least two orders of
magnitude off of even an offer that could be considered a serious
negotiating position. (Look up the context if interested, I'm not going
into the method by which the estimates are reached, here.)

Second and more apropos to this discussion, many pointed out how
impossible it was, even if the majors like Linus and Andrew WERE to be
tempted to sell out. Note, however, that this "impossibility" was within
the context of the offer and its immediate response -- several
contributors replying immediately that their contributions were made under
the conditions of the code being GPL, and under NO circumstances,
presumably not even if personally offered MILLIONS for relatively small
contributions, would they consider relicensing it BSD or similar, because
that would mean it could be taken proprietary and they were **NOT**
interested in their work being made proprietary under *ANY* conditions (a
response which I must say I found personally gratifying, but that's beside
the point).

The point is, the Merkey offer would have amounted to a hostile
relicensing of the code, from the perspective of many contributors, even
if the money was found reasonable, and therefore would have
been /close/ /to/ impossible. Never-the-less, given a few years and tens
of millions of dollars, the code in question could theoretically be
rewritten. However, the theory is out of line with reality in that if
that amount of money (likely tens of millions of dollars, certainly single
millions) were to be thrown at the problem, an entirely new implementation
could be written, making it "Linux compatible" if that were considered one
of the requirements.

Restating the conclusion of the Merkey events, it would make no sense to
take the Linux kernel private (or BSD/public, if you wish, which then
allows it to be taken private), since it would cost more to do so than to
reimplement from scratch to a compatible specification. That's rather a
different prospect, however, than that of a friendly/consensual
relicensing.

Over a timeframe on the order of a half-decade, a friendly relicensing
should be possible, and it's quite possible we'll see it undertaken, with
discussion starting next year as the GPLv3 drafts are circulated, and an
actual beginning to the kernel relicensing process sometime in ?2007?,
after the GPLv3 is finalized (assuming it's considered acceptable) and a
consensus has been reached among the active kernel community that
switching would be a "good" thing.

(A bit long winded, yes, but hopefully, I've decently covered the bases.)

Duncan