Single-company free software

Posted Oct 13, 2005 6:40 UTC (Thu) by ekj (subscriber, #1524) [Link]

To take a well-worn example, there is considerable controversy over where the line is drawn regarding dynamic linking of GPL code to closed code, particularly with regard to the Linux kernel.

Yeah, that example is worn, allthough not well-worn. I've debunked it before, guess I'll do so again;

You are correct that it is not always 100% clear what exactly constitutes a "derived work", for example, in the case of the Linux kernel there's some disagreement as to if a kernel-module is a derived work of the kernel or not.

However, this confusion has absolutely --zero-- to do with the GPL, but is instead a general problem with copyright.

"derived work" is defined in law, and license-writers are not free to redefine it. Or put another way: if they redefined it, that redefinition would carry no weight anyway, what matters is what is, in the eyes of the law, a derived work.

If I write my own "EPL" (Eivinds Public License) in which I state that all software running on the same computer as my software is to be considered "derived" and must be released under the EPL, that would never stand up in court. If the law considers that non-derived (and that's a fair bet) there's nothing I can write to change that -- I'm not the lawmaker in any country.

Oposite, writing that I consider something *not* to be derived (even though legally it may be) will also not change the meaning of derived work. It migth however be interpreted as a permission from me to do so. (In other words I say: "I don't consider loadable modules derived from my work", the court may hear that as: "I permit loadable modules with other licenses")

Yes, it's sometimes unclear what exactly constitutes a "derived work", this is however fully a unclarity in the law, and nothing that *any* license can change.

Posted Oct 14, 2005 0:49 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

If you don't agree to the GPL, you don't have the extra rights.

Small technical correction: GPL is not a contract (aka agreement), ergo, there's nothing to agree to. What you mean is that if you don't perform the conditions of the GPL, you don't have the extra rights.

The difference is one of timing: in a contract, you agree to it and then can be forced to perform (by the person with whom you agreed) at a later date. With a license condition, you perform the condition, and then you have the license. You have no future commitment. There's nothing to breach.

Posted Oct 11, 2005 23:22 UTC (Tue) by Ross (subscriber, #4065) [Link]

Discussion about revokability of the GPL came up when the nmap author forbid SCO from using his software due to their claiming that the GPL was invalid. Also with DJB's software with it's lack of real license.

As for the point about licensing: licenses have to work that way. The only person who can license a copyrighted work is the copyright holder. They may give permission for another to sublicense, but that only works because they are acting under the copyright holder's authority. A copyright isn't ever transferred through licensing, GPL or otherwise. The point is not that the copyright holder doesn't have absolute authority over distribution with the GPL, but that they do have such authority and chose to use it to grant sublicensing rights with only minimal restrictions. They can't "ungrant" those later, as there was no provision in the original license for that to happen. IANAL either.

Posted Oct 13, 2005 14:58 UTC (Thu) by Duncan (guest, #6647) [Link]

> 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

Posted Oct 11, 2005 9:21 UTC (Tue) by drag (subscriber, #31333) [Link]

Yes, it's a license. A copyright license. It says as much in huge letters.

Show me. I said it was a license. A license dealing with distrubuting software. It does not with distributing copyrights. When a software author distributes software under the GPL he retains full copyrights.

Fundamentally all software licenses, including GPL, are based on copyright law. The GPL especially leverages copyright law agressively because copyrights are a fundamental to most forms of property law around the world and enforced by many international treaties.

If it were a contract, in many jurisdictions there'd have to be an exchange of consideration and something like a signature or some other explicit acceptance.

None of these are generally held to be true for the GPL, as I understand it.

I never said it was a contract. It's a license, I said it was a license.

Posted Oct 12, 2005 20:14 UTC (Wed) by AnswerGuy (guest, #1256) [Link]

In popular vernacular the term "derivative" can mean "inspired by" (possibly with a denigrating connotation). If I say that the old TV series "The Saint" was derivative of Ian Fleming's work in a critique of it --- that would be the likely inference.

However, the term "derivative" in the context of copyright law is somewhat more specific. There has to be a substantive copying. (Not necessarily literal copying, but copying nonetheless).

Conflating "derivative" (in the more general sense of "similar to and probably or presumably inspired by) with "copied" is exactly the sort of yellow sensationalism that SCO has been attempting in their full press public case against Linux. It appears that they've tried the same in the court of law, as well. So far the latter of these fiaSCOs has apparently been wholly unsuccessful.

JimD

Posted Oct 13, 2005 5:53 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

we don't know the license terms, but we know they aren't permanent and irrevokable becouse Oracle has publicly said that when the contract is up for renewal next year they currently 'fully expect to negotiate an extention to that relationship"