|
|
Log in / Subscribe / Register

Single-company free software

[Posted October 10, 2005 by corbet]

This has been an interesting week for those who watch how free software and the business world interact. Oracle's acquisition of Innobase, Check Point's acquisition of Sourcefire, and the closing of the Nessus source all raise some fundamental questions. Free software users are secure - even smug - in the knowledge that the software they use cannot be yanked out from under them. Is that really true, however, in situations where an important component is owned by a single company?

Oracle has announced the acquisition of a Finnish company named Innobase. This company is the creator of the "InnoDB" storage engine used by the popular MySQL relational database management system. MySQL has a number of storage engines, but InnoDB is the one which seems to meet the needs of a large portion of MySQL's users. So those users may well have cause to wonder about language like the following, from the Oracle press release:

InnoDB is not a standalone database product: it is distributed as a part of the MySQL database. InnoDB's contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship.

MySQL AB has put out a cheery press release "welcoming" Oracle to the free database market. Behind the smile, however, there may be some worry in the MySQL office. Oracle, after all, does not have a reputation for being a particularly pleasant company to negotiate with. MySQL is almost certainly paying Innobase for the right to include InnoDB with the proprietary versions of its software; it may be that the price is about to go up.

Should MySQL users worry? The current version of InnoDB is licensed under the GPL, and Oracle cannot take that away. What might happen is that development for the freely-licensed InnoDB may slow or stop. Nothing can prevent the user community - or MySQL AB itself - from forking the project and continuing development should Oracle take things in an undesirable direction. But MySQL AB's motivation to do so may be small if it is unable to include InnoDB in its commercial products.

Meanwhile, Sourcefire has been acquired by Check Point, a security firm. Sourcefire is the company created around the free Snort intrusion detection system. Snort users depend on it to catch and respond to attempts to compromise systems on their networks. So the idea that this code could go proprietary is of concern.

Check Point claims to be "fully committed" to the Snort open source community, so, presumably, Snort will remain free for a while. In the case of Snort, however, the users who truly depend on it are already paying for additional services. Among other things, a tool like Snort requires regular updates to its rule set to keep up with the latest attack signatures. Quick rule updates were already a value-added service, and that is unlikely to change. With luck, the free rules will continue to be updated regularly. If that fails to happen, and there is sufficient interest in the community, those updates will come from outside the company in the future.

Users of the Nessus security scanner were recently surprised by a Nessus roadmap posting. The upcoming 3.0 release will include a number of improvements, especially in performance, but it will no longer be licensed under the GPL. It will, instead, carry a "free beer" license which makes the distribution of binaries difficult or impossible. Tenable Software, the company behind Nessus, cites two reasons for the license change. The first is that other companies are using Nessus to compete in ways that Tenable sees as unfair:

A number of companies are _using_ the source code against us, by selling or renting appliances, thus exploiting a loophole in the GPL. So in that regard, we have been fueling our own competition and we want to put an end to that. Nessus3 contains an improved engine, and we don't want our competition to claim to have improved "their" scanner.

The exact nature of this "loophole" is unclear; selling an appliance loaded with GPL-licensed software does not change the GPL's requirements, as several router appliance vendors have found to their detriment. That said, it is clear that Tenable believes that distributing Nessus under the GPL is costing it business. When that belief is combined with the company's other claim - that the wider community has failed to contribute any worthwhile code to Nessus anyway - the reasoning behind the change becomes clear. Why bother with a free license when it hurts business and does not bring in any contributions from outside?

It is hard to say, from a distance, why there has been so little community contribution to Nessus. Certainly there is nothing readily visible on Nessus.org encouraging contributions. But there does not appear to be any indications that Tenable went out of its way to discourage or reject contributions. This may be one of those cases - certainly not the only one - where an outside development community has simply failed to come together for a particular project.

Once again, the current version of Nessus is licensed under the GPL, and nobody can take that away. Tenable has even said that it will continue to support the GPL version with bug fixes. So if the Nessus user community is truly upset by the licensing change, it will be able to fork the free version and carry it forward. It's worth noting that many Nessus plugins, which perform the actual security checks, have been covered by a different license for some time, however. Tenable requires third-party plugins to be distributed under the GPL, which indicates that the company sees those plugins as being derived from Nessus itself. How such plugins can be legally used with a non-GPL Nessus would be an interesting question for the lawyers.

All three of these cases illustrate a particular hazard associated with free software projects which are entirely owned by one company. Any such project can turn proprietary at any time, leaving users scrambling for a new solution. This risk is worth keeping in mind, but it should also be kept in perspective. Proprietary software is no more reliable; indeed, it can vanish altogether leaving users with no recourse at all. Free software, at least, cannot be taken away. Users have the option of carrying it forward, should they choose to do so. OpenSSH is a good example of how this freedom can work.

A bigger risk with single-company free software might well turn out to be that it has a harder time attracting developers. This may be especially true in cases where developers are required to assign their copyrights to the owning company on any contributions. It is hard to justify giving away your code when some company might just turn around and make it proprietary. For this reason, a number of companies based on free software projects have created independent foundations to own the copyrights and manage development. For both users and developers who are evaluating free software projects, the existence of such a foundation will provide a higher degree of assurance that the freedoms they count on will remain available in future releases of the software.

to post comments

Single-company free software

Posted Oct 11, 2005 2:24 UTC (Tue) by lutchann (subscriber, #8872) [Link] (12 responses)

The current version of InnoDB is licensed under the GPL, and Oracle cannot take that away.

According to this Wikipedia article, there are genuine concerns about the revocability of the GPL that, like most aspects of the GPL, have not been tested in court in any jurisdiction.

Single-company free software

Posted Oct 11, 2005 5:29 UTC (Tue) by szoth (guest, #14825) [Link] (5 responses)

Do you think its possible that the people who think that public domain is
a better way to distribute source code than under the GPL might have a little more influence on that wikipedia article that other folks?

The article seems to be refering to the legality of shrink wrap lisences. If it's a problem for the GPL it would be a problem for all kinds of other licenses too.

As for the GPL not being tested, that's some popular FUD your peddling. Even if it were true it would still be FUD, but it is more fiction that fact. To your credit you say that it is _mostly_ untested, a subjective statement and impossible to refute. However I will claim that the GPL is _mostly_ tested:

http://web.archive.org/web/20191018144227/http://www.groklaw.net/article.php?story=20050225223848129

Single-company free software

Posted Oct 11, 2005 15:59 UTC (Tue) by lutchann (subscriber, #8872) [Link] (2 responses)

Geez, don't get so defensive, this isn't Slashdot.

I specifically linked to the article where the information came from so that everyone could draw their own conclusions as to the accuracy and bias of the source. I don't put a lot of stock in the journalistic quality of Wikipedia material, so I'm not going to take anything written there as fact without verifying it first, and I don't expect anybody else to.

I stand by the claim that the GPL is mostly untested, although I don't mean "tested" in the FUD sense. The GPL is generally considered to be a valid, well thought-out license, and nearly all of the code I write is released under the GPL or LGPL because I have faith in the legal soundness of those licenses. However, the interpretation of many of the terms in the GPL is still unclear.

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. When proprietary software companies find an unanswered question regarding their own license, they promptly revise their license terms to clarify their intentions. However, since there is such a large body of code that will forever be licensed under the GPLv2, it is up to the courts to resolve ambiguities in the license, and that doesn't seem to happen very often.

Single-company free software

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

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.

Single-company free software

Posted Oct 13, 2005 15:24 UTC (Thu) by lutchann (subscriber, #8872) [Link]

Thank you, that is a much better explanation regarding the binary module debate than I could have managed. This particular area of confusion effectively illustrates why we desparately need more case law to shape the legal framework we've created for open source development. As you've pointed out, these issues arise not just from ambiguities in the GPL, but from ambiguities in copyright law that affect us more than commercial developers who rely instead on contract law to enforce their software licenses. Again, until we see more court cases, we can't be sure about a lot of the "common knowledge" surrounding open source software.

Single-company free software

Posted Oct 11, 2005 16:37 UTC (Tue) by jwb (guest, #15467) [Link] (1 responses)

The GPL is not a shrink-wrap license, and it is unlike almost any other commercial software license. The GPL grants you extra rights you do not normally have. If you don't agree to the GPL, you don't have the extra rights. Most licenses, including shrink-wrapped EULAs, take away rights you normally have. The difference between the two is fundamental.

Single-company free software

Posted Oct 14, 2005 0:49 UTC (Fri) by giraffedata (guest, #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.

Single-company free software

Posted Oct 11, 2005 17:12 UTC (Tue) by Ross (guest, #4065) [Link] (5 responses)

I like Wikipedia as much as the next person, but just because it says something doesn't make it true. I have not actually read the article. If I did I'd feel obligated to fix it which I just don't have the time to do ATM. Most licenses have not been tested in court in any jurisdiction. There just isn't any credible reason to believe in the ability for a pure license to be revoked outside of any terms embodied in that license (the GPL in fact automatically revokes itself in certain conditions). The GPL is a promise from the copyright holder to the recipient of the software. If they tell you you have a perpetual license to distribute modified copies of the work, there is no legal way for them to take back that promise in the future.

What they can do is release it under a different license and make all future modifications only under that license. That does not remove the copies of the work under the old license nor take away the rights granted to people holding those copies, including the right to distribute them to others under the same terms.

Single-company free software

Posted Oct 11, 2005 18:49 UTC (Tue) by lutchann (subscriber, #8872) [Link] (3 responses)

I figured that merely pointing out the article was from Wikipedia would be enough of a hint for everybody to add that pinch of salt when reading it.

The reason I linked to it, though, was because I'd not previously heard the argument it suggested regarding revocability of the GPL, which I will summarize here for you and others who would prefer not to read the article. I'm not saying the argument is correct or well-founded, merely that it is interesting to consider.

The main point is that the GPL is (was, maybe) unique in that permits redistribution not by allowing licensees to sublicense to the recipients to whom they distribute the software, but by licensing the work from the original licensor to the recipients. This might be interpreted to mean (IANAL!) that if the original licensor somehow loses the copyright, the program could no longer be distributed to new recipients.

Anyway, as I pointed out in a post a couple of minutes ago, the reason it is particularly important for the conditions of the GPL to be shaped by the courts is because the license is effectively set in stone for a huge amount of software, so there really is no other way to find further clarification on the grey areas that have surfaced over the last decade.

Single-company free software

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

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.

Single-company free software

Posted Oct 12, 2005 18:02 UTC (Wed) by MathFox (guest, #6104) [Link]

I am not a lawyer either, but IMO revocation of a written offer requires at least a written revocation. Thanks to the GPL every owner of a copy of the sourcecode has the right to redistribute and relicense. It won't be trivial to send out revocation notices to all redistributors of your code. It is more difficult than the RIAA and MPAA task to track P2P users, a John Doe lawsuit shouldn't work against someone who legimately distributes your code.

If you succeeded in taking this notification hurdle, the real legal fun will start. You will be asked to pay damages for revocation of distribution rights, people will object to revocation of their rights to use the code, etc. I can not tell beforehand how the lawsuits will work out in all relevant jurisdictions, I don't expect that you'll win the ~100 lawsuits easily.

Nmap Non-Revocation

Posted Oct 13, 2005 6:50 UTC (Thu) by fyodor (guest, #3481) [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.

I was not arguing (nor do I believe) that the GPL can be revoked in the general case. The SCO issue was based on specific language within the GPL clause 5: "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License." To the best of my knowlege, SCO has ceased distribution of Nmap in accordance with my demand (If anyone catches them still distributing it, let me know).

As for the Nessus issue, I have already sent out a response for the Nmap Security Scanner Project. We aren't planning to follow suit. Nmap has been GPL since its release more than 8 years ago and I am happy with that license.

-Fyodor

Single-company free software

Posted Oct 21, 2005 20:49 UTC (Fri) by pimlott (guest, #1535) [Link]

There just isn't any credible reason to believe in the ability for a pure license to be revoked outside of any terms embodied in that license
Yes there is. And if you google "GPL revocable", you will find additional discussion which makes it clear that the question is far from settled.

Single-company free software

Posted Oct 11, 2005 2:55 UTC (Tue) by jonabbey (guest, #2736) [Link]

Oooh, diabolically brilliant move by Oracle.

Single-company free software

Posted Oct 11, 2005 3:38 UTC (Tue) by hppnq (guest, #14462) [Link]

Mmmh. Of course we worry about what might happen when the proprietarians invade our free world, because we know their business models: discontinued software is just one of the threats users of proprietary software are exposed to, all the time.

The GPL however cleanly separates the rights to use, modify and distribute free software from the business concerns usually mixed in with (proprietary) software licenses. That does mean that free software companies have to invest in coming up with a business model that works for them, since it's not as simple as getting enough users on the upgrade-train.

The crazy vision that software should be like water and earth has turned out to be incredibly successful, especially for users. I like this way of the dodo. ;-)

Single-company free software

Posted Oct 11, 2005 5:48 UTC (Tue) by hgj (guest, #672) [Link] (16 responses)

What is wrong with the next statement:

If version 2 of a product is GPL then version 3 of that product is a derived product of it, so version 3 must also be released as GPL.

Single-company free software

Posted Oct 11, 2005 6:08 UTC (Tue) by botsie (guest, #1485) [Link] (2 responses)

> What is wrong with the next statement:

> If version 2 of a product is GPL then version 3 of that product is a
> derived product of it, so version 3 must also be released as GPL.

Not really true. As the original licensor of the work, you have every right to relicence your work anyway you like. Licences only apply to *other* people.

Of course, licence changes cannot be retroactive. Any older versions that were GPL-ed would still be available to the community and could be maintained and enhanced if need be -- but of course only under the GPL. It's only a problem for people like MySQL AB who depend on being able to dual licence the code for revenue.

Also, any software that was previously open source couldn't be relicenced unless:

a. all community patches were accompanied by a copyright assignment

b. or all contributors signed off their agreement with the license change.

So I'd tend to be a little suspicious of projects that changed their licensing.

-- b

Single-company free software

Posted Oct 13, 2005 8:49 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

It is definitely annoying to change licenses. It took SpamAssassin months and months and lots of chasing and the removal of some working code (because the original developers couldn't be found).

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?

Single-company free software

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

Single-company free software

Posted Oct 11, 2005 6:54 UTC (Tue) by drag (guest, #31333) [Link] (6 responses)

GPL is a software license dealing with redistributing software... It doesn't deal with copyrights, it doesn't deal with patents (there is implied contract.. (if you give somebody the right the use software, but sue them for using it is something that would fail in a courtroom) but it's not explicit).

If you can release a peice of software that was released under the GPL under a new closed source license depends on weither or not your a copyright holder.

Under the GPL you can use, modify, and redistribute any copies or modified copies of GPL'd software. Just as long as you release the source code if the end user wants it. If you don't release the source code under request then you loose your rights under the GPL.

But if you wrote the software, or at least obtained the copyright, then GPL doesn't deal with you. You own it you do what you want with it. You have to own ALL of the copyright though. If you have a patch or add-on code for a program you got under the gpl, it doesn't make it yours.

Soooo...

If InnoBase owned all the copyrights for InnoDB then Oracle could release it under closed source license since I assume that by buying out Innobase Oracle also bought the copyrights.

If InnoDB doesn't own all the copyrights and a part of their product is only aviable to them under the GPL license, then Oracle can't release it under a closed source license anymore then Innobase, you, or I could do.

What they can do instead though is stop all new developement on InnoDB. Maybe somebody will start a community effort around the GPL'd version if that happens.

Single-company free software

Posted Oct 11, 2005 8:52 UTC (Tue) by nix (subscriber, #2304) [Link] (5 responses)

GPL is a software license dealing with redistributing software... It doesn't deal with copyrights, it doesn't deal with patents (there is implied contract.
Yes, it's a license. A copyright license. It says as much in huge letters.

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.

Single-company free software

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

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.

Single-company free software

Posted Oct 11, 2005 10:25 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

I think you may have a language problem. A copyright license is not `a license for distributing copyrights'. It's a license grant controlling the copying of works, as you yourself just admitted. We call `a license grant controlling the copying of works' a `copyright license'.

Copyright and property law have absolutely nothing whatsoever to do with each other in UK or US law or any other jurisdiction I've heard of.

You are repeating canards.

Single-company free software

Posted Oct 11, 2005 12:19 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

Well I suppose your right. Like I said I am not a lawyer.

It still doesn't say anywere in the GPL about it being 'a copyright license', much less in big bold letters. I suppose that's implied though.

Copyrights is based on the same legal concepts of property though. You make something it's your property because you made the effort to create it. Same thing with written works. You made it then the copyright ownership is essentially your property to give or sell as you choose. (or if you worked under contract to create the software then the people that hired you own the copyright)

Same fundamental concept, pretty much universal property stuff from the dawn of time. Natural law stuff, liberty type stuff.

Unlike, say something like, patents. Which is a relatively modern invention.

All I wanted to get across though was that the GPL has no transfer of the ownership of the copyrights, those are retained by the author and if that person or company owns all the copyrights then they can release versions under whatever license they choose. If they don't own all the copyrights to the software then they can only release under GPL if they obtained the software, at least partially, under the GPL themselves.

Single-company free software

Posted Oct 11, 2005 15:00 UTC (Tue) by MortFurd (guest, #9389) [Link]

SNIP...

All I wanted to get across though was that the GPL has no transfer of the ownership of the copyrights, those are retained by the author and if that person or company owns all the copyrights then they can release versions under whatever license they choose. If they don't own all the copyrights to the software then they can only release under GPL if they obtained the software, at least partially, under the GPL themselves.

That is the one absolutely correct statement that you have made. The copyright owner can change the license to take a piece of software out from the GPL. If you don't have full ownership of the copyright to it, then you cannot take a piece of GPLed software and place it under a different license.

On the other hand, even if you do own all copyright on a piece of GPLed software, you still cannot revoke the rights granted on previous versions of the software. Your new version can be proprietary, or be under any license you like - even one and the same version of the software can be available under different licenses. The GPLed copy stays under the GPL, though. This is what gives Free (as in freedom) software the ability to fork and continue even if the original copyright owner drops the project or takes it proprietary.

Single-company free software

Posted Oct 13, 2005 19:31 UTC (Thu) by kreutzm (guest, #4700) [Link]

Well, actually copy right is not an "natural" concept either. When only few people could read and write, copying was just natural (take the monks copying the bible or other works as examples). Just when copying became easy and more and more people were able to read, the concept of copyright sprung up.

Single-company free software

Posted Oct 11, 2005 14:37 UTC (Tue) by pj (subscriber, #4506) [Link] (2 responses)

>What is wrong with the next statement:
>
>If version 2 of a product is GPL then version 3 of that product is a derived product of it, so version 3 must also be released as GPL.

What makes you think v3 is necessarily a derivative of v2? Many many software products and projects have done a rewrite from scratch between major versions. In such a case, the rewritten code isn't really a derivative work since they have no code in common.

Single-company free software

Posted Oct 11, 2005 18:20 UTC (Tue) by Blaisorblade (guest, #25465) [Link] (1 responses)

Not necessarily. Samba4 is said to be a full rewrite of Samba3, but the notion of "derivative work" doesn't relate exactly to "common code".

If you and I write a quicksort routine indipendently, and it happens to be the same exact routine, there's no copyright violation, even if we write at different moments in time. The latter writer should just show that he never saw the other code.

Viceversa, Samba4 is written starting from Samba3 code, implementing more or less the same algorithms/protocols/whatever, but after thinking to its design problem and re-engineering it.

To make it more obvious, say the Samba3 team has disappeared and somebody else starts rewriting Samba to obtain Samba4 anew, like Andrew Tridgell is doing.

If he starts from the ideas (say reading the code) of Samba3, his code will be a derivative work.

At least, from the copyright law point of view. IANAL, anyway.

I don't know if the GPL extends his powers so long, but I know for sure that, for instance, people implementing Classpath (a full replacement of Java libraries) are disallowed from reading the Java libraries sources, to avoid lawsuits.

Conflating different meanings of "derivative"

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

Single-company free software

Posted Oct 12, 2005 12:29 UTC (Wed) by jamesh (guest, #1159) [Link] (1 responses)

If a single entity holds the copyright to the entire project, then it doesn't need a license to create derivative works, so they could use whatever license they want.

Two ways to prevent this are:

  • Make sure no one owns copyright on the entire work. That way license changes require consensus (which would mean the project wasn't covered by this article).
  • Transfer ownership of the code to a separate entity such as a foundation (as discussed in the article). This way the original author's rights are clearly defined by the license it receives from the foundation. Depending on the bylaws of such a foundation and the license it grants, this might not actually be any better though ...

Single-company free software

Posted Oct 13, 2005 8:55 UTC (Thu) by nix (subscriber, #2304) [Link]

<blockquote>
If a single entity holds the copyright to the entire project, then it doesn't need a license to create derivative works, so they could use whatever license they want.
</blockquote>
This depends on how they got that copyright. If RMS went insane and the FSF decided to relicense its stuff under something not similar in spirit to the GPL (say, the Eat-Your-Babies EULA, which requires the eating of one baby for each copy redistributed), all those copyright assignments the developers signed would have their terms violated. What would happen then I don't know; a huge legal crapfest, probably...

Single-company free software

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

If version 2 of a product is GPL then version 3 of that product is a derived product of it, so version 3 must also be released as GPL.

Nothing is wrong with the statement as such, but you're forgetting one thing: If you're the sole copyright-ownder of a work, you're free to do anything you like with the software, including changing it and giving the next version out under a different license.

If you write GPLgame v1 alone you're free to update that and a year later release say MPLgame v2 or even ProprietaryGame v2 based on it. This only changes the minute you accept outside patches and don't have the people providing those assign copyright to you.

Selling GPL appliances

Posted Oct 11, 2005 15:27 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses) 

   A number of companies are _using_ the source code against us, by selling
   or renting appliances, thus exploiting a loophole in the GPL. [...]

Sure there are no concerns with the GPL in this case: Every buyer of such an appliance is entitled to the full source code of the GPLed software.

The real problem are vendors putting a web based user interface on top of GPLed software and keeping that user interface code proprietary. Obviously they think that the whole work (GPL engine + frontend) does not count as a derivative work so that they can get away with such a business model. It gives them a competitive advantage over other vendors who GPL everything and thus are required to share all improvements between themselfs.

However the GPL does not say that executing a GPL program by another process is enough to make the whole a non-derivate work. I guess it is only a matter of time that such GPL violations will come to the attention of a broader public.

*Renting* GPL appliances

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

In a sense it may be legal and possible to *rent out* an appliance with embedded GPL code. In that case it can be argued that the rental is a service rather than a "distribution" of the work.

Certainly I can offer you a service in which I employ my own proprietary extensions to a GPL'd product to perform some work for you; giving you back the results and refusing to reveal my sources. I haven't distributed the original work nor any derivative of that work; merely a product of that work's output.

In fact that is precisely what Dawson Engler at Coverity is doing using his xgcc patches to GCC to perform automated static source code auditing (as he did for the Linux kernel in a couple of reasonably well-publiced instances, through the Stanford MetaL code checker project)

.

I suspect this is the primary concern that the Nessus people had. That competitors were offering competing services based on Nessus and some plug-ins or NASL modules that they'd written themselves.

The emergence of sophisticated AJAX toolkits and techniques, along with the increasing ubiquity of permanently connected broadband across broader populations will exacerbate this problem. I can potentially take any sophisticated bit of UI independent code, provide an AJAX/web front end and offer it as a service rather than distributing it. I seem to recall that this was one of the major issues that the FSF was hoping to mitigate with version 3 of the GPL.

JimD

slick and smart move by Oracle

Posted Oct 11, 2005 23:49 UTC (Tue) by stock (guest, #5849) [Link] (3 responses)

It might just be that MySQL's InnoDB will have to be forked() soon.
InnoDB is currently GPL , but i have seen software projects move from GPL
to a different license, and the next major version of that migration
result became proprietary. It all depends how the folks of MySQL will see
this. Oracle has been very slick and smart with this Acquisition. Because
indeed, the next major version of InnoDB could make MySQL a _real_
database contender.

Robert

slick and smart move by Oracle

Posted Oct 12, 2005 18:27 UTC (Wed) by jonabbey (guest, #2736) [Link] (2 responses)

You can't change the license of a project without approval from the holders of the copyright. In the case of Innobase, that would now be Oracle.

Oracle may not be able to revoke permission to use MySQL under the GPL, but they may well be able to jack MySQL AB for big money to use Innobase under any other terms, as when MySQL AB licenses MySQL for embedded use, and such.

MySQL can fork Innobase all they want, but only under GPL, and then they would be unable to let people embed MySQL in their products without forcing the source code release of their proprietary bits.

Fiendishly clever of Oracle, again.

slick and smart move by Oracle

Posted Oct 13, 2005 3:15 UTC (Thu) by skybrian (guest, #365) [Link] (1 responses)

We don't know what license or contract there is between InnoDB and MySQL. It might be that MySQL already has all the rights they need and they're irrevokable.

slick and smart move by Oracle

Posted Oct 13, 2005 5:53 UTC (Thu) by dlang (guest, #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"

Forks of nessus

Posted Oct 12, 2005 11:01 UTC (Wed) by henning (guest, #13406) [Link] (1 responses)

There exist allready two forks of nessus..

Forks of nessus

Posted Oct 13, 2005 9:15 UTC (Thu) by bastiaan (guest, #5170) [Link]

Let me guess, gnessus and knessus. :-)


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds