| |||||||||||||
Possible routes to kernel on GPLv3Possible routes to kernel on GPLv3Posted Jan 26, 2007 14:10 UTC (Fri) by smurf (subscriber, #17840)In reply to: Possible routes to kernel on GPLv3 by beoba Parent article: GPL 3: An Open-Source Earthquake? (CRN)
90% doesn't cut it. You need 100%. You won't get 100%. End of story.
Consider that several developers don't want GPLv3. (Linus among them...) So they claim their pieces of code but do not relicense them. What do you do -- spend a year rewriting half the kernel AND lose a few important contributors?
NFW.
(Log in to post comments)
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 14:59 UTC (Fri) by coriordan (guest, #7544) [Link] Nope. Programmers seem to link that law is executed on computer processors, but it's not.
You need about 95% of copyright ownership, and you have to remove any of the 5% if any owner requests their code is removed.
This is how Mozilla moved from the MPL to a triple MPL/GPL/LGPL licence.
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 15:53 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Still doesn't cut it. 10 first-line kernel hackers have publicly disagreed with GPLv3, there are probably much more who think likewise in the rank and file. Sure, if you could get 95% GPLv3'd, you'd be in the clear; but I guess those 10 are responsible for something like a 30% of the kernel (mostly core stuff, that can't just be configured out). Plus if they walk away, then Linux is no more (it isn't the current source code, but its development dynamics what makes it successful).
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 16:13 UTC (Fri) by coriordan (guest, #7544) [Link] > Still doesn't cut it My explanation of why relicensing is possible doesn't cut is as an explanation for why it will happen? Of course, but that's because you changed the topic. C'mon. So, onto the topic you raised: will the developers be willing? There are three factors that point to "maybe". One is that Linus loves digging his heels in and TALKING _like_ *this* and saying never never never, but he also doesn't mind changing his mind after all that. That's his management style, he even documented it somewhere. The second is that in the Linux developers survey that came out against GPLv3, one person later said they hadn't read GPLv3 - how many others hadn't read it? And thirdly, we can't predict the future. No one guessed that Novell would jump into bed with MS. We don't know what other nasty tricks are in store which might make it clearer why a really solid licence is necessary.
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 17:19 UTC (Fri) by vonbrand (subscriber, #4458) [Link] > Still doesn't cut it Sorry, keyboard faster than brain there. So, onto the topic you raised: will the developers be willing? AFAICS, Linus' position is essentially that getting Linux on some appliance doesn't automatically mean I'm entitled to run something else on it. I also think it is quite reasonable to lock in (via signed code) what configuration the code can do to some appliances. When devices where controlled mechanically, they were designed with built-in stops and limits. Today, when the control is much more detailed, it is more and more done in software. Plus software is much easier to change than, say, sawing off a pesky stop somewhere., and changes in software aren't as easy to see in their effects (remember any bug you've chased for days lately?). Plus a software change is easy to revert ("Oops, with my modification it ended up screwing up, let's replace it by the original and go complain to the vendor..."). So yes, it does (sometimes) make a lot of sense restricting what software the buyer can run on the machine. Plus the flexibility that easily field-replaceable software gives is vital in some uses, so "just place it in ROM" doesn't cut it either. So yes, I do think the DRM (and some other) restrictions in the draft GPLv3 (which I did read, IANAL in any case) are trying to solve a problem (current DRM frenzy) by (a) attacking the wrong problem, (b) with the wrong (non)weapons
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 17:47 UTC (Fri) by coriordan (guest, #7544) [Link] There are definitely grey areas, but people seem to see these and then think that therefor no line should be drawn, but that leads to the situation where there's no reason for a manufacturer not to tivoise all the software on the device. They get full control, and the customers get no freedom to help themselves or cooperate with each other as a community. Many companies see that as a win, but for computer users, in terms of having those freedoms, it's a complete loss.
So where to draw the line? GPLv3 draws the line at network installs. Whatever parts of the software can be upgraded by the manufacturer over the network have to also be modifiable by the owner.
If a regulation requires that a certain software-controlled feature be restricted, it can go in ROM. That will usually be a tiny amount of code, maybe it will just be two numbers.
If the manufacturer wants to restrict more than is necessary, then that's just a violation of the spirit of the GPL and it's the GPL's job to stop that.
So GPLv3 encourages manufacturers to put as little as possible in non-user-modifiable memory by mandating that that part of the software also be non-manufacturer-modifiable.
In all the noise that this has generated, I don't think anyone's made a list of how many companies this will affect? A friend in one of the World's largest medical device manufacturing companies confirmed to me that they don't use tivoisation in any of there devices - and yet the example of medical devices has often been used to say that GPLv3 goes too far.
The other ways to tackle the current DRM frenzy are to either (a) use our market pressure, but that's just choosing to fail since we have a track record of never using our market pressure effectively, or (b) shake off the power that the content industry has over us by moving to free content - this means discarding all culture made in your county and my country in the last century, and It won't happen.
Our licences can't do everything, and not everything will be happily black and white, but we've got to do what we can, and if you've a better way to draw the line through this grey area, gplv3.fsf.org is asking for your input.
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 19:16 UTC (Fri) by sbergman27 (guest, #10767) [Link] """gplv3.fsf.org is asking for your input."""
While I recognize the importance of keeping up appearances, it would be nicer if anyone there were actually listening.
GPLv3 is Richard's baby and no one else's. Never forget that.
Possible routes to kernel on GPLv3 Posted Jan 30, 2007 7:37 UTC (Tue) by drag (subscriber, #31333) [Link] ""GPLv3 is Richard's baby and no one else's. Never forget that.""
Oh, bullshit.
I mean seriously, how can you say stuff like that? The GPLv3 is probably the most debated, most reviewed, most discussed software license in history. (while still in draft, were changes can actually happen) There are thousands of people, hundreds of orginizations, intellectual property owners from all around word have given input and had questions answered (some in more general ways then others). Everything rom small Free software groups to multi-billion dollar corporations.
If you don't like it, thats fine. But at least have a realistic view on it and the amount of people that think it's pretty good stuff.
Samba, for example, have already stated that they are moving to it. Sun Microsystems seem to like it pretty well also.
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 19:22 UTC (Fri) by bronson (subscriber, #4806) [Link] Despite what you say, coriordan, I think the market is a very clear reason for the manufacturer not to Tivoise. Think of what Linksys's sales would have been if they had Tivo'd the WRT54G? Significantly lower, that's for sure. Same goes for Archos products. That's two examples and I'm sure I could find more. Your claim that "we've never used our market pressure effectively" is, I think, demonstrably false.
Another reason: the cost. The extra hardware and development time will add to the price of the unit. Most companies won't care what software you run on their box, so they won't bother to lock it down.
Finally, what do you mean by "DRM Frenzy"? I only see DRM on music and movie media. That's hardly a frenzy. And since shiny round discs are pretty much obsolete (you watch), that just leaves Microsoft's Vista-compatible video cards. I think you can see why I'm not terribly worried. And, no, I don't think DRM will catch on in the future either.
It's like making huge sacrifices to save customers from Divx (the Circuit City DRM disaster). Why bother? The customers will save themselves and you can expend your effort on more important things. No need to knock yourself out.
I just looked at gplv3.fsf.org and nothing has changed since September 26th?? That might explain why, in the last 4 months, GPLv3 discussion on LWN doesn't appear to have changed at all. It's the same old arguments, and the same old outcomes (agree to disagree).
So, are we going to see some changes at any point? Or discussion on DRM? Since your committee meetings are private (oh, the irony), I have no idea what the FSF has done in the last 4 months. Heck, it doesn't look like anything at all has changed since 26 August.
I must say, I find the GPLv3, and its decidedly non-free development process, very disappointing.
Possible routes to kernel on GPLv3 Posted Jan 26, 2007 23:49 UTC (Fri) by sbergman27 (guest, #10767) [Link] """I must say, I find the GPLv3, and its decidedly non-free development process, very disappointing. """
I'll second that. Though I can't claim to be disappointed, as I expected it to go this way.
As I've said previously, GPLv3 is Richard's baby and *no one* else's.
It will be what Richard want's it to be, and other's opinions do not factor in. He is doing what he can to maintain the appearance of an open process because he must. But it is all a facade.
-Steve
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 0:04 UTC (Sat) by alexbk (subscriber, #37839) [Link] The lawyers of Sun and Nokia, who, unlike you, are actually involved with GPLv3, disagree.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 0:14 UTC (Sat) by sbergman27 (guest, #10767) [Link] My suggested modifications have been entirely ignored. No response whatsoever. Although I did get an automated response on one occasion emphasizing how important each and every comment and suggestion is to the FSF. No actual response to that one, either. On the rest it was just silence.
I would be interested in seeing the responses you have gotten back from the FSF regarding modifications to the GPLv3.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 0:39 UTC (Sat) by alexbk (subscriber, #37839) [Link] Nowhere they had promised you'd get a personal response; I reckon with the amount ofsuggestions they get answering each one individually would be unpractical. I agree that some kind of feedback on suggestions (such as "read by Eben Moglen on this date") would be good. However the many refinements between draft1 and draft2 indicate that they do listen to what people say, unless you asked them to drop anti-Tivo language or other major points.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 0:49 UTC (Sat) by sbergman27 (guest, #10767) [Link] """unless you asked them to drop anti-Tivo language or other major points """
It appears that we mostly agree. There have been no significant changes to GPLv3 from draft 1 to the present. There are unlikely to be any between now and its official inception. And the FSF is not expected to give any reasons.
For a moment, there, I thought we might *disagree* on these things. ;-)
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 3:15 UTC (Sat) by Arker (guest, #14205) [Link] When you open *anything* up to public comment like this, it goes without saying that comments which amount to 'your goals are completely wrong, you should scratch the entire idea' aren't likely to be implemented. So what? Do you really expect them to read your peanut-gallery screechings and suddenly withdraw the idea and announce that v2, riddled as it is with known exploits, is perfect forever and all time? Please, get real.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 18:33 UTC (Sat) by bronson (subscriber, #4806) [Link] I don't remember the kernel guys saying that.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 23:31 UTC (Sat) by Arker (guest, #14205) [Link] Well that's exactly what some of them have said, boiled down to the essentials. They like the loopholes that v3 is being designed to close. The only way to make someone taking that position happy with v3 would be to abandon the fundamental reason for the existence of the GPL, all versions of it.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 0:07 UTC (Sun) by vonbrand (subscriber, #4458) [Link] They like the loopholes that v3 is being designed to close. They haven't say such a thing, they said that GPL should not try to get into areas that aren't properly a code license's. Also, GPLv2 gives certain specific rights, what is wrong with with wanting to give just that ones? Sure, GPLv2 would gain a lot by cleaning up the language, and making it (more) compatible with non-US laws. Besides, the 4 freedoms (and GPLv2) haven't ever talked about "If you get a device running free code, you are entitled to run anything else you want on it". I can certainly see uses for open source that require (for complying with regulations, for safety, etc) running only certified programs. Sure, the most talked about case is restricting users access to digital content, but nothing GPLvX could do will make any difference for or against that, but it will hurt other uses badly.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 0:57 UTC (Sun) by b3timmons (guest, #40286) [Link] They haven't say such a thing, they said that GPL should not try to get into areas that aren't properly a code license's. Also, GPLv2 gives certain specific rights, what is wrong with with wanting to give just that ones? Sure, GPLv2 would gain a lot by cleaning up the language, and making it (more) compatible with non-US laws. The GPL has always applied to distributors, so why should it not be adjusted to whatever new distribution methods such as Tivos that have developed in a decade and a half (incredibly long in this biz) since v2? To limit rights as in v2, are you not aware of the exceptions language in v3 that allows certain restrictions to be imposed? Besides, the 4 freedoms (and GPLv2) haven't ever talked about "If you get a device running free code, you are entitled to run anything else you want on it". I can certainly see uses for open source that require (for complying with regulations, for safety, etc) running only certified programs. Sure, the most talked about case is restricting users access to digital content, but nothing GPLvX could do will make any difference for or against that, but it will hurt other uses badly. Just a trivial google search on the terms "gplv3", "medical", "devices" gives as the top hit: http://fsfe.org/en/fellows/ciaran/... which is a recent summary of thought which has existed for some time now and which throws your concern here into doubt. The bottom line is that the GPL has always aimed to uphold the four freedoms, and with this protection now diminished from loopholes, v3 is needed to fix them.
Certifiable Posted Jan 29, 2007 23:07 UTC (Mon) by GreyWizard (guest, #1026) [Link] Many things (glassware, candles, ladders, power tools) that might maim or kill someone if carelessly handled, yet I am allowed to own and even modify them if I comply with regulations myself. So I'm afraid I can't share your enthusiasm for a world where I am denied as many choices as technologically possible in the name of safety. I would rather assume responsibility for my own actions and live in a free society.
Also you are mistaken about the "four freedoms" enumerated by the FSF. Number one is "the freedom to study how the program works, and adapt it to your needs." To do that I must be able to run modified software on the devices I actually own unless we suppose I have unlimited resources. Releasing software under a license that ensures this freedom more strictly than GPLv2 might not change the world but it seems worth trying -- after all the same thing was said about GPLv2 once.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 6:07 UTC (Sun) by bronson (subscriber, #4806) [Link] "[The kernel guys] like the loopholes that v3 is being designed to close."
Arker, that's an absurd thing to say. Most of them are very happy with v3, they just think it goes a little too far when it comes to DRM. Where did you get the idea that they want it full of loopholes?
Possible routes to kernel on GPLv3 Posted Jan 29, 2007 22:20 UTC (Mon) by Arker (guest, #14205) [Link] I did say *some* - I'm quite aware that there is considerable difference of opinion.
But the ones who have been making the anti-gpl noises are indeed propounding a position that says the loopholes are good, they don't need to be addressed. They say they don't *want* to prevent companies following Tivos lead and effectively making the software non-free. As long as that's their position, they won't be interested in version three, they're going to stay with version 2, and they aren't likely to have anything useful to contribute to the v3 discussion, since they don't agree with the purpose of the thing to begin with.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 17:51 UTC (Sat) by coriordan (guest, #7544) [Link] When you submit a comment, it is passed on to 4 committees of about 130 people. They consider the comment and try to form consensus on what, if anything, should be done. They then pass that on to RMS who makes the final decision. According to members of the committees, which are mostly made up of non-supporters of FSF, RMS is changing the GPL drafts in response to their input. Links to the committee membership lists are here:http://www.fsfe.org/en/fellows/ciaran/ciaran_s_free_softw...
And here's the newsforge article where committee members say that RMS is acting on the comments:
The goal is to write a licence, so yes, when you submit a comment, the committees work on the licence instead of contacting you for a dialogue. That seems like the smartest use of the committees' time.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 19:00 UTC (Sat) by bronson (subscriber, #4806) [Link] Everything seems open when you're a member of the secret committees? That's hardly surprising.
Besides, that article is from 5 Aug 2006. The kernel position statement was from 15 Sep 2006 (http://lwn.net/Articles/200422/ ). I wonder if you'd find such unanimous adoration for the gplv3 process now.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 15:21 UTC (Sun) by coriordan (guest, #7544) [Link] It's not like that at all. And FWIW, I'm not on any of the committees and I'm not privy to any private info from or about the committees.
Each committee decides how they want to work.
Committee D is the hackers+community committee, and they like transparency and inclusion. They decided that membership is open to everyone, which includes you. (Someone else on this page already mentioned that they joined that committee and got replies from Eben Moglen about some of their comments.)
Committees A to C are lawyers, corporations, and projects. They decided their discussions should be private. That's a good idea. While I'm disappointed that I won't get to hear what each person says, I know that they wouldn't say anything if their conversations were viewable to the public and the media - or worse, they'd lie for tactical/market reasons or use the forum as a PR tool.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 14:42 UTC (Sat) by vonbrand (subscriber, #4458) [Link] The kernel is a much larger body of text, and you mostly get some king of response even when you shoot your mouth off. And it is not that this isn't a higly specialized area of work, where the result has to be checked and refined by specialists, and where we have Our Great White Leader, who has claimed that his job is mostly saying "No". Why would something like this not work for creating a community-agreeable license?
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 22:21 UTC (Sat) by grouch (guest, #27289) [Link]
Law is not C code. I can fiddle around with the kernel, determine the value of the output within the time it takes to compile and boot, and nobody will get sued as a result. If I fiddle around with a software license, the output may not be noticed for years and could very well be the cause of severe hardship for lots of people. My opinion regarding some new patch in the kernel might be useful to the developers, if I can present some logical basis for my opinion or some real-world experience to back up that opinion. My opinion regarding whether or not the word "convey" needs to be in GPLv3 is of no importance to anyone, because I don't have a clue about the legal jurisdictions in which it holds significance. The effect of "return 1;" is not something that will change if you compile the kernel in the U.S. one day and Libya the next. Anyone might demonstrate the effects of changing such lines of code. The effects of using "convey" versus "propagate" versus "copy" are not so easily and universally demonstrated. Anyone can suggest an intended or hoped-for effect, but how to achieve that effect in a license is not something one can determine by reading a man page or some source code.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 0:22 UTC (Sun) by vonbrand (subscriber, #4458) [Link] Law is not C code. I can fiddle around with the kernel, determine the value of the output within the time it takes to compile and boot, and nobody will get sued as a result. If I fiddle around with a software license, the output may not be noticed for years and could very well be the cause of severe hardship for lots of people. Exactly the same could somebody who is a lawyer say about writing a kernel. Yes, both are complex, specialized endeavors. Yes, in both cases specialists most have the last word. But in both cases the end result will have to be agreeable to its users, be it software users or developers releasing code. If either group isn't happy, the code or the license will be moot. And I fear GPLv3 will be a complete non-starter, when it could have been a step forward.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 1:23 UTC (Sun) by b3timmons (guest, #40286) [Link] Exactly the same could somebody who is a lawyer say about writing a kernel. Yes, both are complex, specialized endeavors. Yes, in both cases specialists most have the last word. But in both cases the end result will have to be agreeable to its users, be it software users or developers releasing code. If either group isn't happy, the code or the license will be moot. And I fear GPLv3 will be a complete non-starter, when it could have been a step forward. Users and developers have had opportunities over and over again to join the process and make their voices heard, so no one has any excuse to complain about lack of opportunity to participate. Torvalds refused to participate because of his admitted dislike of committees. Should some special allowance have been made for him and the kernel guys? Do you realize how unfair that would look to other projects, several of which did participate in the process? Most GPLed software is licensed v2+, so I see no basis at all for your fear that v3 is a non-starter. You comment as if the kernel guys were somehow representative of GPL users in general, which is silly given how nearly all projects have nothing to do with Tivoization. Even the kernel guys are not as against v3 as you might think, with about 30% of the code currently licensed v2+.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 14:09 UTC (Sun) by grouch (guest, #27289) [Link]
Lawyers must be a different kind of animal where you live. If you ever get a lawyer who says he or she can quickly and precisely determine the effects of changing a few words in a legal document, run away! You can do such changes with software code and the results will be apparent when anyone, anywhere, properly compiles and tests that code. Judges, lawyers, courts and legislatures do not perform the same function as a compiler. The process used for drafting GPLv3 is unprecedented. I can find no instance of any other software license ever being created by soliciting feedback from the world.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 2:10 UTC (Sat) by b3timmons (guest, #40286) [Link] The v3 drafting process includes both a Committee D which anyone can join and a commenting system upon the current draft. The archive for D's mailing list shows that Eben Moglen himself has responded to some of the emails from members of the public who joined the committee.
I may expect a reply to my post in any public forum or mailing list, but I am certainly entitled to nothing. OTOH, no reply does not imply that my comments are ignored.
Unless there an error in the above facts, I cannot see how people feel that the drafting process is in any way not open. What am I missing?
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 18:25 UTC (Sat) by bronson (subscriber, #4806) [Link] Committee D is a ghetto The last discussion appears to be 28th March. Looking over the minutes I feel that D must be a committee in the worst sense of the word: a lot of non-authoritative people describing what they're working on and not producing a single thing other than me-too blog posts. The word "TPS Report" comes to mind...James Blackwell's "how GPLv3 fights DRM" or Don Armstrong's "DRM and Authentication" look particularly interesting to me. Alas, I can't find anything either on gplv3.fsf.org or via google. Since nothing has happened since March 2006, if at all, I hope you understand why I feel disinclined to participate in committee D. Here's a crazy suggestion: open up the discussion. Maybe some mailing list archives, a forum, a regularly updated blog? This stuff is trivial; it takes all of 1/2 hour to set up. It sure would help; right now, gplv3.fsf.org looks totally abandoned. And why have secret police committees? I would really like to know what the GPLv3 drafters thought of the Kernel document. Since gplv3.fsf.org doesn't even acknowledge that the kernel guys exist, what can I do? File a Freedom of Information Act subpoena?? Just imagine if the FSF wrote software using this process! The whole gplv3.fsf.org process demonstrates the very definition of "not open." Don't get me wrong; I can't wait until we have an updated GPL so the Microsoft-Novell hole can be plugged. I just wish the current draft were so encumbered with phantom issues. At this rate, it will take 4 more years to release and, when it finally does get shoved out the door, it will be identical to draft 1 of almost a year ago. Not good.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 20:46 UTC (Sat) by bronson (subscriber, #4806) [Link] I realize I worded my previous post little ranty (shouldn't write before morning coffee).
Here's what I was trying to say:
- I have no interest in becoming part of a committee that has no charter and no direction. Committees need definite, achievable goals to pursue.
- gplv3.fsf.org appears to be abandoned. The last publicly-visible updates were from Q3 of last year.
- There has been no action whatsoever on the gplv3 in the last six months. The 27 July draft is still the most recent.
- There's basically no readable discussion to be found on gplv3.fsf.org (the "Comments" page has become impenetrable).
- There has been tons of very good, very readable discussion on LWN, Slashdot, and LKML. Why is this? Why can't it happen on gplv3.fsf.org?
- Why hasn't the FSF dignified the LKML position statement with a clear response? They seem to reject all the kernel developers as fringe outliers.
- There's no way for me to learn more about why the FSF is making these decisions because everything is done behind closed doors in proprietary committees. What happened to freedom?
I just hope that the GPLv3 manages to survive this process.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 21:33 UTC (Sat) by b3timmons (guest, #40286) [Link] bronson,
Eben Moglen immediately responded to the kernel guys in the media and in his blog:
http://emoglen.law.columbia.edu/blog
Indeed, the kernel guys were always invited to participate from the very beginning. I recall that Torvalds was upset that he did not get an advance copy of an early draft. He wanted special treatment that no one else was getting. I also recall that he expressed no desire to participate in a committee. Are you not aware of all of this?
If you bother looking up the Committee D mailing list archives, you will find plenty of discussion on issues such as whatever concerns you have.
In general, nothing you have written has in any way been against their schedule, which is listed at the end of a document that it seems you ought to understand better:
From http://gplv3.fsf.org/process-definition:
1. 16-17 January 2006: Initial Conference; release of first public draft
I do not know for sure, but I suppose the MS-Novell deal has been an important distraction of Eben Moglen from other concerns. However, there are people with impressive expertise on Committee D. For example, there is Seth Schoen of eff.org who has written thoughtfully on Treacherous Computing.
Please try to do some more reading before making unfounded claims.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 7:41 UTC (Sun) by bronson (subscriber, #4806) [Link] That process definition shows how far behind schedule the GPLv3 is. It's now basically February 2007 and the third discussion draft is 4 months late. The "latest possible release date" is less than 8 weeks away. Even if they got draft 3 out today, that's hardly enough time to have any meaningful discussion.
Eben Moglen's blog entry sounds nice. "I invite them to represent themselves in any way they choose, and pledge to work with them to create, even at this late date, a form of participation in the deliberations about GPLv3 that would reflect their preferred means of work, and be appropriate to their position in the community of developers."
Except that never happened. Maybe Eben didn't realize that they _were_ participating using their preferred means of work? Their position statement was quite clear. Why didn't he just reply to it in his blog entry? In fact, I can't find a clear, authoritative reply anywhere. Just the clarification page which is so dismissive that it's not clear the author even read the kernel position statement.
Thankfully a number of people have posted clarifications here on LWN (thanks especially to coriordan), so I feel that the patent situation is actually in pretty good shape. I look forward to reading draft 3.
You suggested I google for the mailing list, "which you will find shows a lot more activity for Committee D than you suggested." So how am I supposed to know that Committee D mailing list archives even exist? I can't read minds. Lessee... 4 messages in November and none since then? Doesn't that demonstrates exactly the sort of inaction that I was talking about?
I agree that some discussion must be private. But almost all of it? You've got to be kidding me. That's an absurd claim to make. Sure, have one private mailing list/committee, but why not try to have at least *some* important discussion in the open?
I feel that I'm now fairly well informed (thanks for the links), and the whole process still looks decidedly non-free. Sorry. The FSF has a lot to learn about how to have an open discussion and how to set up an usable web site!
Please please please release a draft 3 in time for the kernel guys to have a few weeks to comment on it? After Eben's hard work on the Novell disaster, and the patent clarifications, I think we'll find that the two sides are much closer to agreement. But we'll never know if there's no draft 3, or no time to comment on it.
b3timmons, thanks for taking the time to respond.
Possible routes to kernel on GPLv3 Posted Jan 28, 2007 19:11 UTC (Sun) by b3timmons (guest, #40286) [Link] That process definition shows how far behind schedule the GPLv3 is. It's now basically February 2007 and the third discussion draft is 4 months late. The "latest possible release date" is less than 8 weeks away. Even if they got draft 3 out today, that's hardly enough time to have any meaningful discussion. Please read carefully: the third draft was only listed as possible, not certain. Given how long ago the process was announced and how easy it was for me to find ways to participate, I just do not buy any excuses of not being able to have meaningful discussion about it. Except that never happened. Maybe Eben didn't realize that they _were_ participating using their preferred means of work? Their position statement was quite clear. Why didn't he just reply to it in his blog entry? In fact, I can't find a clear, authoritative reply anywhere. Just the clarification page which is so dismissive that it's not clear the author even read the kernel position statement. You are leaving out this part from Moglen: I appreciate the positions taken publicly by the kernel developers. To be clear, the process of deliberation in which FSF and everyone else has been engaged since January is not only a process of taking positions. It also involves listening to the positions others have taken: it's the effect of listening as well as talking that gives deliberative democracy its effectiveness as well as its legitimacy. I think you misunderstand what it means to participate. Participating means agreeing to minimum standards expected of everyone. In this case it meant a process of not only speaking but listening -- even to others who may not entirely agree with them. Yes, they could have participated using their preferred means of work, as long as that involves listening at some level. Moglen tried to give them special treatment here, but even this was not good enough. You must admit that they were in effect asking to be treated with more favor than other participants. Again, a warning sign was Torvalds expecting to see an early draft before other participants. How can issuing the position statement publicly at a relatively late date to put Moglen on the spot not be seen as a political move? A clearly unproductive thing is exchanges of position statements and critiques which are simply at too large of a granularity to make any sense here. Even the deliberation on lkml does not function in any way like this. Moreover, I think all of us should appreciate that deliberative processes have many challenges, such as maintaining a high S/N ratio, and that there must be inevitable tradeoffs, such as representation. So I am glad Moglen did not respond too much in his blog, since I think that would have threatened the process itself in any number of ways. Think about it. You suggested I google for the mailing list, "which you will find shows a lot more activity for Committee D than you suggested." So how am I supposed to know that Committee D mailing list archives even exist? I can't read minds. Lessee... 4 messages in November and none since then? Doesn't that demonstrates exactly the sort of inaction that I was talking about? The D resources page notes the mailing list, hence the guess that there must be archives. The only demonstration is just a matter of degree of activity. I think you wrote earlier that the last activity was March, but now it is November. However, I fail to see your point about activity. Different activity levels occur in many different projects for many different reasons. Claiming a certain standard here requires far more substantiation than you have given. I agree that some discussion must be private. But almost all of it? You've got to be kidding me. That's an absurd claim to make. Sure, have one private mailing list/committee, but why not try to have at least *some* important discussion in the open? No one entity claimed or prescribed any level of privacy for the process as a whole, of course; the participants themselves set their own terms. In at least one of the committees with some privacy, Committee B, we can see minutes of their meetings. Moreover, you should give more credit to the great effort put into the public draft commenting system. Even so, much discussion did turn out to be private. Is it unreasonable to guess at why that might be: FSF being stretched to the max to encourage public participation, non-paid public participation in Committee D, relatively large stakes for corporations, etc.? I am sure the process could have been improved. The web site should have done more handholding, for example, and there is never enough publicity. As an ordinary user, I should have done more earlier to make suggestions for the site, for example. In a sense, I have come around to agreeing with you about non-free aspects of the process. In particular, I think money talks, as usual, even here. One could argue that it boils down to the four freedoms versus money. Moreover, the process has involved tradeoffs. However, in no way does there seem to be some overarching covert plan. bronson, I can see that you are trying to make your points more carefully; improving even more would get you better attention than my meager attempts.
Possible routes to kernel on GPLv3 Posted Jan 29, 2007 8:16 UTC (Mon) by bronson (subscriber, #4806) [Link] Of course I realized that draft 3 was not certain. Given how contentious draft 2 was, however, I'd have thought that releasing a draft 3 would be of critical importance. Even if it remains mostly unchanged, it could be accompanied by annotations or a document describing why the contentious sections are unchanged.
You view the kernel team's position statement timing as a political move. I see it more as an act of desperation. I don't think they wanted to resort to such theatrics; it's not their style. Whether it was justified or not, I think they must have felt like they were pretty much out of options.
You know, it's funny that each side is accusing the other of not listening. And even funnier that each side appears to be correct!
How can we break this communication breakdown? I can offer a suggestion... Release a draft 3. Then let the kernel guys could come up with an updated position statement. I think the MS-Novell deal and the patent clarifications would keep this statement a lot shorter than the last one.
The FSF could then respond, hopefully with more depth than last time (the clarification was awfully brief and dismissive). Above all, the FSF could demonstrate, using actual examples, what clauses the kernel guys could add to the GPLv3 to achieve their goals. Even if it's only academic in this case (presumably the kernel will remain GPLv2 forever), I think it's really worth keeping the kernel devs happy with the FSF's new licenses. You never know when a Linux Kernel NT prototype will be written and require an updated license. :)
Even if no agreement can be reached, at least this way each side would understand why things are the way they are. It would be a lot harder to write confusion off to "typical FSF bureaucratic BS" or "typical prima donna kernel whiners." Hopefully, the kernel guys would know how to modify the GPLv3 to suit their needs, a useful thing even if they never have the opportunity to take advantage of it.
The Linux kernel represents a ton of developers. I really hope that they can end up mostly satisfied with the new GPL.
I've learned a lot from this discussion, b3timmons. Thank you. I just wish it could have occurred somewhere on gplv3.fsf.org. :)
Possible routes to kernel on GPLv3 Posted Jan 29, 2007 15:25 UTC (Mon) by b3timmons (guest, #40286) [Link] bronson,
While I agree that it would be nice to see an updated draft soon, the contention really seems to come mainly from the kernel guys. Unfortunately, as RMS originally warned years ago, "Linux kernel = all of FOSS" in the minds of way too many people (I am not saying you!). You question whether the position statement was political, but of course we should note that Torvalds has for a long time played balancing acts of various sorts. Some of these acts involve being political whether he likes it or not. I cannot believe that all of those behind the position statement did not act without their employers in mind. Of course, there is nothing wrong with this in and of itself, but, IMHO, the statement was made with other entities in mind, such as Linus's employer, OSDL.
OTOH, the MS-Novell deal worries me, and I would not be surprised if it spooked Moglen, RMS, etc. into brainstorming about more crazy ways that free software can be made effectively nonfree. Note that they, like the other participants, are also representatives. They represent all people who expect the GPL to once again guarantee the freedom that, as stated in its preamble, it intends to guarantee.
You might interesting the thoughts of an upcoming legal eagle, ex-Novell guy Luis Villa. In particular, see his criticisms of both the FSF and the kernel guys:
Possible routes to kernel on GPLv3 Posted Jan 29, 2007 21:45 UTC (Mon) by bronson (subscriber, #4806) [Link] The Linux Foundation desires a strong GPLv3, don't they? You imply that Linus and his "many interests" are bent on harpooning the new GPL. I find this extremely implausible. Much more likely is just typical communications difficulties, no? Especially when exacerbated by the FSF's bureaucracies. Yes, the position statement was too politically loaded, but I hope both parties can overcome this.
Apparently Eben is satisfied that GPLv3 draft 2 is sufficient to prevent the MS-Novell deal in the future. That's good enough for me! I do hope he and RMS are gaming future scenarios; given the skill with which Microsoft convinced Novell to sign this crazy deal, we can be quite sure that the opposition is doing so.
I met Luis a few times when I lived in Boston. I like the guy a lot and follow what he's doing pretty closely. I think he's spot on with pretty much everything he says.
You claim that the contention comes mainly from the kernel guys. Luis isn't a kernel guy, is he? LKMLers tend to loathe Slashdot but there are a number of dissenting voices here: http://ask.slashdot.org/article.pl?sid=06/10/06/2046257 Tectonic isn't a kernel mag: http://www.tectonic.co.za/view.php?id=914 (this is satire but its position is clear). I'm sure I could find more examples if I kept looking.
Yes, the vast majority of free software developers are silent on the matter. That should not be interpreted as tacit support for the gplv3! Make no mistake: the GPLv3 is still a very controversial license. I really hope the FSF takes the time to get it right.
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 20:48 UTC (Sat) by b3timmons (guest, #40286) [Link] Since nothing has happened since March 2006, if at all, I hope you understand why I feel disinclined to participate in committee D. Here's a crazy suggestion: open up the discussion. Maybe some mailing list archives, a forum, a regularly updated blog? This stuff is trivial; it takes all of 1/2 hour to set up. It sure would help; right now, gplv3.fsf.org looks totally abandoned. Not all websites hold your hand equally well, but what is so hard about doing a google search: Committee D mailing list site:gplv3.fsf.org The first hit gives: http://gplv3.fsf.org/mailman/listinfo/committee-d , which you will find shows a lot more activity for Committee D than you suggested. And why have secret police committees? I would really like to know what the GPLv3 drafters thought of the Kernel document. Since gplv3.fsf.org doesn't even acknowledge that the kernel guys exist, what can I do? File a Freedom of Information Act subpoena?? Of course, there were several bits of reaction about the kernel document, including http://www.fsf.org/news/gplv3-clarification "secret police committees" is just silly. Whether we get a more informed response than mine, we could indulge in a little common sense. Clearly, since companies are involved with concerns that they may wish to not be overly public, is it unreasonable to suppose that a committee with a certain privacy level would elicit more candid feedback from them? Likewise for the other groups. Of course, anyone could always contact any member with any concerns since they are all listed. Answer me this: since gplv3.fsf.org does not go out of its way to acknowledge any outside group, why should it acknowledge the kernel guys? Could you be more specific about some unfair inconsistency? Just imagine if the FSF wrote software using this process! The whole gplv3.fsf.org process demonstrates the very definition of "not open." Nonsense. The only thing not open I see is that some committees have a certain level of privacy. What do you want? For those committees to be totally public and then for the, say, corporate people, to not be frank about their concerns? Don't get me wrong; I can't wait until we have an updated GPL so the Microsoft-Novell hole can be plugged. I just wish the current draft were so encumbered with phantom issues. At this rate, it will take 4 more years to release and, when it finally does get shoved out the door, it will be identical to draft 1 of almost a year ago. Not good. "At this rate"? Are you not aware that they have long had a schedule to keep in order to get it out in two months? Phantom issues indeed: phantom adj : something apparently sensed but having no physical reality; "seemed to hear faint phantom bells"; "the amputee's illusion of a phantom limb" In short, I think your post is presumptuous and ill-informed, but maybe I am missing something. Apart from the MS-Novell deal that they have promised to handle, what are your issues with the second draft?
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 14:31 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Ever wonder what the "cathedral" was that ESR ranted against when he came up with Open Source?
Possible routes to kernel on GPLv3 Posted Jan 27, 2007 15:34 UTC (Sat) by sepreece (subscriber, #19270) [Link] "So where to draw the line? GPLv3 draws the line at network installs. Whatever parts of the software can be upgraded by the manufacturer over the network have to also be modifiable by the owner."
Can you clarify how you think GPLv3 draws the line at that point? I don't see anything in there that talks about a specific means of installing or even about who can do the installing (despite all the FSF comments about "manufacturers having rights they don't pass along"). It says that if there are checks based on keys, you need to provide the keys.
In reality, manufacturers almost never have the ability to push upgrades into delivered devices, though third parties (cable companies, mobile carriers, etc.) may, usually in conjunction with service contracts. Installs are typically done in stores or at the user's request.
The situation is, in fact (at least for cell phones), just as though the vendor said "we sold you version x of our product, but if you bring it back to the store, we'll swap it for the current version." You could get exactly the same model with ROM, but then the process would take a lot longer, since the owner's data would have to be transferred to the new device.
"The other ways to tackle the current DRM frenzy are to either (a) use our market pressure, but that's just choosing to fail since we have a track record of never using our market pressure effectively, or (b) shake off the power that the content industry has over us by moving to free content - this means discarding all culture made in your county and my country in the last century, and It won't happen."
On the contrary, there is some reason to believe that for music, at least, there is a real trend toward selling DRM-free MP3s (there was an article in the New York Times saying that in the last week <http://www.nytimes.com/2007/01/23/technology/23music.html...>).
Possible routes to kernel on GPLv3 Posted Jan 30, 2007 8:09 UTC (Tue) by drag (subscriber, #31333) [Link] """Can you clarify how you think GPLv3 draws the line at that point? I don't see anything in there that talks about a specific means of installing or even about who can do the installing (despite all the FSF comments about "manufacturers having rights they don't pass along"). It says that if there are checks based on keys, you need to provide the keys."""
Well that's a odd way to state it, but it's fairly effective.
It boils down to it: 'if the manufacturer can change out the software and replace it with a newer version then you should be able to do that also'
That is typically done through network access in embedded devices, but serial port access is common also.
This is different from, say, read-only firmware which the manufacturer doesn't have to let you change it, since they can't change it without taking the device appart and replacing the physical chip.
For example, with OpenMoko and their phones, the regulatory bits are in the firmware logic and only a abstracted form of the GSM tuner (or whatever) is presented to user space in the form of a serial interface which you interact with in a similar fasion to regular old modems.
That way the phone can be completely open source in the kernel (except for a GPS thing, which is another issue entirely) and still be able to respect the legal restrictions requirements.
Also it's prefectly GPLv3 compatable to have it so that you violate warrentees if you try to modify the software and such things. There is nothing in the GPLv3 that says the original manufacture has to remain liable if you change something and break it. Things like that.
|
|||||||||||||