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).
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.
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.
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).
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.
Sure they can. So what? The "real" Plan 9 continues to be developed and distributed by the labs as LPL.
I don't know if the Berkley guys just got a bag of GPL code or if this is a continuous agreement, and they'll get subsequent, more recent code in the future. In the meantime, code from Bell Labs is LPL.
> The "real" Plan 9 continues to be developed and distributed by the labs
Are there still employees on the project? I had been under the impression that the entire core dev team left in 2003, mostly for Google, and that Alcatel-Lucent no longer staffs the project. Looking through the last-modified dates in the source tree, there are a handful of edits in the last few years, but not very many, and the only specific people I can find who've worked on plan9 in the past 5 years are all external to Bell Labs (e.g. the 9front people).
There's definitely more activity outside the labs than inside, however there are still a few Bell Labs people who work on it. For example, the new MIPS kernel was entirely labs work.
Networking equipment, various set-top boxes (the WDTV Live is a good example, running on a tri-core Sigma MIPS CPU; two cores are user accessible, the third is locked down to run DRM crap), some Android devices. Bunch of other embedded uses.
As I noted elsewhere, at least as of a year or two ago MIPS was likely still outselling x86 in terms of volume (but x86 is still supreme in terms of revenue because all the other architectures have far lower average unit costs).
What is the point of anything? What is the point of life. There is no point, the point is that people have fun working on things they tickle their intellect. People are motivated by things that are hard, beautiful. People are motivated by things that haven't been done before. People are not motivated by the usefulness of a thing.
Plan 9 is a research operating system, it's a platform to do fundamental operating system research. It is not a product, and its development is not shaped by commercial interest.
That being said, Coraid hardware runs Plan 9, it's embedded, you don't see it. They also make all their development on Plan 9.
"Plan 9 shows up in lots of different types of applications, making use of different benefits. It is used in embedded systems, where the low overhead is important. It is used in commercial products where the reliability and performance are important. It's used in massive supercomputers where the novel interconnections and low "system noise" are needed. What you get out of it largely depends on what you're looking for from it."
Most routers are MIPS. There are probably more MIPS devices coming out each year than ARM devices, it's just that they are in very small devices and now in fancy phones.
Last I saw, the estimated number of units shipped for ARM was around 3 billion, with MIPS and PPC at around 500 million, and x86 somewhere in the 300m-400m range.
You might be right, I might be wrong. We'll never know. I tried to find good numbers, but estimates seem to be made up; e.g. between 1 and 10 billion ARM CPUs each year. I couldn't find good data.
Either way, even if MIPS doesn't dominate anymore, it's still a huge market (probably more chips than x86), and will continue to be in the future (even though it might be shrinking).
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."'
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.
At least in the US, the fact that a contract states it is governed by the laws of a particular state doesn't mean that you have to actually go to court in that state. For instance, the lawsuits between SCO and IBM, and SCO and Novell were heard in Utah, although in some cases New York or Delaware law applied (because some of the contracts involved had choice of laws provisions).
For what it's worth, the chance that a random US judge will apply another state's laws correctly, or even coherently, is pretty slim.
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.
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)
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)
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.
> It means that you agree that all disputes will be settled in NY
It means that they will be settled using NY law, not that they will be settled in NY. An example might make things clearer.
Suppose a party in the UK enters into a contract with a party in Germany. The contract has a clause that says either party can terminate the contract provided they provide 30 days written notification to the other party. Failure to provide adequate notification can result in some losses for the other party, and so could lead to litigation. The contract has a clause that says it will be governed by the laws of New York State.
The German party wants to cancel the contract, and does so by sending an email to the UK party 31 days before their proposed termination date. The UK party does not see the email for several days, and incurs some losses. They sue the German party in German court. Let's assume that the German party conducts business throughout the world, and so the plaintiff has many choices as to where to sue (they can basically sue anywhere that has personal jurisdiction over the German party).
The key issue is whether or not the German party provided 30 days written notification. Is email "written notification", or does it have to be a more traditional form of written communication, such as postal mail or telegram? Also, 30 days from whose point of view? Does the sender merely have to send the notification 30 days or more before the propose termination date, or does the receiver have to receive it 30 days or more before that date?
Different jurisdictions might have different answers to these questions. If the contract does not define what constitutes 30 days written notification, the outcome can depend on where the plaintiff sues.
What the German court will do is look at their choice of law rules. Those rules will tell them what jurisdiction's contract law to apply when interpreting a contract between a UK party and a German party, and then use that jurisdiction's contract law to figure out what constitutes 30 days written notification. One of Germany's choice of law rules says that if the contract explicitly says what jurisdiction's rules to use, the German court will honor that.
Thus, the German court will try to figure out how New York contract law interprets "30 days written notification". If New York allows email notification, and if the 30 days is from the sender's viewpoint or the recipient's viewpoint.
This is one of the things that makes a judge's job interesting--just because you sit on the bench in Germany doesn't mean you only get to deal with German law. It gets especially interesting if you are trying to apply foreign law to an issue that has not been considered in the foreign jurisdiction. This would happen in this example if New York law had nothing to say about what "30 days written notification" should mean. The German could would then have to try to infer the principles behind New York contract law, and decide what they think would happen if the issue arose in New York.
It is important to note that the German court will NOT use New York law for things not related to contract interpretation. It will use German law for rules of procedure, rules of evidence, qualification of expert witnesses, and things like that.
A completely different thing is a choice of venue clause, although they are often confused with choice of law clauses. A choice of venue clause would say that the parties agree that any litigation over the contract will be brought in New York courts, and that the parties concede that the New York court has personal jurisdiction. You should always be careful if you see a choice of venue clause in a contract, especially if it is a foreign venue for you.
Choice of law clauses are generally pretty safe. They are essentially just shortcuts saving a lot of verbiage in the contract, so that both parties can know what any terms, like "30 day written notice", actually mean.
The FSF has argued that choice-of-law clauses in licenses are incompatible with the GPL. I believe the theory is that if things were otherwise, one could effectively apply a choice-of-law to state that a very free-software-hostile jurisdiction's laws applied to substantive issues arising in disputes over the license.
I have assumed that the FSF's doctrine on this point actually grew out of concerns over one of the licenses in the complex Python license stack, the CNRI license, which has a Virginia choice-of-law clause, close to the time of Virginia's adoption of the controversial UCITA.
Note that if a license does not have a choice of law clause, that just means one resorts to default rules about what jurisdiction's law applies to a given issue. (I.e., absence of a choice of law clause does not make the underlying issue go away.) Choice of law clauses are common in proprietary software licenses (and other commercial contracts) and are generally seen by lawyers as beneficial measures to reduce interpretive uncertainty (though obviously in 'form agreements' this is to the benefit of the licensor).
I believe the attempt to limit applicable law to the state of New York as opposed to permitting application of laws of other jurisdictions is the problem.
IANAL but:
The GPL states that if any place has laws that conflict with the license, you don't have permission to distribute software there.
The LPL seems to lean the other way in the case of New York law or US ip law conflicting with the license, and you just have to follow the laws instead of the license when they conflict.
Of course, the real conflict is probably the LPL saying
"No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation."
The GPL is "governed" by the Geneva international copyright treaty. It's supposed to be "Universal" until, eventually, being disproved in court. Which has never happened AFAIK.
...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.
yes, you can even debug processes on a different cpu architecture, over serial of you like, or a pipe, or even by hijacking dns records, or even via email, any way of organising exchanging bytes 9p is an awesome idea and when you've used plan9 for a while going back to other OSes has you constantly frustrated.
A decade (or so) ago, you could have said the same thing while leaving out "Linux" (some would argue it's still valid to leave out Linux in that claim). Things have a way of changing, and even I, as a big fan of Linux, can see its limitations and hope that, at the very least, Linux will integrate some of the better ideas from other OSes (Plan9 especially has some awesome ideas). Or, you know, Plan9 sticks to its guns and gains traction. I might even go as far as saying the world could do worse than to replace OSX and Windows with the likes of Plan9 and Inferno.
While I think the overall concept is amazing, my understanding is that the user interface stayed somewhere in the mid-nineties, and that it lacks things people tend to expect in a modern UNIX-like operating system, such as a decent browser, vim, shell history and symlinks. On the other hand, it has in some ways infected Linux (virtual filesystems), though sadly in a fairly limited fashion (think of copy-paste on steroids, built-in authentication agent). The way it is designed around a single, simple but powerful metaphor (everything is a file) is really brilliant.
Plan 9 has acme and sam. There's also a vim port, but give Rob Pike's editors a chance. The relation between Unix and Plan 9 is the same as the relation between vim and sam.
> shell history
There's terminal (not shell) history, check out the " and "" scripts. Again, things are different in Plan 9. There's no point in doing the same stuff again. The Plan 9 mechanism is an emergent property of its design (it doesn't require special code in shells), and it's scriptable (again, see " and "").
> symlinks
This makes no sense, Plan 9 have private namespaces which can do many things, including everything symlinks do.
> decent browser
The browser is probably the biggest gripe for more people. You can run a semi-recent Opera in linuxemu. I believe it wouldn't be too hard to update linuxemu so you could run a recent firefox or chromium, however nobody did the work so far. Personally, when I use Plan 9, I use it to do things I can't do in Unix, so I don't spend any effort that would enable me to do things I do in Unix. For browsing I use a mac.
> Plan 9 has acme and sam. There's also a vim port, but give Rob Pike's editors a chance. The relation between Unix and Plan 9 is the same as the relation between vim and sam.
From what I can read on wikipedia, both acme and sam are mouse-centered. This is a major philosophical change compared to vim, while my understanding is that Plan 9 is a pure expression of the ideas underlying Unix ("Unix without the hacks").
> There's terminal (not shell) history, check out the " and "" scripts. Again, things are different in Plan 9. There's no point in doing the same stuff again. The Plan 9 mechanism is an emergent property of its design (it doesn't require special code in shells), and it's scriptable (again, see " and "").
I'm afraid " and "" have both defeated my google-fu. Would you mind enlightening me about them?
> This makes no sense, Plan 9 have private namespaces which can do many things, including everything symlinks do.
I see. From what I read, that's certainly a much more powerful and cleaner abstraction than symlinks.
> The browser is probably the biggest gripe for more people. You can run a semi-recent Opera in linuxemu. I believe it wouldn't be too hard to update linuxemu so you could run a recent firefox or chromium, however nobody did the work so far. Personally, when I use Plan 9, I use it to do things I can't do in Unix, so I don't spend any effort that would enable me to do things I do in Unix. For browsing I use a mac.
This sounds reasonable. Anyway, given the limited hardware support, I suppose a VM is the way to go.
Yes, Plan 9 is mouse-centric (not only acme and sam, but rio too). Give it a chance though, mouse chording and plumbing on B3 is a very powerful thing. To make an analogy, using a mouse in Unix is like having a fist, using a mouse in Plan 9 is like having fingers.
This, along with hardware support, is why I don't run Plan 9 as my only OS. Porting a modern browser to Plan 9 would be incredibly painful, and I believe the codebase of Chromium or Firefox is larger than Plan 9 itself these days!
> vim
Someone actually ported vim, and it's pretty easy to install from contrib.
> symlinks
These are a deliberate omission; the ability to rearrange the filesystem with bind doesn't correspond exactly to symlinks since it's done as a property of the current namespace rather than stored in the filesystem, but with the idioms that are built around bind, I've never missed symlinks at all.
Sorry for going into defensive-weenie mode and attacking your positive post!
> Sorry for going into defensive-weenie mode and attacking your positive post!
No worries. One of the reasons for my post is to learn more about what's available on current Plan 9. Besides, I don't mind having my misconceptions corrected, as long as it's done politely. Thanks for taking time to do that.
Uh. The fact that the shell serializes its history wherever is an implementation detail. If there is no way to: bring up the last commands used, sequentially, with a simple shortcut like "arrow up", and search for a given command like (like ctrl-r), that's a regression in usability compared to something like bash.
But we consider Bash an abomination. All the developers have been entirely free to build a new shell and that no-one has in 20 years of development by the cream of the Unix team and use by some excellent coders shows us that this is the way we want to work.
We have no need for command history. Mostly because we use better tools such as Sam and Acme to run arbitrary shell commands.
I shall repeat, like I end up doing on most plan9 threads, I have never had the need for command history in 15 years of using plan9. Ten years of that was full time software development and system administration in plan9.
Not using an OS because it doesn't have a shell like Bash is short sighted. These kind of arguments are why most of us don't even turn up to threads about plan9. It's the same 3 things over and over. No command history, doesn't have Linux programs, doesn't have a native HTML4 compliant web browser
> We have no need for command history. Mostly because we use better tools such as Sam and Acme to run arbitrary shell commands.
Just now, I was repeatedly running curl in order to test an API, occasionally tweaking URL parameters here and there. Would you really open a text editor, type your curl line inside, and execute the result?
I'm not trying to be antagonistic, but I just have a hard time fathoming the idea of a shell without history.
But you do have command history, it's just not in your shell, because the shell is the not right place to put it. The windowing system exposes all the history as a text file, so you can use scripts that use this text file or write your own. I already mentioned " and "" in another comment. In particular, to reexecute previous command I'd just type "".
As for using text editors. Yes, in Plan 9 this is actually feasible and it's a widely used idiom. What makes it so much easier is that I can just middle-click or middle-swipe on anything inside the editor, and it would execute. So yeah, I can just type commands and edit them. When I B2 on them they will run.
Or rather I'd merely be right clicking on a URL and my environment would already know I wanted to retrieve that URL as text. If I was in Acme it would open that text in a new window, if in the shell it would just print it on stdout (if that's what I had set up).
When I say the environment knows, actually a program called "the plumber" does text matching on the strings it is sent and executes commands based upon the pattern. I could arrange for different commands to execute based upon the URL.
If I knew I was going to experiment I would be keeping a record.
As Tesla said in response to Edison's now famous "1% inspiration, 99% perspiration" remark
"If you thought a bit more, you wouldn't have to sweat so much."
(both were in a live radio debate, curiously only Edison's has entered the lexicon)
The problem is that both your attitude and 4ad reflect a somewhat toxik high-priest holier-than-you.
For example, someone enquiring about using arrow for history navigation gets an immediate response about how bash is an abimination and a rant about no-one having written a new shell in 20 years and what not.
Meanwhile, skipping entirely any discussion about how plan 9 does things better. 4ad mentioned " but failed to explain how one navgates /down/ the history. It also entirely ignores the fact that users have voted and arrows have won. They are used to navigate in text. Navigate between email messages. Practically every where keyboard-based navigation is used, arrow leys have proved both accessible, simple to understand and fast to use for the level-1 needs (next, previous, ...). Are your rants enlightening? no. They merely impress that plan 9 is not a community I'd like to join.
you can share virtually anything that can be represented as a file, including filesystems served by the kernel. e.g. "import -b $server '#A' /dev" will allow you to write to /dev/audio on a remote server.
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.
Well if you are familiar with unix Plan 9 was its successor which extrapolated a lot of the ways of doing things into a much more well defined operating environment. Things like IPC are heavily emphasised.
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]
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...
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.
It's quite fascinating, in lights of the idelogical bunfights over kdbus, systemd, and Wayland which are plaguing the Linux world, to look at what the designers of Linux did as a followup: binary IPC is baked in. Everything is a file. And so on.
These guys didn't design Linux; it would work better if they had. They created Unix.
Also, know how you do init in Plan 9? You add commands to an init file, and they run when the machine boots. If a service goes down for some reason, you GO RESTART IT YOURSELF.
> Also, know how you do init in Plan 9? You add commands to an init file, and they run when the machine boots. If a service goes down for some reason, you GO RESTART IT YOURSELF.
Are you saying that lack of process monitoring is a feature? The "add commands to init" thingie has simplicity going for it, and reminds me of the little I've seen of Arch's old init scripts, but I'm not interested in figuring out the dependency order of my services by experimentation, or giving up parallel initialization.
Correct. Just like unix. If something crashes, there is a serious problem. Restarting it blindly is typically going to do more harm than good (allowing the attacker who crashed it infinite chances to keep trying to exploit the bug rather than just crash the process). When something crashes, you fix it, you don't just restart it and pretend that is supposed to happen.
Yes, but this should never be the default. If something crashed, it's often a sign of an underlying problem that should be solved. Programs crash for a reason.
I've seen many "Windows import" sysadmins who think it's perfectly natural to reboot a server because something is not working. It's not. Automatic restart of crashed processes should be the exception (as in "we need to keep the reactor core cool") rather than the norm.
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.
Well, Linus is pretty succinct why the "It's a shame or not" discussion is not a matter of discussion, but that the matter is decided.
> And please, when you join that fight, use your _own_ copyrights. Not somebody elses. I absolutely hate how the FSF has tried to use my code as a weapon, just because I decided that their license was good.
and about having a poll deciding the matter
> Here's a poll for you:
> - go write your own kernel
> - poll which one is more popular
I very often dislike Linus style of discussion, but that one was pretty clear and straightforward.
Normally the "Write a kernel and come back when you've won" is a bullshit argument, but the GNU Hurd kind of predates Linux, and would be an acceptable candidate to that argument...and has lost.
> Normally the "Write a kernel and come back when you've won" is a bullshit argument
Actually, I don't think it's a bullshit argument in cases where the fundamentals are here: Somebody calls a vote on the license of code that was largely written by the the other person. That other person is totally entitled to say "Hey, go, vote on the license of your piece of code and not on mine."
> Your reply amounts to "Your opinion differs from Linus's opinion, and is therefore wrong."
More like: "Someone other respected person believes otherwise, and here is their justification. This other position may be a better one, for the reasons they give."
The parent poster expressed a blanket statement. Because there's no subject (or, because it's implicit that the subject is "everyone") they are an invitation for discussion.
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.
The original author has a right to decide what license to use, but not what other people feel is the right choice.
If linus decided tomorrow to make new software under a license that only allowed white people to use it, I would consider it wrong and a racist license. I reject your claim that the author has the right to establish such license as "right".
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.
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.
> 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.
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.
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?
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.
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.
Don't we have enough proprietary builds of FLOSS projects?
Every time I look at Android phone or TV or a router I regret that BSD/MIT/Apache is so popular. Those devices run tivoized proprietary builds of what consists mostly of free software, but builds are shitty or just restricted (want a proper firewall? never mind it's there go buy next-tier device). And users can't do anything about that.
Users and GPLv3 deserve more love. They're already screwed by everyone and their pet code monkeys.
The more restrictive your licensing, the less likely many developers are to use it now. Although I'd readily admit that applies to some industries more than others.
As an example, John Carmack (formerly of ID Software) recently posted this on twitter:
GPL never did really do anything for game code, and I do
wonder whether it was a fundamental cultural
incompatibility.
When I was merely a user of free software, I too believed as others did, that a more restrictive (or "stronger" if your prefer) copy-left license was better. However, the more years I've spent in the software industry, the more my opinion has varied.
I think it ultimately comes down to who the primary "users" of your code are. If it's an application, it's probably ok to use more restrictive licensing. If it's a library, or code that's in any way intended to be reused by others more generally, the licensing should have very few restrictions if you want to encourage wide usage and to discourage others from duplicating the work.
I really liked the criteria that http://www.gnu.org/licenses/why-not-lgpl.html outlines regarding lgpl or not. It's the same criteria I use to decide whether to use a strong copyleft license or not:
>The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.
>This is why we used the Lesser GPL for the GNU C library. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another—no problem for them, only for us.
>However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline.
You're twisting "users" to mean "programmers that have the time and interest in spending it on hacking their gadgets."
There is a huge difference here: the vast majority of people don't mess with their routers (heck - I'm a programmer, and I code at home and at work, and I don't mess with my router). So the people you're talking about are a very, very small group.
I'm not saying that this is a group of zero size. All I mean is: compare the total number of people that are into their wrt54g routers with the total number of routers out there. Users aren't idiots; they just have other things they'd rather be doing than messing with their wireless routers.
You imply that they're paying too much for their routers, given the features they have. Who are you to say what a feature (of a product you don't have to support) is worth to another person? If you think you can do better, no one is stopping you from making and distributing routers that you'd like, either for sale or for gratis.
> You're twisting "users" to mean "programmers that have the time and interest in spending it on hacking their gadgets."
Nope, I meant users. Who want products to work.
I'm not willing to hack my phone myself, in fact I don't have resources to do that. But I'm willing to pay someone to do that. Yet, I can't, because the necessary extent of reverse engineering would cost me a fortune. So, I learned to live with what I have.
> the vast majority of people don't mess with their routers
Does that prove anything? See, I don't mess with my phone and my TV, too. Does that mean I'm really satisfied with those? Nope, I just tolerate them.
Imagine there's a patch that automagically improves your network experience by configuring QoS features your router already has (but has no UI for them). Would you install it? If you'd have to crack your router open, solder a serial port, run a TFTP server and risk bricking the device - you probably wouldn't. If you'd have just download a file and click a button or two and have a new feature (not complete router reflash to a new firmware) - I guess you quite likely would consider so.
> Who are you to say what a feature (of a product you don't have to support) is worth to another person?
Uh. Someone, who heard some those other persons complaining? I must admit, this is a subjective opinion, I do not have proper statistics that can make things objective.
However, you're right, routers were a bad example. Average user rarely has an opinion on those just because they don't really consciously interact with them. "Smart" TVs and phones are much more common source of complaints. And the point was not about pricing. It was about inability to control what you have.
Where to even begin. First of all, plan 9 is already under a BSD style license, it always has been. They just also let people have it with extra restrictions now (the GPL) because RMS is a lunatic and insists that some licenses are not GPL compatible because they contain a clause he thinks would make it a contract. Despite the obvious fact that the GPL is legally a contract whether he likes it or not.
>Every time I look at Android phone or TV or a router I regret that BSD/MIT/Apache is so popular
Android is built on the linux kernel, which is GPL. You are proving yourself wrong with that example.
> And users can't do anything about that.
Of course they can. If they do not want that, they can choose not to purchase it. It isn't rocket science. You are simply upset because actual users are proving you wrong, and showing that they don't give a shit about things being GPL. Your "but think of the users" histrionics are so transparently fake it is insulting everyone's intelligence to continue repeating it.
Proprietary software would still exist without free software. People who write software can do whatever they like with it, and it is incredibly self-absorbed and arrogant to suggest that giving away something they made is a problem because it violates your arbitrary belief system.
Such horrible hatred in your post. What in the world has caused you to become like that?
Did someone offer you software, with no cost attached, and promises that you can modify and share it, and then it was not enough? You wanted to also have the right to threaten your users with lawsuits if they in turn did the same thing as you just did to the program?
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
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.
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. :)
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...
> 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.
> 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... 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.
When you ask "why did big company X make strange choice Y regarding licensing or IP", 99 times out of 100 the answer is "lawyers". If the Plan 9 group had had its way, Plan 9 would have been released for free under a trivial MIT-like license (the one used for other pieces of code, like the one true awk) in 2003 instead of creating the Lucent Public License. Or in 2000 instead of creating the "Plan 9 License". Or in 1995 instead of as a $350 book+CD that came with a license for use by an entire "organization". Or in 1992 instead of being a limited academic release.
Thankfully I am not at Lucent anymore and am not privy to the tortured negotiations that ended up at the obviously inelegant compromise of "The University of California, Berkeley, has been authorised by Alcatel-Lucent to release all Plan 9 software previously governed by the Lucent Public License, Version 1.02 under the GNU General Public License, Version 2." But the odds are overwhelming that the one-word answer is "lawyers".
I agree the 2000 and 2003 releases' strange custom license terms sound lawyer-driven, but weren't the 1992 and 1995 releases' terms also driven by hopes of commercial exploitation? My impression was that during this period AT&T still hoped they'd be able to license Plan9 for $$$ to a vendor, like they had done with Unix, which meant they wouldn't want to release the code under a permissive license.
Yes, but who tells you "you can't do that because we want to keep open the possibility of making money later"? The lawyers.
AT&T gave away Unix during Unix's formative years, because AT&T's government-granted monopoly disallowed it from making money on computers. They didn't make any money on Unix then. They tried later, and made some, but what a sense of loss about what might have been if only they'd been charging from the beginning! Of course, if they'd been charging from the beginning, it's hard to say Unix would have been so popular.
If you don't want to see a proprietary fork of your code, you should use GPL. If you don't mind seeing proprietary forks of your code, you can use BSD, Apache, MIT or any other more "permissive" license.
I don't think Plan9 has much commercial value in it left, but they may consider it would be awkward if, say, EMC or Cisco incorporated some of its technologies (Plan 9 had some interesting ideas about storage and network transparency) into their proprietary products without paying for them. It's easy to sympathize with the small garage inventor and to think it's nice for you to subsidize small innovators, but it's much harder to do the same with corporations that would patent-extort you the moment they realized they could gain some advantage from it.
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.
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.
Finally someone that actually understood what I meant. Gaining traction is a lot more important for getting work done than the contributions back from *GPL ever has been.
This argument is consistently colluded with the other argument for open and transparent software. They are two topics independent of each other, IMHO. If you care about open software, it does not imply you care about preventing others from using your software in a leechy fashion.
So you acknowledge today some people do already leech as you put it, under the GPL. It may be a violation, and the other party may laugh as they are in a different juridiction.
So, what was your point again?
We have a law against theft, yet there are continous occurences of people stealing and getting away with it, so by your logic we should remove the law against theft.
If you look at the note on the home page[1], they needed to get permission from Alcatel-Lucent for the license change. They may not have been able to sell them on BSD.
This isn't a shame, it does nothing. Plan 9 was already released under a BSD style license (one with an absurd amount of pointless legalese, but non-copyleft nonetheless). This is simply releasing it with additional restrictions so that people who are contributing to GPL software can use it now too.
Plan 9 as distributed by the labs continues to be LPL (not GPL and not dual licensed).