"Would it be allowable to release a program with mixed GPLv2 and GPLv3 code as long as one was clear on which parts were which"
No, it isn't.
Still, when Linus wanted to move into the GPLv3 I don't think there will be any problem. It is not as if he didn't just exactly that in the past. You know, once upon a time, Linux kernel was "GPLv2 or later", but one day he decided to go "GPLv2 only". While the commiters were surely much less than today, the problem was qualitatively the same. And the solution is the same too: he will just announce that he will move the license so whoever that doesn't like it can get in contact with him. If there's no opossition, the license change just will take place overnight.
"I would have thought that if you get too fussy with regard to the licence and how the code can be used alot of companies will just run away"
What you seem to forget is that from day 0 whatever RMS did was "way too fussy"... on the start. It was "way too fussy" to start a "holy war" just because some printer drivers. It was "way too fussy" to start a foundation to cope with his points of views; it was "way too fussy" to look for a distribution license just to cope with his own envision. But, as bad as was the idea of the GPL (how in his sane mind would code for a license that will make your code just to be wide open to the competition? After all, if you want code for the sake of it, you have BSD-like licenses, haven't you?). But on the long run, not only there has been "some" persons and companies that have developed and release under the GPL, but that the GPL is seen as a more corparte-friendly license than others. Now new menaces come to disturb RMS's envision (you can say a lot of things about RMS but one you can't say is that it's easy to change his mind) and his reacting to cope with them and *again* as it was from day 0 a lot of people say that "this time" he really is gone "way too fussy".
Well, maybe. We just need to wait and see (I for one believe that RMS is *again* on the right track).
"For exmaple, GNU contrubutes the complier and Command Line Tools. Suppose future versions of that software are release in GPL3. Could the rest of Linux resonably stay on GPL V2?"
You should try for a better example: both the compiler and command line tools are the less "viral" of all software since they doesn't bind to anything in order to be used.
Microsoft holds a lot of patents. Microsoft can ask for patent fees to whomever is using its software at its will. Microsoft signs an agreement not to ask for patent fees on its own software to whomever uses Novell software too. This can lead to Microsoft Word costing X to Novell clients and X*2 (numbers out of my ass) to non-Novell clients. In order to avoid this, there is a clause within GPLv3 that forbids GPLv3 distributors to entry such an agreement.
I can see how can this affect Novell which will have to decide to break its deal or be damn sure it is not distributing GPLv3 code.
How this will affect say, Debian, since it didn't sign such kind of agreement? Microsoft can certainly decide to ask for a special patent fee on Microsoft Word to users of Debian GNU/Linux, since a patent holder can always decide who to license its patented IP and how much for but, again, that's no news: Microsoft can do exactly the same right *now*, as it can do it regarding, for instance Autodesk's users (Microsoft Word for registered AutoCAD users will cost X; Microsoft Word for non-AutoCAD users will cost X*2). Even more, Microsoft doesn't need any special agreement with AutoDesk for such a policy (and, at least, GPLv3 *forbids* such kind of agreements to GPLv3 *distributors* -it does say nothing about GPLv3-covered software *users*). So *again* what does make GPLv3 so special that such patent fees will arise more easily/more frecuently/more gravely once it is published?
"You think locking people who need or desire to use MS software out of the freedoms the GPL protects is a positive situation?"
Frankly, I don't give a damn about Microsoft users -that's a problem between Microsoft and them. But anyway, it will be Microsoft, not the GPL producers, the one that will try to extort its own user base -in a way Microsoft can go *today* without GPLv3 being neither a deterrent nor a helper (except for the fact that *maybe* it will help it not to happen: probably AutoDesk in my previous example could sue Microsoft if it tried a different license fee for their own products with regards of AutoCAD usage without a previous agreement with AutoDesk because of the impact on AutoDesk's corporate image). Maybe we should even hail Microsoft to go that path: it would be so bizarre and such a blatant extortion on their own userbase that would push more and more users out of its products or even push for a change on current patent laws.
"The reason they're profitable with such a low return rate is (as has been said before) that the cost of each email is tiny"
And the reason why their email costs are tiny is because they don't use their own servers for the most part. Obviously paying per email isn't going to increase their costs anyway.
The real point (again) is making money out of things we gave for granted till yesterday. And we took them for granted till yesterday because it is the way it is supoused to be: it is the mixture of the greed of some companies to make money out of unethical things mixed with the stupidity of some people who won't see the real consecuencies of their elections. I know it only too good: I have my own domain and my own mail server on my DSL line from home; I even have a fixed IP. To the best of my knowledge spam *never* got out from my server; still the fact that my IP is marked as dynamic/residential on some blacklists makes my e-mails rejected on some servers and somehow it's *my* fault and somehow the means to reach them goes by *me* paying money to some third party company on top of the money I'm already paying to my ISP both for my DSL line and my fixed IP.
"The GPLv3 will be able to go in directions the GPLv2 cannot"
Like... what? I don't see any direction GPLv3 can take that cannot be taken (or better said *expected* to be taken) by GPLv2 at least as their originators (the FSF) wanted it.
"resentment will probably set in and there will be widespread use of the GPLv2 only clause"
More handvawing? There will be a widespread usage of the "GPLv2 only" caveat *or* the FSF will win its "battle for control" with its GPLv3; it cannot be both ways, as it can't be that even projects that will go "GPLv2 only" *after* GPLv3 is published will avoid their previous "GPLv2 or higher" from being forked by "our new GPLv3 overlords".
"From a personal perspective, Would you really be happy if because of some clause in an open source license and how your were tricked into a deal, forbid you from using the new version that has all the cool things in it?"
Like... which case? for the software I just *use* there won't be any usage limitation on GPLv3, no more than in the GPLv2, and this means *noone*: neither GPLv2 nor GPLv3 are even user licenses at all. From the developer perspective I've been quite aware of the difference between "GPLv2 only" and "GPLv2 or greater" so there's no way I can be "tricked" one way or the other.
"And this doesn't really touch on the division we would have between the two groups"
Se my previous paragraph. Malign FSF either wins its battle on the GPLv3 issue, in which case there won't be "two groups" (not at a significative degree, at least) *or* it doesn't win it so your armaggedon scenario doesn't become to live (you will have a situation more or less like current one at most). It can't be both ways.
"I used the term license because the GPLv3 groups the paten protection or covenant not to sue into a "patent license deal"."
Repeat with me: such "patent license deal" is NOT the GPLv3. On GPLv3 licensed software, such an agreement will have no impact (since it means just "current agreement and then a bit more", so by GPLv3 I'm bound not only not to sue *you* due to our "non-beligerant agreement" but not sue anything else) *or* will impact those with such kind of agreements (like Novell) and then it's *their* problem, nor mine, since will be *them* those with problems due to the widespread usage of the GPLv3.
"So you have a third party not effected by the GPL offering indemnification over IP they claim ownership on"
Which is *exactly* the current situation. Do you think that Microsoft can't look for patent fees on both users and developers of GPLv2 software *NOW*? The difference will be that at least under GPLv3 one won't be able to release software *and* look for patent fees after the fact. So those living in the older "GPLv2 world" will be exposed to absurd patent claims where those living on the "GPLv3 world" will be safe. What that means to me is "the sooner the GPLv3 world, the better".
"In this case, you have companyA distributing GPL covered software to companyB or userB. Now companyZ who is so far removed from the software in itself and the licensing of it lays claim to IP in the software that it didn't place into the covered works and offers companyA and B protection from lawsuits but not C,D,E or anyone else."
Hell, HOW IS THIS ANY DIFFERENT FROM GPLv2 SOFTWARE!!! Please state THIS. You are talking about a "new world of terror" regarding GPLv3 but you are failing to substiantate how GPLv3 will be ANY WORSE than current situation. At least, under GPLv3 noone wil be able to seed minefields within the code (under current GPLv2 is perfectly possible for companyA to introduce code under their own IP protection, wait for widespread usage and then ask for patent fees to any third party -or at least, try for it: a different matter will be to see if any judge will support such bastardized claims. At least GPLv3 insures by explicit wording within the license that if anyone wants to make patent claims, it will have to be on *other's* code, not their own! And they wil
"That in itself [breaking open source comunity at both ways of the "license fence"] is a big problem because of compatibilities and such."
Yes it is. But is a problem no bigger than current way: there are a *lot* of open source licenses that are not compatible with GPLv2. So your "armaggedon scenario" is no worse than current one regarding this point. And please remember that this could only affect those projects that stick with the "GPLv2 only" stanza; those that use the "GPLv2 or higher" cannot affect third party users or developers since they are free to use, modify and redistribute such code either under GPLv2 or GPLv3 at will.
"All someone has to do is create a license that protects you or me from lawsuit when distributing anything and get us to make payment for it. This kicks the anti novell deal thing in and boom."
It is both against the spirit of the GPLv3 (as stated in its preamble: "the GPL assures that patents cannot be used to render the program non-free.") and the letter of it (paragraph#10: "Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work" and paragraph#11 "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version."). So there's no way that under the GPLv3 CompanyA grants usage of a patent to CompanyB but not to CompanyC,D and E or, in fact, to any third party that (legally) puts its hands on the source code.
"This is the trick, it covers anything you distribute but not who you distribute to"
That's not what the GPLv3 explictly states: by adding code that might be covered under a patent of yours you already gave me -and anyone else I might distribute to, "a non-exclusive, worldwide, royalty-free patent license" covering such patent claims. And you are not allowed to modify this by means of an "additional term" since patent claims is excluded from paragraph#7. Did you really read the GPLv3 draft?
"They can word the covenant not to sue so that it doesn't cover your own actions of placing the problematic IP in the code yet still works if you decide to distribute anything GPL."
No, they can't. That's exactly what the GPLv3 is for. What you are presenting as GPLv3 problems are, in any case, problems on the GPLv2, so the fastest the GPLv3 is in use, the least the menace from GPLv2 holes will be.
"Let's not, as it is completely, utterly irrelevant"
Then you already made your choice.
"As if the source code was deserving of humanitarian consideration"
You decided to take my comparation purposedly in an unintended way. That's OK to me but it doesn't invalidate it. It's just you didn't want to play by the rules.
"Slavery - and human conditions in general - aren't going to produce a reasonable comparison."
That's your opinion, not mine. Both cases are about "objects" (either [people] or [copyrighted code]) burdened under limiting circumnstances (regarding [free will] in one case, regarding its [redistribution abilities], in the other). Both proposed situations manage with the problem at hand on a similar way 'mutanda mutandi' (freeing your own slaves goes to distributing your code under Public domain as making war against slavery goes to distributing code under the GPL since you can in both cases substitute the changing part [the one within brackets] without altering the meaning of the resulting situation: you gain [free will]/[redistribution abilities] for [people]/[copyrighted code] either only [within your property]/[your own development] or [within labour hands at a whole]/[within code world]).
The fact that you don't want to pay attention to any comparation or reasonement that obtains a different output than your prejudiced one doesn't make those comparations or reasonements any less reasonable.
Where is the 'ad hominem' here? I can't see it anywhere. It is you the one making vague assertions about the GPL "licensing opens the door to an additional legal minefield we'd just as soon avoid". The only one situation I can come with that genuinely makes a difference regarding management of code and/or third party licensing between open and closed source programs is the one I outline -that is, that there's illegal distribution of third party code which can be easily covered in the case of closed source but not in the case of open source, wich is independant whoever the source comes from (so no 'ad hominem': my argument is not based upon being you the one I'm answering to).
"My question was more specifically targeted at the traditional retail space, where generally copies of the software are sold, and not service"
Maybe my "snarky sarcastic reply" made you lost the part where I said I had at sight a BOXED RETAIL-SELLED COPY of a GPL software collection from a profitable company still in bussiness.
And you can find another post of mine on this thread talking about how Red Hat is still selling copies of Red Hat, although disguising its name as "services".
"Really? Then explain how PD does less for freedom than the GPL."
That has already been explained to the nausea. Here comes again: Let's compare with slavery in the USA of old days. Public domain (or BSD-like licenses) is like being a southern landowner that takes the decision to free their own slaves; GPL is like organize an army to fight against slavery.
Now you can think about it and end up saying that the former is the "freer" option because you don't force other landowners' freedom about having slaves. Or, you can end up saying that the later is the "freer" option because it ends up slavery and it's no freedom the "freedom to enslave".
"I don't like the GPL because the licensing opens the door to an additional legal minefield we'd just as soon avoid"
Probably you are right here. By letting your clients see your source code they could see, for instance, you are illegally including third party code without rights to do so. If you don't let them see, they won't discover. It's just I don't see it quite a fair thing to be done.
"makes distribution and maintenance more complicated"
How can be distributing and maintaing code *any* more complicated or any more *anything*? On one extreme scenario how can distribution be any easier than "here it is: go download it yourself"?; on the other extreme, whatever your distribution and maintenance model currently is, how changing your distribution license into the GPL would force you to change them the least bit?
"poses linking issues, forcing decisions about embedded code vs. external libraries based on exposure of our own IP"
Do you mean that distributing your products under a restricted EULA doesn't pose linking issues and forces decisions about embedded code vs. external libraries based on exposure of your own IP? The only way I can imagine for this to be true is by you knowlingly violating copyright laws, and I don't think this to be the case, is it?
"Of course the developers will care about the bug, and eventually fix it, but if your business critically depends on it, an answer like "Next week I'll probably have time to look into that" will not be acceptable to you. You need the fix, and you need it as fast as possible. And that's what you pay for."
No. You pay for the safety net of being able to point to someone identifiable else that is not you when something goes nasty.
For the most part, specially regarding a project with ample distribution, you either don't sign support contracts and then you contact yourself with the specific guru of that software that will tell you "next week I'll probably have time to look into that", (but who said you can't pay said guru a big one-time check in order to change his response into "I'll do it tonight"?), or you have an expensive support contract, you call them, they'll tell you "I'll put our best engineers right now to the task; tomorrow you'll have a patch", and then they go to find who is the specific guru of that software; ask him, he answers "next week I'll probably have time to look into that" and then their phone support manages to distract you the whole week till they have the patch from the guru.
*But* the big difference with the payed support is that when your boss comes in rage asking why the database server is broken four days now, you can cover your ass by saying you are pressing your support company all you can so it's not your fault but those damned [here support company X], so you divert your boss rage from you to your support company.
I think there are some misconceptions around Red Hat. It's true that Red Hat makes money out of services, but it is true that they make money out of directly selling the software too (and I'd say they earn more on direct licenses that by means of services).
I just sent another message where I mocked up about Dell selling boxes with Red Hat preinstalled -and that's "direct selling" whatever the name they want to push through your throat: I want a machine and I want Red Hat on it, therefor I have to pay 600 if I want it serviced.
A *lot* of people buy such servers (from Dell, from IBM, from HP...) and *buy* the software because of the buying of the software itself, not for any other added benefit. Corporate environments need (or they think they need) feel worm by buying "something" that means "somehow" there is a contractual relationship between their assets and their assets' dealers. They need, say, a PowerEdge 2950 with a "certified" installation of RHEL 4AS and a "certified" installation of Oracle 9i and a "certified" installation of an EMC fiber channel storage device.
They won't give a damn about what any other services come in the bundle (I know about a ton of Red Hat installations on different companies, all of them with their one-year standard upgrade services payed along the hardware that they won't even try to register at Red Hat Network). If any, the value-added services only mean problems and nuisances to them when if something "funny" arises and they call the hardware support, first they hear is "did you upgrade to BIOS patch version XXX, and controller Z version YYY" (after all it is *suppoused* that those "services" you payed for are exactly the existance of such patches -you wouldn't need support if you were sure everything is going to run flawlessly) or they try to ask to Red Hat and first they hear is "did you upgraded your kernel to version XXX?" or "did you applied security fix ABC?". All they want is some "bundled product" they pay a lot of money to install and have a piece of paper that says "certified" so their asses are covered, and then they want to forget about it for the next three or four years. Then they decomission all the hardware and software alike an buy a new "bundle".
That's the bussines of "selling" software and it works exactly the same for proprietary or open software because, deeply on, it has nothing to do with the software itself and it's all about brand recognition and warm feelings.
"Perhaps you can help explain this to me... I've never understood how one could easily sell GPL'd software."
You just put in a box and sell it. From where I currently stand I can view an old red and white box with a man on a funny hat printed on it. It's labelled "Red Hat 6.2" and do you know what's inside? GPL'd software packaged in a box and selled for a profit. I think I heared rumours recently that Red Hat is still in bussiness making money out of selling GPL'd software and some services around it, and I can say that some days ago I visited Dell's web page and peeked among their servers pages. There you could buy -online! hell, bussiness techniques are advancing day-in day-out mate, some servers -"poweredge" I think they call them, either with Windows (Vista or 2003, I really don't remember) for a price, or Red Hat -for a price too, so it must be true Red Hat is still in bussiness selling GPLed software.
"Actually, once something is GPL'd it's always GPL'd, so you can never change the license of a GPL'd work."
Well, the "problem" with this is that "source code" means two things at the same time: it's an abstract concept (like in "the source code of Emacs 11" which is the abstraction of all the copies ever made and those that could possibly be made -or the archetype of Emacs 11 if you are platonicly inclined), and it's a concrete thing (like the very CD I pass to you that contains a copy of the source code or the physical paper and ink of an impressed version).
It is true that the copy (the concrete thing) of a program you distributed to me under GPL terms is forever mine under GPL terms and the author can do nothing to revert this. But it is true too that -being the author and only copyright holder, he can make *further* copies of the source code and distribute those under any other license he deem apropiate, just like Stallman (provided he retains copyright of all the codebase) can tomorrow start distributing copies of Emacs 11 under a Microsoft-like EULA -that, of course, doesn't mean your already owned copies of Emacs 11 are anyless GPLed than before. So where previously there were only one archetype of the Emacs 11 source code, now we have two, one under the GPL and another under el Ms-like EULA.
" It is being forced in a concerted effort to force as many people as possible to use it in order to be under the new obligations."
OK, let's pay into your armaggedon scenario. Let's imagine the FSF already published the GPLv3; it already moved all its codebase to the new GPLv3, and it already "won the battle" and most GPL-liken developers are using it on their own developments. Now what? What is the real problem now?
There's certainly no problem to me. My software production/usage is terribly outbalance to the side of the usage. What are my new concerns regarding the use of GCC, Emacs, Subversion, etc.? Maybe I'm ill-informed but I really don't see any problem on this side. On the other side, for the short part of the software that I develop I know I can produce it under GPLv3, GPLv2, BSD or even a Microsoft-like EULA. Even more, I'm not planning development of any "DRM-powered", patent encumbered or "hardware usage-limiting" software, so I really can't see how the adoption of the GPLv3 for my own software (*even* if I were really obliged to use it, which I'm not) would badly affect myself. And even-even more, since I'm quite worried about where the devolpment of "DRM-powered", patent encumbered or "hardware usage-limiting" software can affect me as a software "consumer" I can only see advantages if your armaggedon scenario really came into live.
But surely I'm missing something. I hope you can enlight me -for all I've seen from you till now is nothing but hand waving, bruhaha, and unspecific claims about how bad will be the new GPLv3 that the FSF will impose over us by force in order to achive some dark and dirty... unstated whatevers. That's nothing but FUD on my book.
"I'm not entirely sure about a staff attorney, but if he is employed by the same company that is being sued you can probably get away with it - however, it's not an altogether shut and dry decision."
You are not "entirely sure"? Are you meaning that "maybe" an attorney office (since all its employees are attorneys) cannot claim or counterclaim at a minor offences court?
"and i suppose it did not occur to you that there is a very good reason WHY open source is not used extensively in defence? who wrote that code? did you audit every single line?"
and i suppose it did not occur to you that there is a very good reason WHY closed source is not used extensively in defence? who wrote that code? did you audit every single line?
"Why does it matter if it was developed or updated by more than one independent software provider?"
Yes, I really think so.
"As long as it is well-defined"
That's the point. Experience shows that you cannot seriously hope for such an entangled thingie as a document format (or network protocol) to be defined beyond shadows on a written standard. The only way to know you have a functional open standard is to have a look at the source code itself. I'd prefer taking away the "multiple providers" and to say instead "at least one open implementation of the standard" (followed, of course, by a proper definition for "open") as a way to demonstrate that the standard is factically doable; whenever the standard shows a shadowy corner you can point to the open implementation and say "it means you should implement it *this* way" (that worked quite good for things like TCP/IP or SMTP). Failing to that, having at least two independent *successful* implementators (and then we have to go after the definition of "successful"), shows that there's the chance to have an implementation directly out from the standard papers.
"PDF is developed solely by Adobe, yet it otherwise fits the bill as 'open'."
Till you crash against the patented parts; till you crash against the shadows on the standard definition and the only way to clarify it is trying to reverse-engineer Adobe's PDF viewer/distiller; till you crash against the development advantage Adobe has since they can have PDF Viewer version+1 the very day they publish a new version of the standard... since the PDF 'de facto' standard is that from Adobe it gets it an iron clad over PDF almost as if the standard were unpublished.
Re:There's a difference between GIT and SVN
on
Linus on GIT and SCM
·
· Score: 1
"I'm sorry but this appears to be self-contradictory. If branches are good, distributed VCS's are good, because they are based around branches as a core concept. You seem to be under the mistaken belief that a branch in a distributed VCS must be private. In fact, you can push or publish any branch"
I think one emerging problem with distributed VCS is that branches *can* go hidden. On a centralized SCM tool, branches are *always* public by default (to those with access to the central repo, of course), so you can always have a look at what other people is going on with. That have the potential to emerge stronger sinergies within your team, since other people can peek at any branch potentially at any time (even when the creator asumes it is still not ready for public scrutiny). On the other hand, private branches (thus decentralized development) has its own advantages too: like assuming (kind of Linus' "sense of humor") that 98% of all work will be rubish, so it's better done wherever it doesn't disturb "real" work.
So at the very end, different scenarios, different solutions. Not a great discover.
"I don't think there is anything especially wrong with Subversion. Sure it doesn't support changesets"
What do you mean exactly with "doesn't support changesets"? It does support atomic commits and branches. What else is need for "changesets" to be supported?
Slashdot Mirror
"This would cause a lot of companies and users to not use or at least contribute to any GPLv3 software"
This would cause a lot of other companies and users to not use or at least contribute to any Microsoft-based software.
"Would it be allowable to release a program with mixed GPLv2 and GPLv3 code as long as one was clear on which parts were which"
No, it isn't.
Still, when Linus wanted to move into the GPLv3 I don't think there will be any problem. It is not as if he didn't just exactly that in the past. You know, once upon a time, Linux kernel was "GPLv2 or later", but one day he decided to go "GPLv2 only". While the commiters were surely much less than today, the problem was qualitatively the same. And the solution is the same too: he will just announce that he will move the license so whoever that doesn't like it can get in contact with him. If there's no opossition, the license change just will take place overnight.
"I would have thought that if you get too fussy with regard to the licence and how the code can be used alot of companies will just run away"
What you seem to forget is that from day 0 whatever RMS did was "way too fussy"... on the start. It was "way too fussy" to start a "holy war" just because some printer drivers. It was "way too fussy" to start a foundation to cope with his points of views; it was "way too fussy" to look for a distribution license just to cope with his own envision. But, as bad as was the idea of the GPL (how in his sane mind would code for a license that will make your code just to be wide open to the competition? After all, if you want code for the sake of it, you have BSD-like licenses, haven't you?). But on the long run, not only there has been "some" persons and companies that have developed and release under the GPL, but that the GPL is seen as a more corparte-friendly license than others. Now new menaces come to disturb RMS's envision (you can say a lot of things about RMS but one you can't say is that it's easy to change his mind) and his reacting to cope with them and *again* as it was from day 0 a lot of people say that "this time" he really is gone "way too fussy".
Well, maybe. We just need to wait and see (I for one believe that RMS is *again* on the right track).
"For exmaple, GNU contrubutes the complier and Command Line Tools. Suppose future versions of that software are release in GPL3. Could the rest of Linux resonably stay on GPL V2?"
You should try for a better example: both the compiler and command line tools are the less "viral" of all software since they doesn't bind to anything in order to be used.
So, all in all, what you say is:
Microsoft holds a lot of patents.
Microsoft can ask for patent fees to whomever is using its software at its will.
Microsoft signs an agreement not to ask for patent fees on its own software to whomever uses Novell software too.
This can lead to Microsoft Word costing X to Novell clients and X*2 (numbers out of my ass) to non-Novell clients.
In order to avoid this, there is a clause within GPLv3 that forbids GPLv3 distributors to entry such an agreement.
I can see how can this affect Novell which will have to decide to break its deal or be damn sure it is not distributing GPLv3 code.
How this will affect say, Debian, since it didn't sign such kind of agreement? Microsoft can certainly decide to ask for a special patent fee on Microsoft Word to users of Debian GNU/Linux, since a patent holder can always decide who to license its patented IP and how much for but, again, that's no news: Microsoft can do exactly the same right *now*, as it can do it regarding, for instance Autodesk's users (Microsoft Word for registered AutoCAD users will cost X; Microsoft Word for non-AutoCAD users will cost X*2). Even more, Microsoft doesn't need any special agreement with AutoDesk for such a policy (and, at least, GPLv3 *forbids* such kind of agreements to GPLv3 *distributors* -it does say nothing about GPLv3-covered software *users*). So *again* what does make GPLv3 so special that such patent fees will arise more easily/more frecuently/more gravely once it is published?
"You think locking people who need or desire to use MS software out of the freedoms the GPL protects is a positive situation?"
Frankly, I don't give a damn about Microsoft users -that's a problem between Microsoft and them. But anyway, it will be Microsoft, not the GPL producers, the one that will try to extort its own user base -in a way Microsoft can go *today* without GPLv3 being neither a deterrent nor a helper (except for the fact that *maybe* it will help it not to happen: probably AutoDesk in my previous example could sue Microsoft if it tried a different license fee for their own products with regards of AutoCAD usage without a previous agreement with AutoDesk because of the impact on AutoDesk's corporate image). Maybe we should even hail Microsoft to go that path: it would be so bizarre and such a blatant extortion on their own userbase that would push more and more users out of its products or even push for a change on current patent laws.
"The reason they're profitable with such a low return rate is (as has been said before) that the cost of each email is tiny"
And the reason why their email costs are tiny is because they don't use their own servers for the most part. Obviously paying per email isn't going to increase their costs anyway.
The real point (again) is making money out of things we gave for granted till yesterday. And we took them for granted till yesterday because it is the way it is supoused to be: it is the mixture of the greed of some companies to make money out of unethical things mixed with the stupidity of some people who won't see the real consecuencies of their elections. I know it only too good: I have my own domain and my own mail server on my DSL line from home; I even have a fixed IP. To the best of my knowledge spam *never* got out from my server; still the fact that my IP is marked as dynamic/residential on some blacklists makes my e-mails rejected on some servers and somehow it's *my* fault and somehow the means to reach them goes by *me* paying money to some third party company on top of the money I'm already paying to my ISP both for my DSL line and my fixed IP.
Stupid if not pathetic.
"The GPLv3 will be able to go in directions the GPLv2 cannot"
Like... what? I don't see any direction GPLv3 can take that cannot be taken (or better said *expected* to be taken) by GPLv2 at least as their originators (the FSF) wanted it.
"resentment will probably set in and there will be widespread use of the GPLv2 only clause"
More handvawing? There will be a widespread usage of the "GPLv2 only" caveat *or* the FSF will win its "battle for control" with its GPLv3; it cannot be both ways, as it can't be that even projects that will go "GPLv2 only" *after* GPLv3 is published will avoid their previous "GPLv2 or higher" from being forked by "our new GPLv3 overlords".
"From a personal perspective, Would you really be happy if because of some clause in an open source license and how your were tricked into a deal, forbid you from using the new version that has all the cool things in it?"
Like... which case? for the software I just *use* there won't be any usage limitation on GPLv3, no more than in the GPLv2, and this means *noone*: neither GPLv2 nor GPLv3 are even user licenses at all. From the developer perspective I've been quite aware of the difference between "GPLv2 only" and "GPLv2 or greater" so there's no way I can be "tricked" one way or the other.
"And this doesn't really touch on the division we would have between the two groups"
Se my previous paragraph. Malign FSF either wins its battle on the GPLv3 issue, in which case there won't be "two groups" (not at a significative degree, at least) *or* it doesn't win it so your armaggedon scenario doesn't become to live (you will have a situation more or less like current one at most). It can't be both ways.
"I used the term license because the GPLv3 groups the paten protection or covenant not to sue into a "patent license deal"."
Repeat with me: such "patent license deal" is NOT the GPLv3. On GPLv3 licensed software, such an agreement will have no impact (since it means just "current agreement and then a bit more", so by GPLv3 I'm bound not only not to sue *you* due to our "non-beligerant agreement" but not sue anything else) *or* will impact those with such kind of agreements (like Novell) and then it's *their* problem, nor mine, since will be *them* those with problems due to the widespread usage of the GPLv3.
"So you have a third party not effected by the GPL offering indemnification over IP they claim ownership on"
Which is *exactly* the current situation. Do you think that Microsoft can't look for patent fees on both users and developers of GPLv2 software *NOW*? The difference will be that at least under GPLv3 one won't be able to release software *and* look for patent fees after the fact. So those living in the older "GPLv2 world" will be exposed to absurd patent claims where those living on the "GPLv3 world" will be safe. What that means to me is "the sooner the GPLv3 world, the better".
"In this case, you have companyA distributing GPL covered software to companyB or userB. Now companyZ who is so far removed from the software in itself and the licensing of it lays claim to IP in the software that it didn't place into the covered works and offers companyA and B protection from lawsuits but not C,D,E or anyone else."
Hell, HOW IS THIS ANY DIFFERENT FROM GPLv2 SOFTWARE!!! Please state THIS. You are talking about a "new world of terror" regarding GPLv3 but you are failing to substiantate how GPLv3 will be ANY WORSE than current situation. At least, under GPLv3 noone wil be able to seed minefields within the code (under current GPLv2 is perfectly possible for companyA to introduce code under their own IP protection, wait for widespread usage and then ask for patent fees to any third party -or at least, try for it: a different matter will be to see if any judge will support such bastardized claims. At least GPLv3 insures by explicit wording within the license that if anyone wants to make patent claims, it will have to be on *other's* code, not their own! And they wil
"That in itself [breaking open source comunity at both ways of the "license fence"] is a big problem because of compatibilities and such."
Yes it is. But is a problem no bigger than current way: there are a *lot* of open source licenses that are not compatible with GPLv2. So your "armaggedon scenario" is no worse than current one regarding this point. And please remember that this could only affect those projects that stick with the "GPLv2 only" stanza; those that use the "GPLv2 or higher" cannot affect third party users or developers since they are free to use, modify and redistribute such code either under GPLv2 or GPLv3 at will.
"All someone has to do is create a license that protects you or me from lawsuit when distributing anything and get us to make payment for it. This kicks the anti novell deal thing in and boom."
It is both against the spirit of the GPLv3 (as stated in its preamble: "the GPL assures that patents cannot be used to render the program non-free.") and the letter of it (paragraph#10: "Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work" and paragraph#11 "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version."). So there's no way that under the GPLv3 CompanyA grants usage of a patent to CompanyB but not to CompanyC,D and E or, in fact, to any third party that (legally) puts its hands on the source code.
"This is the trick, it covers anything you distribute but not who you distribute to"
That's not what the GPLv3 explictly states: by adding code that might be covered under a patent of yours you already gave me -and anyone else I might distribute to, "a non-exclusive, worldwide, royalty-free patent license" covering such patent claims. And you are not allowed to modify this by means of an "additional term" since patent claims is excluded from paragraph#7. Did you really read the GPLv3 draft?
"They can word the covenant not to sue so that it doesn't cover your own actions of placing the problematic IP in the code yet still works if you decide to distribute anything GPL."
No, they can't. That's exactly what the GPLv3 is for. What you are presenting as GPLv3 problems are, in any case, problems on the GPLv2, so the fastest the GPLv3 is in use, the least the menace from GPLv2 holes will be.
"Let's not, as it is completely, utterly irrelevant"
Then you already made your choice.
"As if the source code was deserving of humanitarian consideration"
You decided to take my comparation purposedly in an unintended way. That's OK to me but it doesn't invalidate it. It's just you didn't want to play by the rules.
"Slavery - and human conditions in general - aren't going to produce a reasonable comparison."
That's your opinion, not mine. Both cases are about "objects" (either [people] or [copyrighted code]) burdened under limiting circumnstances (regarding [free will] in one case, regarding its [redistribution abilities], in the other). Both proposed situations manage with the problem at hand on a similar way 'mutanda mutandi' (freeing your own slaves goes to distributing your code under Public domain as making war against slavery goes to distributing code under the GPL since you can in both cases substitute the changing part [the one within brackets] without altering the meaning of the resulting situation: you gain [free will]/[redistribution abilities] for [people]/[copyrighted code] either only [within your property]/[your own development] or [within labour hands at a whole]/[within code world]).
The fact that you don't want to pay attention to any comparation or reasonement that obtains a different output than your prejudiced one doesn't make those comparations or reasonements any less reasonable.
"Look up ad hominem"
Where is the 'ad hominem' here? I can't see it anywhere. It is you the one making vague assertions about the GPL "licensing opens the door to an additional legal minefield we'd just as soon avoid". The only one situation I can come with that genuinely makes a difference regarding management of code and/or third party licensing between open and closed source programs is the one I outline -that is, that there's illegal distribution of third party code which can be easily covered in the case of closed source but not in the case of open source, wich is independant whoever the source comes from (so no 'ad hominem': my argument is not based upon being you the one I'm answering to).
"My question was more specifically targeted at the traditional retail space, where generally copies of the software are sold, and not service"
Maybe my "snarky sarcastic reply" made you lost the part where I said I had at sight a BOXED RETAIL-SELLED COPY of a GPL software collection from a profitable company still in bussiness.
And you can find another post of mine on this thread talking about how Red Hat is still selling copies of Red Hat, although disguising its name as "services".
"Really? Then explain how PD does less for freedom than the GPL."
That has already been explained to the nausea. Here comes again:
Let's compare with slavery in the USA of old days. Public domain (or BSD-like licenses) is like being a southern landowner that takes the decision to free their own slaves; GPL is like organize an army to fight against slavery.
Now you can think about it and end up saying that the former is the "freer" option because you don't force other landowners' freedom about having slaves. Or, you can end up saying that the later is the "freer" option because it ends up slavery and it's no freedom the "freedom to enslave".
Now, it's your choice.
"I don't like the GPL because the licensing opens the door to an additional legal minefield we'd just as soon avoid"
Probably you are right here. By letting your clients see your source code they could see, for instance, you are illegally including third party code without rights to do so. If you don't let them see, they won't discover. It's just I don't see it quite a fair thing to be done.
"makes distribution and maintenance more complicated"
How can be distributing and maintaing code *any* more complicated or any more *anything*? On one extreme scenario how can distribution be any easier than "here it is: go download it yourself"?; on the other extreme, whatever your distribution and maintenance model currently is, how changing your distribution license into the GPL would force you to change them the least bit?
"poses linking issues, forcing decisions about embedded code vs. external libraries based on exposure of our own IP"
Do you mean that distributing your products under a restricted EULA doesn't pose linking issues and forces decisions about embedded code vs. external libraries based on exposure of your own IP? The only way I can imagine for this to be true is by you knowlingly violating copyright laws, and I don't think this to be the case, is it?
"Of course the developers will care about the bug, and eventually fix it, but if your business critically depends on it, an answer like "Next week I'll probably have time to look into that" will not be acceptable to you. You need the fix, and you need it as fast as possible. And that's what you pay for."
No. You pay for the safety net of being able to point to someone identifiable else that is not you when something goes nasty.
For the most part, specially regarding a project with ample distribution, you either don't sign support contracts and then you contact yourself with the specific guru of that software that will tell you "next week I'll probably have time to look into that", (but who said you can't pay said guru a big one-time check in order to change his response into "I'll do it tonight"?), or you have an expensive support contract, you call them, they'll tell you "I'll put our best engineers right now to the task; tomorrow you'll have a patch", and then they go to find who is the specific guru of that software; ask him, he answers "next week I'll probably have time to look into that" and then their phone support manages to distract you the whole week till they have the patch from the guru.
*But* the big difference with the payed support is that when your boss comes in rage asking why the database server is broken four days now, you can cover your ass by saying you are pressing your support company all you can so it's not your fault but those damned [here support company X], so you divert your boss rage from you to your support company.
"A support system like Redhat"
I think there are some misconceptions around Red Hat. It's true that Red Hat makes money out of services, but it is true that they make money out of directly selling the software too (and I'd say they earn more on direct licenses that by means of services).
I just sent another message where I mocked up about Dell selling boxes with Red Hat preinstalled -and that's "direct selling" whatever the name they want to push through your throat: I want a machine and I want Red Hat on it, therefor I have to pay 600 if I want it serviced.
A *lot* of people buy such servers (from Dell, from IBM, from HP...) and *buy* the software because of the buying of the software itself, not for any other added benefit. Corporate environments need (or they think they need) feel worm by buying "something" that means "somehow" there is a contractual relationship between their assets and their assets' dealers. They need, say, a PowerEdge 2950 with a "certified" installation of RHEL 4AS and a "certified" installation of Oracle 9i and a "certified" installation of an EMC fiber channel storage device.
They won't give a damn about what any other services come in the bundle (I know about a ton of Red Hat installations on different companies, all of them with their one-year standard upgrade services payed along the hardware that they won't even try to register at Red Hat Network). If any, the value-added services only mean problems and nuisances to them when if something "funny" arises and they call the hardware support, first they hear is "did you upgrade to BIOS patch version XXX, and controller Z version YYY" (after all it is *suppoused* that those "services" you payed for are exactly the existance of such patches -you wouldn't need support if you were sure everything is going to run flawlessly) or they try to ask to Red Hat and first they hear is "did you upgraded your kernel to version XXX?" or "did you applied security fix ABC?". All they want is some "bundled product" they pay a lot of money to install and have a piece of paper that says "certified" so their asses are covered, and then they want to forget about it for the next three or four years. Then they decomission all the hardware and software alike an buy a new "bundle".
That's the bussines of "selling" software and it works exactly the same for proprietary or open software because, deeply on, it has nothing to do with the software itself and it's all about brand recognition and warm feelings.
"Perhaps you can help explain this to me... I've never understood how one could easily sell GPL'd software."
You just put in a box and sell it. From where I currently stand I can view an old red and white box with a man on a funny hat printed on it. It's labelled "Red Hat 6.2" and do you know what's inside? GPL'd software packaged in a box and selled for a profit. I think I heared rumours recently that Red Hat is still in bussiness making money out of selling GPL'd software and some services around it, and I can say that some days ago I visited Dell's web page and peeked among their servers pages. There you could buy -online! hell, bussiness techniques are advancing day-in day-out mate, some servers -"poweredge" I think they call them, either with Windows (Vista or 2003, I really don't remember) for a price, or Red Hat -for a price too, so it must be true Red Hat is still in bussiness selling GPLed software.
"Actually, once something is GPL'd it's always GPL'd, so you can never change the license of a GPL'd work."
Well, the "problem" with this is that "source code" means two things at the same time: it's an abstract concept (like in "the source code of Emacs 11" which is the abstraction of all the copies ever made and those that could possibly be made -or the archetype of Emacs 11 if you are platonicly inclined), and it's a concrete thing (like the very CD I pass to you that contains a copy of the source code or the physical paper and ink of an impressed version).
It is true that the copy (the concrete thing) of a program you distributed to me under GPL terms is forever mine under GPL terms and the author can do nothing to revert this. But it is true too that -being the author and only copyright holder, he can make *further* copies of the source code and distribute those under any other license he deem apropiate, just like Stallman (provided he retains copyright of all the codebase) can tomorrow start distributing copies of Emacs 11 under a Microsoft-like EULA -that, of course, doesn't mean your already owned copies of Emacs 11 are anyless GPLed than before. So where previously there were only one archetype of the Emacs 11 source code, now we have two, one under the GPL and another under el Ms-like EULA.
" It is being forced in a concerted effort to force as many people as possible to use it in order to be under the new obligations."
OK, let's pay into your armaggedon scenario. Let's imagine the FSF already published the GPLv3; it already moved all its codebase to the new GPLv3, and it already "won the battle" and most GPL-liken developers are using it on their own developments. Now what? What is the real problem now?
There's certainly no problem to me. My software production/usage is terribly outbalance to the side of the usage. What are my new concerns regarding the use of GCC, Emacs, Subversion, etc.? Maybe I'm ill-informed but I really don't see any problem on this side. On the other side, for the short part of the software that I develop I know I can produce it under GPLv3, GPLv2, BSD or even a Microsoft-like EULA. Even more, I'm not planning development of any "DRM-powered", patent encumbered or "hardware usage-limiting" software, so I really can't see how the adoption of the GPLv3 for my own software (*even* if I were really obliged to use it, which I'm not) would badly affect myself. And even-even more, since I'm quite worried about where the devolpment of "DRM-powered", patent encumbered or "hardware usage-limiting" software can affect me as a software "consumer" I can only see advantages if your armaggedon scenario really came into live.
But surely I'm missing something. I hope you can enlight me -for all I've seen from you till now is nothing but hand waving, bruhaha, and unspecific claims about how bad will be the new GPLv3 that the FSF will impose over us by force in order to achive some dark and dirty... unstated whatevers. That's nothing but FUD on my book.
"I'm not entirely sure about a staff attorney, but if he is employed by the same company that is being sued you can probably get away with it - however, it's not an altogether shut and dry decision."
You are not "entirely sure"? Are you meaning that "maybe" an attorney office (since all its employees are attorneys) cannot claim or counterclaim at a minor offences court?
"a leak is not always illegal; But the leaker may be breaking contractual obligations"
Is it now legally acceptable to break contractual obligations?
"and i suppose it did not occur to you that there is a very good reason WHY open source is not used extensively in defence? who wrote that code? did you audit every single line?"
and i suppose it did not occur to you that there is a very good reason WHY closed source is not used extensively in defence? who wrote that code? did you audit every single line?
"But if someone leaks the code, is it then legal to distribute?"
Just properly rewrite your phrase and let's see:
"But if someone illegally distribute the code (that's a "leak", isn't it?), is it then legal to distribute?"
See?
"Why does it matter if it was developed or updated by more than one independent software provider?"
Yes, I really think so.
"As long as it is well-defined"
That's the point. Experience shows that you cannot seriously hope for such an entangled thingie as a document format (or network protocol) to be defined beyond shadows on a written standard. The only way to know you have a functional open standard is to have a look at the source code itself. I'd prefer taking away the "multiple providers" and to say instead "at least one open implementation of the standard" (followed, of course, by a proper definition for "open") as a way to demonstrate that the standard is factically doable; whenever the standard shows a shadowy corner you can point to the open implementation and say "it means you should implement it *this* way" (that worked quite good for things like TCP/IP or SMTP). Failing to that, having at least two independent *successful* implementators (and then we have to go after the definition of "successful"), shows that there's the chance to have an implementation directly out from the standard papers.
"PDF is developed solely by Adobe, yet it otherwise fits the bill as 'open'."
Till you crash against the patented parts; till you crash against the shadows on the standard definition and the only way to clarify it is trying to reverse-engineer Adobe's PDF viewer/distiller; till you crash against the development advantage Adobe has since they can have PDF Viewer version+1 the very day they publish a new version of the standard... since the PDF 'de facto' standard is that from Adobe it gets it an iron clad over PDF almost as if the standard were unpublished.
"I'm sorry but this appears to be self-contradictory. If branches are good, distributed VCS's are good, because they are based around branches as a core concept. You seem to be under the mistaken belief that a branch in a distributed VCS must be private. In fact, you can push or publish any branch"
I think one emerging problem with distributed VCS is that branches *can* go hidden. On a centralized SCM tool, branches are *always* public by default (to those with access to the central repo, of course), so you can always have a look at what other people is going on with. That have the potential to emerge stronger sinergies within your team, since other people can peek at any branch potentially at any time (even when the creator asumes it is still not ready for public scrutiny). On the other hand, private branches (thus decentralized development) has its own advantages too: like assuming (kind of Linus' "sense of humor") that 98% of all work will be rubish, so it's better done wherever it doesn't disturb "real" work.
So at the very end, different scenarios, different solutions. Not a great discover.
"I don't think there is anything especially wrong with Subversion. Sure it doesn't support changesets"
What do you mean exactly with "doesn't support changesets"? It does support atomic commits and branches. What else is need for "changesets" to be supported?