
Plan 9 released under GPLv2 - mischief6
http://akaros.cs.berkeley.edu/files/Plan9License
======
4ad
Title is misleading. Plan 9 was, and continue to be LPL. The Labs just made a
special arrangement with these guys from Berkeley for them to distribute Plan
9 under dual-licensing terms. They in turn integrate Plan 9 bits into their
GPL operating system (akaros).

Plan 9 as distributed by the labs continues to be LPL (not GPL and not dual
licensed).

~~~
schmichael
I'm confused. If Berkeley received a GPL license for Plan9, doesn't that mean
they can redistribute it under the GPL?

From the GPL:

You can redistribute it and/or modify it under the terms of the GNU General
Public License as published by the Free Software Foundation; version 2 of the
License.

I'm assuming "it" in this case refers to the Plan 9 code.

~~~
pierrebai
4ad is just nit-picking.

The labs still only distribute Plan 9 under its own license. Now Plan 9 is
available also underthe GPL, but the labs doesn't distribute that version.
it's only relevant if they continue to work on it and don't continue to share
their changes under the GPL.

At worst, there will be a fork under GPL and they will slowly diverge.

~~~
4ad
My understanding is that the Berkley guys develop akaros and have no interest
in maintaining a Plan 9 fork (they just want to integrate some Plan 9 code).
Of course, other parties are free to fork the GPL version (not that this will
ever happen).

~~~
_delirium
Now that there's a GPL version, it does mean other developers of Linux
derivatives, or of Linux itself, could mine bits and pieces of the code,
though, just like Akaros is doing. I agree a long-running GPL-licensed Plan9
fork isn't that likely, but now that there's even a one-time dump of the code
under the GPL, it removes the legal barrier to kernel devs cherrypicking
pieces of the Plan9 code and integrating them into patches. For example, the
developers of Linux's v9fs implementation can now borrow code from Plan9's 9p
implementation, if they choose.

~~~
4ad
That's true, although I doubt that will happen as well. Time will tell.

FWIW, Ron Minnich wrote the Linux v9fs. He was very involved with Plan 9, for
example the Blue Gene port. He know ports Plan 9 bits into Akaros.

------
TallGuyShort
Referring to Plan 9's previous license, the Lucent Public License, Wikipedia
says:

'The clause in particular that causes it to be incompatible with the GNU GPL
is "This Agreement is governed by the laws of the State of New York and the
intellectual property laws of the United States of America."'

~~~
pyre
How is the GPL _not_ governed by the said laws? I'm confused. Is the GPL
illegal in the State of New York?

~~~
stonemetal
If you live in the UK and release code under the GPL to someone else in the
UK, then yes said code is not governed by the laws of the state of New York. I
am unfamiliar with GPL case law in New York but it is probably legal there.

The point is the LPL license says you agree to be bound by New York law for
license disputes even if you do not call New York home. Which means you have
to defend any license violation suits in New York, because the odds of finding
a Judge capable of hearing New York law cases outside of New York are rather
slim.

~~~
wbl
Actually, New York law is pretty much the world standard for international
commerce. Foreign law is applied regularly in many courts, for instance
inquiring if a marriage is valid.

~~~
jobigoud
Including in countries where we use code law rather than common law ? That
seems strange.

~~~
venomsnake
It has nothing to do with common/code law as I understand it.

It means that you agree that all disputes will be settled in NY. Every
european consultant that had done work for US company has signed such
agreement (enforcement cross continent is another beast altogether)

~~~
noselasd
Still, if you're UK based, and you provide GPL software to someone else who is
UK based - how would it make sense for that license arrangement were governed
by NY law. (which is presumably why the GPL doesn't have such a clause)

~~~
TallGuyShort
The bottom line is the clause is only to protect the lawyers and the original
distributor because they have chosen a jurisdiction they know best. The GPL is
all about protecting the user's freedoms, which is why they're so at odds:
even if the result isn't so different, the intent is very different.

------
cbaleanu
They also added Plan 9 to a github repository[0]

[0] [https://github.com/brho/plan9](https://github.com/brho/plan9)

------
hrkristian
From the Wikipedia article:

>Consequently, sharing the device across the network can be accomplished by
mounting the corresponding directory tree to the target machine.

Does this mean Plan 9 natively supports sharing _any_ device managed by the
kernel over a network connection?

~~~
4ad
Yes, mounting a remote /proc means instant remote debugging. Mounting a remote
/net means instant VPN.

~~~
smorrow
...bores me to no end. There's never any use for that stuff. The opposite
direction is more interesting, when the far end of the cpu connection uses
/mnt/term, especially for the like of /mnt/term/mnt/plumb.

I've never really understood why 'import /proc' is better than 'cpu acid'.
Yeah, there's cases where the remote host won't have acid installed.

More interesting, I think, would be stuff like getting /net in a VM from the
host OS [surely 9vx or inferno's /net could be separated out], getting
/dev/sd* from a 9P server that knows QCOW, etc.

Not mattering whether it's in the kernel or userspace, without using $LD_*, is
also far more interesting that not mattering whether it's local or remote.

------
etrain
The project responsible for getting the license changed is doing some awesome
work in the manycore lightweight OS space -
[http://akaros.cs.berkeley.edu/akaros-
web/news.php](http://akaros.cs.berkeley.edu/akaros-web/news.php)

~~~
mischief6
i would have submitted this link, but it has already been linked in the past,
and there was no other news page dedicated to this information on that site.

------
Dauntless
Can someone explain in plain talk what Plan 9 is and does? Thanks...

~~~
jff
Everything in UNIX is modelled as a "file", whereas in Plan9 everything is
modelled after a "burrito" \- some guy on Slashdot

~~~
frik
Plan9 needs a wider adoption. It is an evolution of UNIX design concepts:

* all objects are either files or file systems

* communication is over a network

* private namespaces (transparent access to remote processes) [1]

Even more modern concepts are in the NT kernel by Dave Cutler (VMS fame). NT
uses an object metaphor that is pervasive throughout the architecture of the
system. Not only are all of the things in the UNIX file metaphor viewed as
objects by NT, but so are things such as processes and threads, shared memory
segments, the global registry database and even access rights. [2] You can
browse the NT object tree e.g. with the ReactOS Explorer on Windows or
ReactOS. [3]

[1]
[http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs](http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)

[2]
[http://old.reactos.org/en/about.html](http://old.reactos.org/en/about.html)

[3] [http://www.foxplanet.de/explorer/](http://www.foxplanet.de/explorer/)

~~~
pjmlp
The NT Kernel is quite good.

~~~
e12e
I recall hearing old NT hands saying that in the early versions of NT, it was
more of a micro-kernel -- eg. the video driver ran in user space. So if the
video-driver crashed (obviously leaving the screen in an unusable state) -- it
was still possible to restart the driver via the keyboard -- no OS reboot
needed. But at the time, they couldn't get the performance they wanted, so
moved the stuff into the kernel -- the rest is a long history of blue screens
of death...

~~~
pjmlp
That is true story.

Thankfully as of Vista, video drivers are back in userspace.

NT is still a microkernel by design. What Microsoft did was to keep the
modules logically separated and use kernel internal RPC to switch between
areas of responsibility in the kernel. Even if it looks like a monolithic one.

This is how hybrid mikrokernels tend to work.

Since Vista the support for user space drivers has been improved a lot.

------
davexunit
Great news, but they really should have picked GPLv3+ or GPLv2+.

~~~
binarycrusader
Actually, it's a very good thing they didn't pick GPLv3+, or have you
forgotten what license the Linux kernel is under?

The Linux kernel is also GPLv2 (not +); I completely agree with the '+' thing
as that leaves the FSF in control of the license (effectively).

~~~
davexunit
It's unfortunate that the kernel Linux is not GPLv3, either.

~~~
binarycrusader
No, it really isn't unfortunate -- and Linus explained why:

[https://lkml.org/lkml/2006/9/25/161](https://lkml.org/lkml/2006/9/25/161)

~~~
hdevalence
The parent poster expressed a personal opinion.

Your reply amounts to "Your opinion differs from Linus's opinion, and is
therefore wrong."

There are many reasons why one might wish that Linux was GPLv3: for instance,
one might think that the "anti-Tivoisation" provisions are important. Linus
obviously doesn't share this point of view; that doesn't make it an invalid
point of view to have.

~~~
binarycrusader
Call me silly, but I believe the primary and original author of a project or
other creative work has the right to establish what is "right" or "wrong" for
their project unless they otherwise waived that right.

~~~
_delirium
Once a project has become a large collaborative project, I don't believe the
original author remains the sole arbiter of what's good for the project. Their
opinion should be given some weight, but whatever their opinion is doesn't
automatically decide what's right for the project.

~~~
binarycrusader
Which is why I said they had the right to "establish".

And you can't seriously convince me for a moment that the vast majority of the
Linux community doesn't agree with Linus.

Every single kernel contributor must at least feel partially the same way,
after all, they agreed to contribute under the existing license terms which
(as Linus pointed out) can effectively never be changed.

~~~
nknighthb
> _And you can 't seriously convince me for a moment that the vast majority of
> the Linux community doesn't agree with Linus._

You can't seriously convince me for a moment that the vast majority of the
Linux community doesn't disagree with Linus.

Your task now should be obvious: Come up with an agreed-upon definition of
"the Linux community", and run a valid survey.

> _Every single kernel contributor must at least feel partially the same way,
> after all, they agreed to contribute under the existing license terms which
> (as Linus pointed out) can effectively never be changed._

You've established nothing more than that the kernel contributors are willing
to work within that framework, not that they feel the same as Linus does.

~~~
binarycrusader

      Your task now should be obvious: Come up with an agreed-upon definition of "the Linux community", and run a valid survey.
    

That's your problem not mine; history has already established a precedent and
you seem deadset to prove otherwise. I don't need to disprove what is already
apparent.

    
    
      You've established nothing more than that the kernel contributors are willing to work within that framework, not that they feel the same as Linus does.
    

No, I've established that not only are they willing to work within that
framework, but that it's logical to assume that they agree with both the
licensing and direction. Otherwise, why would they devote so much time and
energy?

As they, "actions speak louder than words" \-- and your words seem very dim
compared to the action of thousands of contributors.

~~~
nknighthb
> _That 's your problem not mine_

Then it's not going to happen, and our opinions are equally valid.

> _it 's logical to assume that they agree with both the licensing and
> direction_

No, it's not. It's logical to assume they _accept_ them. There are many
reasons they might do so. One is certainly because they agree with them,
another is that, weighing the benefits of working within the existing
framework, they conclude it outweighs their disagreement with the licensing
and direction.

Some of the benefits include, by the way, continued salary. Most kernel
contributors are paid for their work by employers.

I work within frameworks I disagree with _all the time_. We all do. Sometimes
because I'm paid for it. Sometimes because I feel I can do more good within
that framework than fighting it. Sometimes it's because I'm bound to by law or
social contract.

That I don't shoot anyone that stands in the way of my ideals is not the same
as saying I agree with theirs.

If I had some motivation to do so (something I thought needed fixed, a new
driver I wanted, or an employer who paid me), I would have no issue
contributing to the Linux kernel. Yet I disagree with the decision to make it
GPLv2 only.

Anyone who can't hold two opposed ideas in their mind at the same time is
surely too stupid to be trusted to work on a kernel, no?

~~~
binarycrusader
For all practical purposes, by contributing, they (employers or individuals)
are agreeing (in whole or in part, through organisation or individually) with
the direction and vision that Linus has established enough to contribute. So
in the end, all of your convoluted arguments about not being in complete
agreement and frameworks is pointless.

~~~
mortdeus
What's funny about this discussion is the fact that Linus is supreme dictator
of kernel.org. Whatever he decides to merge in his personal fork of Linux
shouldn't be up for debate just because the Linux community willingly decides
to keep pulling his commits into their clones.

That's why we have the right to fork. While we can't change GPLv2 kernel code,
there is nothing stopping anybody from including GPLv3 code in the kernel so
long as it doesn't directly link against GPLv2 code in a way when the fork is
distributed.

------
bobowzki
I'm always hoping Plan 9 will take off! Such an interesting system to
experiment with...

Would be interesting to see what would happen if a cloud provider offered an
(updated) version.

------
yosyp
seems to be a lot of confusion here. excellent explanation of this by Ron
Minnich, directly from the 9fans mailing list
[http://9fans.net/archive/2014/02/75](http://9fans.net/archive/2014/02/75)

------
pjmlp
This is great news.

------
e12e
Does anyone have some insight into how Akaros compares to (and contrasts with)
Dragonfly BSD?

------
brickcap
Am I the only one who thought this referred to the movie plan 9 from outer
space?

~~~
georgemcbay
In a roundabout way, it does, as that's what the OS was named for.

But as an older unix nerd/Go programmer, I have the opposite reaction where
when I hear people talking about the movie it immediately reminds me of the
OS.

------
patrickg_zill
Is it easy to install under VMware, VirtualBox, or KVM?

------
z3phyr
PLAN 9 uses its own standard of C

~~~
RamiK
That's incorrect. Plan 9's C is a restricted ANSI C variety.

~~~
4ad
It's not restricted, it has extensions rather.

~~~
RamiK
I'm thinking about the pre-processor not supporting #if and the requirement
for function prototypes.

I suppose the extension you have in mind are the extra libraries for dealing
with buffered io, unicode and concurrency. But I don't think those could be
termed "PLAN 9 own standard of C".

To clarify, my idea of restricted was in the sense of a highly refined subset.
Much akin to how one should use C++ for instance. A careful selection of the
good parts in C. Essentially, I was paying a complement to Plan9. :)

~~~
4ad
There are language extensions, mostly related to embedding structs (which made
it in Go) and a new storage class, not only new libraries.

Please see section 3.3:
[http://doc.cat-v.org/plan_9/4th_edition/papers/compiler](http://doc.cat-v.org/plan_9/4th_edition/papers/compiler)

~~~
RamiK
Extensions don't break standard compliance so I didn't bring them up. Note
that both C++ and GNU C have similar extensions but under different semantics
which don't make them any less ANSI compliant.

BTW, be careful around those documents. The assembler, compiler, parser and
linker have seen over two decades worth of work since those were put ink to
paper. Though admittedly I haven't read through the lib9 source tree in
years...

~~~
4ad
> Extensions don't break standard compliance so I didn't bring them up.

Sure they do, by definition code that uses the extensions is not standards
compliant. Plan 9 C code makes heavy use of Plan 9 extensions. The Go runtime
also makes use of those extensions, that's why gcc recently (2009) implemented
-fplan9-extensions in order for gccgo to compile the Go standard library.

> Note that both C++ and GNU C have similar extensions but under different
> semantics which don't make them any less ANSI compliant.

I think what you mean is that GNU C is a strict superset of ANSI C and you
assume that Plan 9 C is the same. This assumption is wrong. Plan 9 C is not a
superset of ANSI C, some ANSI C things are missing; e.g. const. That being
said it's not that hard to compile C89 code with the Plan 9 C compilers.

> be careful around those documents. The assembler, compiler, parser and
> linker have seen over two decades worth of work since those were put ink to
> paper.

I should know since I use Plan 9 every day and I recently ported the Go
toolchain to Solaris and gave a talk on these tools. The compiler document is
very accurate, the only glaring anachronism is that the extern register
storage class doesn't necessarily use a register in the Go toolchain, but
depends on the target operating system. It's still true on Plan 9 though. The
assembly guide is more inaccurate, but the C papers are accurate, at least for
now.

~~~
RamiK
> Sure they do, by definition code that uses the extensions is not standards
> compliant.

I don't follow. How's having non-standard complying code taking advantage of
the extensions offered makes the compiler itself any less standard capable? I
was under the impression being standard compliant didn't mean forbidding
extensions... But I suppose I could have been mistaken. :(

> GNU C is a strict superset of ANSI C...

In the same way that I said "Plan 9's C is a restricted ANSI C variety". Yes.
It takes some good stuff from ANSI C and leaves some unnecessary stuff out by
default. Still, keeping to the standard.

> some ANSI C things are missing; e.g. const.

Surprisingly irrelevant. The draft actually said "If an attempt is made to
modify an object defined with a const-qualified type through use of an lvalue
with non-const-qualified type, the behavior is undefined.". So, regardless of
what the Plan9 doc says about giving warnings and not implementing const in a
standard confirming way, no behavior was ever expected in the first place by
the standard so the compiler is unwittingly compliant :D And volatile follows
suit...

My guess to why the standard requires to implement a keyword without
specifying explicit behavior, is that they wanted backward-compatibility with
some vendor compiler that did implement these but didn't want to force any
actual functionality.

Mind you the standard is far more lax then most people give it credit: Even
"void main()" and "exits(0);" that usually raise a few eyebrows are all
implementation-specific according to the standard and thus are compliant.

> The compiler document is very accurate...

I was thinking about
[https://docs.google.com/document/d/1xN-g6qjjWflecSP08LNgh2uF...](https://docs.google.com/document/d/1xN-g6qjjWflecSP08LNgh2uFsKjWb-
rR9KA11ip_DIE) but I'm obviously not as versed as you in the state of the
tool-chain so that's that I suppose. I personally did some work on getting the
compiler to work on a MIPS router I had a few years back but my work was
superseded by something better before I could even think about release so that
was that... It was at a pretty late stage though with most of the assembly
written down. So the impression I got at the time must have had mostly to do
with the assembler. But that's ancient history I suppose.

So, from what I can tell out of the standard and the actual behavior of the
compiler, it's complaint regardless of what it's docs say. More so, I can't
think of a lot of non-confirming compilers I came across outside the embedded
circles in recent years. Why, even MSVC is at most a custom header away per
project away from compliance and since boiler-plate was never restricted it
might as well be considered standard.

TL;DR Standards are highly overrated.

------
dhfjgkrgjg
This is a big shame. They are already familiar with the BSD license, so why
the GPL?

~~~
pjmlp
To forbid getting money leeching the work of others for free.

~~~
yxhuvud
Yes, it would be an absolutely horrible thing if someone actually started to
use the OS.

~~~
thelel
Apple gives people who want to make use of their beautiful code the finger.
Why not do the same to potential Steve Jobs'? If BSD had been licensed under
the GNU GPL, OS X would either have to have been built from scratch, or be
free software.

~~~
yxhuvud
They also backport a lot of it upstream to FreeBSD. It is not a black and
white question.

~~~
belorn
If one go by market share, the code sent back upstream are worth far less than
1% of Os X.

~~~
yxhuvud
So? That doesn't change that Apple usage of FreeBSD codebase is still a net
win for the FreeBSD project. It is still a win-win situation even if the win
isn't totally symmetrical.

