You can do all that on an iPhone too - you just jailbreak it
Thats an answer? Setting aside the legal (you're breaking the law) and technical (not easy for noobs to do) issues here, in this day and age, why in God's name should anyone have to *crack* their own damn *phone*?
Nokia's attempt to do this is too late
If Nokia was some unknown, or running in a distant third place, then maybe... except they're currently #1 in the market, so given their *current* position, how have you concluded at this early juncture that they're already 'too late'?
Even if they slip to #2 (or even #3) in the meantime while they get their software up-to-snuff, they've still got plenty of staying power due to their size and diversity. Geez, its not like they're on the verge of bankruptcy because of being a marginal player in the market or anything.
all over a clause that had to attribute to the developers be present in a binary release.
A rebellion was already brewing long before the clause issue. The infighting the GP referred to had been going on for *years* prior to this, but you don't fork something as massive as Xfree86 without serious consideration and thought, so there was much inertia. The clause problem was just the final straw that finally broke through the inertia.
The BSD patent wranglings were done and dusted quite a few years ago
*boogle*
That BSD 'wrangling' you refer to, e.g. the USL v. BSDi lawsuit, was about copyright & trademark, not patents.
If you really think running a *BSD protects you from patent trolls, then you don't understand the problem with software patents. Hint: if *BSD ever becomes as popular as Linux is now, it'll have *exactly* the same problem that Linux has now.
while allegations
You mean FUD?
[Yawwwn...]
legal actions against the Linux kernel are ongoing.
Wake me up when just *one* of those legal actions actually *succeeds*.
The way Linux is going at the moment we pretty much need a microkernel... Linus pretty much stated that a couple of weeks ago.
Bullshit.
His comment was about the size and complexity of the kernel, which is an inevitable occurrence for any OS that becomes popular. People went nuts over his comment only because at one point he used the word 'bloat' to refer to the problem, and folks started reading more into that than what he actually said or meant. However, anyone who actually read what *he* said, in full, rather than what others claimed he said, just yawned and asked 'Why is this a story?'.
And at no time did he ever mention microkernels, and since has reiterated his opinion about them.
But now there's this new kid in town in Linux, PulseAudio.
Which isn't actually necessary for most 'typical' users (whether their sound driver is ALSA or OSS).
Its talked about a lot only because of the decision of one popular distro to make it default on their system, which given the number of problems since reported, may have been premature, but I don't know the whole story as I don't use that distro.
Yea, and its a *really* difficult concept when it doesn't even make any sense.
You clearly do not know the story behind *why* Linux was trademarked (you would have if you'd bothered to read the last para of that section the GP's link points to).
The trademark was done to *ensure* Linux's continued freedom for the rest of us. Up until the point when that jackass showed up, none of the devs or users cared about the lack of a trademark.
Alas, there is always at least one greedy bastard willing to game the system for their own profit, with utterly no concern whatsoever for anyone else's freedom.
I never have understood why the Linux guys hate the registry so much.
I hated the registry back when I was a Windows guy, and I'm sure there are current Windows guys who also hate the registry. Its not even a Windows-only thing. The registry, or any closed, binary-blob configuration db, is an equal-opportunity hate-fest for many.
Do you really think hunting down a bazillion config files and editing them is better?
If there really was a bazillion of them, or if I really had to hunt them down, then I'd have to agree with you... except there isn't, and I don't, so I can't.:)
If you were as comfortable with a *nix system as you are obviously comfortable with a Win system, then you'd understand why I had to chuckle at your post...
But a lot of F/OSS software is developed to solve a particular (maybe rather specific) problem and the suggestion that it could be modified to solve both the original problem and another, new problem winds up getting shot down in flames.
What if the authors of the software in question have what they believe is a good reason (Internet Standards) to shoot down what they think is a bad suggestion?
(notwithstanding the fact that by this time virtually every major LDAP server on the planet except for OpenLDAP supported multimaster replication)
That was at the top of my Google search. Did you not know, or did you deliberately leave that out of your "example"?
Even if this support isn't the same as, or as complete as, the other implementations, that fact that it now exists ruins your use of openldap as an example of... wait, what *was* your point anyway? That people can disagree over technical issues, or what is the best way to implement something? That FOSS often places a higher value on standards than proprietary alternatives? And you think thats a *bad* thing?
At least with FOSS you can always fork it and do what you want anyway. With proprietary software, if begging doesn't work, you are SOL.
I don't believe commenting out a bunch of device drivers from GENERIC for hardware that is not even in the box will have much of an overall effect really.
Leaving out drivers for stuff you don't need does have a very big effect on kernel *compile* times, note that the OP referred to *recompiling* the kernel.
Why waste time compiling something you'll never need, and risk the possibility of compile failures from problems in that "cruft" code?
I could give a rats ass about how fast it compiles some app, show me some REAL benchmark!
Compile speed *is* a real benchmark, just obviously not one that interests you, but it is useful to others.
The problem Phoronix has is in finding a set of benchmarks that is useful to the largest segment of their readership. Judging by these sub-threads here, its clearly not easy.
The problem you're describing is not an issue just for Linux but most current 'conventional' OSes. On any OS with a shared memory space as you described, if you can a) 'hack' a pointer, and b) move or map your own code to where that 'hacked' pointer is now pointing to, and c) combine this with some other exploit/bug to get elevated privileges in the code you inserted earlier and take immediate advantage of this, then you can theoretically pwn the system whatever its OS (as always, it depends on the specific circumstances).
As you say, this is fundamentally a weakness of the hardware-assisted approach to process isolation, because in a paradigm that allows modifiable pointers in userland code, neither the hardware nor the OS can ever *really* know what the pointers are actually pointing to.
It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space)
Not sure I'd go as far as 'by design', at the very least its not an easy exploit to accomplish (not withstanding this latest problem), since it depends on finding at least one bug/flaw in the OS to let you do the first step of 'hacking' a pointer (and usually at least one more bug/flaw to be able to do something really dastardly), but yes, there is an overhead, and its certainly not a perfect model (what is?).
maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
If they can get it right, absolutely.
In fairness however, these OSes accomplish their goal by restricting you to a type-safe language(s), in effect, they (try to) avoid the problem of pointers being 'hacked' by eliminating the presence of writable/modifiable pointers that *can* be 'hacked' within running code. They use the strictness of the language as the protection mechanism, rather than hardware assistance. This however is not trivially easy to accomplish either (see jxos and their 'Isolates' mechanism they're having to shim into their system), which is why these OSes remain work-in-progress research projects. Then, once they do get it right, we won't be able to just 'port' all our current software over and take off, nope, all the software we use now will have to be rewritten in a type-safe language that that OS supports (or thrown out!), so the switching over process won't happen anytime soon.:(
It is a 'cool' idea though, if for no other reason than it avoids the overhead of the hardware assisted model, and eliminating modifiable pointers (at the source code level) in code will allow smarter static/jit compilers to safely do *far* more aggressive optimizations than they can do now, as modifiable pointers (especially if they can also be aliased) are the single biggest headache for any optimizing compiler.
Because the code may actually exist somewhere else other than GPL code. If it does not exist, there may be people elsewhere working to bring it into existence under a different license.
This is just a variation of the GP's point. If the code is under a license you can't use, then it effectively doesn't exist, and with a proprietary license that you couldn't afford, you'd have exactly the same problem.
That's a lot different than having hundreds of companies reinventing the wheel in isolation.
Guess what hundreds of companies did back when there was no open source software community at all?
The current state of affairs is at least a major improvement.
Whereas if I had reinvented the wheel, I seriously doubt the company would have let me make it available to others even though we weren't a software house.
If your company wasn't in the business of monetizing software, then they shouldn't have had a problem using GPLed software. I think you've left something out of your example, because as it stands, I can't tell what the problem was.
I definitely would have had no time at all to support or maintain it for others.
There is *no* FOSS license that requires the author to provide support or maintenance. How is this a GPL-specific problem?
They get modifications and improvements to their code contributed back to them. Is that really so hard to see?
I need to make the source for the modified kernel available to my customers, which they are free to redistribute, but the greater linux kernel community has no such right to the source unless they purchase one of the machines.
Or one, just one, of your customers uploads a copy of your source to the net somewhere, which they are free to do.
Yes, your example is theoretically possible, but it obviously isn't a common occurrence. A much more common example is modified GPLed stuff being used in-house, and thus never released because its never distributed, and yet that has not hurt the popularity or use of GPLed software either.
I see comments saying that the GPL means people have to give back. This is not, and has never been the case.
Does finding a (rare) exception to a rule, automatically invalidate the rule? If this were true then the more common exception I gave above would have already invalidated it.
So, how much can you trust open source software?
More than closed source, since at least I can read it.
Can you be sure it isn't infringing someones copyright?
If I can read it, so can others. If there's a problem, it is much more likely to come out eventually.
The answer is usually no, unless you wrote it yourself.
Even writing it yourself isn't a guarantee you won't be sued. See SCO v Linux.
As a developer, I will never release software under the GPL, but I will release software under actually free licenses like BSD or Apache.
That's called freedom of choice, and yes, its a good thing... unless you object to others choosing differently.
For a recent application, I wanted to use the ExtJS framework because of how awesome it is. This is a commercial product I'm developing. So our choices were to use the GPL license for ExtJS, and release all of our code also, or pay ExtJS for a proprietary license and have the right to do whatever we want to do with our code. We chose the option where we pay ExtJS for their work.
You may not realize this, but in this example, the GPL worked exactly the way the ExtJS developers intended it to.
It's about the freedom to use the code that I write the way that I want to use it without having another license tell me what I can and can't do with my own code.
This is exactly what you got in this example. You paid them for a different license to get the freedom that you wanted. You got your freedom, they get to keep their freedom, so what exactly are you complaining about?
Are you complaining that the ExtJS devs *also* released under the GPL so that anyone willing to abide by its terms could use their stuff without paying? Is that not their *own* freedom to do so? Are you placing your own freedom over theirs? Is that fair?
then you're missing the point and you don't understand business.
If you put yourself in the shoes of the ExtJS devs and thought about it from their perspective, maybe you'd begin to understand why some people use/prefer the GPL
Besides, judging from the ExtJS website, and the fact they made a nice chunk of change out of their transaction with your company, they also seem to understand business... yet they obviously aren't afraid of the GPL.
I'm sorry but I think you need to polish your anti-GPL argument some more, and FYI, next time don't use as an example GPL software that has been successfully commercialized by a for-profit company.
Right, and what some people think is a valid "short, fair-use quotation", other people might think is a copyright violation!
Lawsuits over fair-use quotations are a regular occurrence (recent legal threats and lawsuits by AP, as an example), aided by the fact that the courts have not provided a clear guideline for determining 'how-much-is-too-much'.
Same problem here.
of the app's developer to use their lib in violation of the lib's license.
But the issue is precisely that the GPL explicitly only applies to distributing, not to using the work:
I shouldn't have used the word "use" there. My response was to the claim that its the end user that does the violating, so I wasn't careful about the use/distribute wording.
The FSF view is that a "derivative work" is created when the app's developer builds the app with that embedded information from their library, and that the GPL violation happens when that app is *distributed*.
The combination of the app and that embedded info, which is a copy or modification of part of their library, is, in their minds, a "derivative work".
The definition of a "derivative work" is the problem. That comes from copyright law, so the problem isn't so much with the GPL or any other license, but with the copyright law itself. The legal system, just like with the problem of fair-use quotations, has yet to give us a clear, precise definition of what is, and isn't, a "derivative work". Its the 'how-much-is-too-much' problem all over again, only applied to pieces of *software* instead of pieces of *text*.
Is the FSF pushing the "derivative work" concept too far? Possibly, I simply don't know, but then again, they do provide the LGPL as an alternative, and obviously, there are always other licenses to choose from.
I'll admit I'm still dithering between GPLv3 and AGPL
Hi,
I'm just curious about why your dithering. From my quick look at them, isn't AGPL3 and GPL3 almost identical except for section 13, and since the same section in the GPL explicitly allows the combination of GPL & AGPL in the same project, it almost doesn't matter which one you use? Or are you just referring to which one you would automatically use as your "default license"?
Is there some other significant difference/connotation that I haven't noticed between them?
if there is a violation going on (i.e., if the runtime combination in memory constitutes a derived work)
Please reread my first post concerning how a linker knows what to link to the program being run. At the time the program is built (by its developer, not the user), it has embedded within it information about the libraries, and their functions and data, it needs at runtime.
This embedded information, depending on specific circumstances, often goes beyond just the name of a library, thus it goes beyond simply a citation of one book from another, as in your example. That embedded information usually includes very specific info about function names and function signatures, variable names and their data types, and may even include constants, e.g. raw data or numbers that are defined in the library itself.
then it seems like the user is the one violating the license (he actually made the copy of the work).
This would only be true if its the user that does the actual building of the program from source, since the info I mentioned above gets embedded into the program at the time its built, not when run.
As I said in the first post, I don't necessarily agree that that info by itself constitutes copyright infringement, in my own mind it would depend on what that embedded information actually is, but that is the position of the FSF, at least.
Slashdot Mirror
The GPL has been tested in court? I must have missed this one.
No, actually you missed all of them.
In the US: http://www.fsf.org/news/wallace-vs-fsf
In Germany: http://www.linux.com/archive/articles/57353
In France: http://opendotdotdot.blogspot.com/2009/09/big-win-for-gnu-gpl-in-france.html
Just google 'GPL tested court' for more links (there are older cases that got in front of a judge too)...
You can do all that on an iPhone too - you just jailbreak it
Thats an answer? Setting aside the legal (you're breaking the law) and technical (not easy for noobs to do) issues here, in this day and age, why in God's name should anyone have to *crack* their own damn *phone*?
Nokia's attempt to do this is too late
If Nokia was some unknown, or running in a distant third place, then maybe... except they're currently #1 in the market, so given their *current* position, how have you concluded at this early juncture that they're already 'too late'?
Even if they slip to #2 (or even #3) in the meantime while they get their software up-to-snuff, they've still got plenty of staying power due to their size and diversity. Geez, its not like they're on the verge of bankruptcy because of being a marginal player in the market or anything.
The fork was a huge waste of time and energy....
if you say so...
all over a clause that had to attribute to the developers be present in a binary release.
A rebellion was already brewing long before the clause issue. The infighting the GP referred to had been going on for *years* prior to this, but you don't fork something as massive as Xfree86 without serious consideration and thought, so there was much inertia. The clause problem was just the final straw that finally broke through the inertia.
The BSD patent wranglings were done and dusted quite a few years ago
*boogle*
That BSD 'wrangling' you refer to, e.g. the USL v. BSDi lawsuit, was about copyright & trademark, not patents.
If you really think running a *BSD protects you from patent trolls, then you don't understand the problem with software patents. Hint: if *BSD ever becomes as popular as Linux is now, it'll have *exactly* the same problem that Linux has now.
while allegations
You mean FUD?
[Yawwwn...]
legal actions against the Linux kernel are ongoing.
Wake me up when just *one* of those legal actions actually *succeeds*.
[Zzzzzzz...]
The way Linux is going at the moment we pretty much need a microkernel ... Linus pretty much stated that a couple of weeks ago.
Bullshit.
His comment was about the size and complexity of the kernel, which is an inevitable occurrence for any OS that becomes popular. People went nuts over his comment only because at one point he used the word 'bloat' to refer to the problem, and folks started reading more into that than what he actually said or meant. However, anyone who actually read what *he* said, in full, rather than what others claimed he said, just yawned and asked 'Why is this a story?'.
And at no time did he ever mention microkernels, and since has reiterated his opinion about them.
But now there's this new kid in town in Linux, PulseAudio.
Which isn't actually necessary for most 'typical' users (whether their sound driver is ALSA or OSS).
Its talked about a lot only because of the decision of one popular distro to make it default on their system, which given the number of problems since reported, may have been premature, but I don't know the whole story as I don't use that distro.
You make it sound as though that's a unique issue.
Glibc and cdrtools are the main two [counter-examples] that immediately come to mind.
Both of which have since been been forked(1)(2) precisely because of their 'schizophrenic'(3) maintainers.
1 : depending on your definition of what a fork is.
2 : 'glibc' -> 'eglibc' , 'cdrtools' -> ( 'cdrkit' | 'dvd+rw-tools' )
3 : or whatever the actual diagnosis turns out to be.
The ONE TRUE indentation style, of course.
Please Philip, only one flamewar at a time, it gets really hard to follow the action with two or more happening simultaneously... :)
Deadpan humour. It is a difficult concept.
Yea, and its a *really* difficult concept when it doesn't even make any sense.
You clearly do not know the story behind *why* Linux was trademarked (you would have if you'd bothered to read the last para of that section the GP's link points to).
The trademark was done to *ensure* Linux's continued freedom for the rest of us. Up until the point when that jackass showed up, none of the devs or users cared about the lack of a trademark.
Alas, there is always at least one greedy bastard willing to game the system for their own profit, with utterly no concern whatsoever for anyone else's freedom.
I never have understood why the Linux guys hate the registry so much.
I hated the registry back when I was a Windows guy, and I'm sure there are current Windows guys who also hate the registry. Its not even a Windows-only thing. The registry, or any closed, binary-blob configuration db, is an equal-opportunity hate-fest for many.
Do you really think hunting down a bazillion config files and editing them is better?
If there really was a bazillion of them, or if I really had to hunt them down, then I'd have to agree with you... except there isn't, and I don't, so I can't. :)
If you were as comfortable with a *nix system as you are obviously comfortable with a Win system, then you'd understand why I had to chuckle at your post...
But a lot of F/OSS software is developed to solve a particular (maybe rather specific) problem and the suggestion that it could be modified to solve both the original problem and another, new problem winds up getting shot down in flames.
What if the authors of the software in question have what they believe is a good reason (Internet Standards) to shoot down what they think is a bad suggestion?
(notwithstanding the fact that by this time virtually every major LDAP server on the planet except for OpenLDAP supported multimaster replication)
Except that OpenLDAP v2.4.xx now has multi-master replication support: http://www.openldap.org/faq/data/cache/1240.html
That was at the top of my Google search. Did you not know, or did you deliberately leave that out of your "example"?
Even if this support isn't the same as, or as complete as, the other implementations, that fact that it now exists ruins your use of openldap as an example of... wait, what *was* your point anyway? That people can disagree over technical issues, or what is the best way to implement something? That FOSS often places a higher value on standards than proprietary alternatives? And you think thats a *bad* thing?
At least with FOSS you can always fork it and do what you want anyway. With proprietary software, if begging doesn't work, you are SOL.
I don't believe commenting out a bunch of device drivers from GENERIC for hardware that is not even in the box will have much of an overall effect really.
Leaving out drivers for stuff you don't need does have a very big effect on kernel *compile* times, note that the OP referred to *recompiling* the kernel.
Why waste time compiling something you'll never need, and risk the possibility of compile failures from problems in that "cruft" code?
I could give a rats ass about how fast it compiles some app, show me some REAL benchmark!
Compile speed *is* a real benchmark, just obviously not one that interests you, but it is useful to others.
The problem Phoronix has is in finding a set of benchmarks that is useful to the largest segment of their readership. Judging by these sub-threads here, its clearly not easy.
If a GPL'd operating system, like Linux, came to dominate the business and consumer OS market
...
If so, how?
The 'if' and 'how' are irrelevant because...
why no significant action in that direction?
Answer: Microsoft.
In normal configs, Linux is vulnerable
The problem you're describing is not an issue just for Linux but most current 'conventional' OSes. On any OS with a shared memory space as you described, if you can a) 'hack' a pointer, and b) move or map your own code to where that 'hacked' pointer is now pointing to, and c) combine this with some other exploit/bug to get elevated privileges in the code you inserted earlier and take immediate advantage of this, then you can theoretically pwn the system whatever its OS (as always, it depends on the specific circumstances).
As you say, this is fundamentally a weakness of the hardware-assisted approach to process isolation, because in a paradigm that allows modifiable pointers in userland code, neither the hardware nor the OS can ever *really* know what the pointers are actually pointing to.
It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space)
Not sure I'd go as far as 'by design', at the very least its not an easy exploit to accomplish (not withstanding this latest problem), since it depends on finding at least one bug/flaw in the OS to let you do the first step of 'hacking' a pointer (and usually at least one more bug/flaw to be able to do something really dastardly), but yes, there is an overhead, and its certainly not a perfect model (what is?).
maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
If they can get it right, absolutely.
In fairness however, these OSes accomplish their goal by restricting you to a type-safe language(s), in effect, they (try to) avoid the problem of pointers being 'hacked' by eliminating the presence of writable/modifiable pointers that *can* be 'hacked' within running code. They use the strictness of the language as the protection mechanism, rather than hardware assistance. This however is not trivially easy to accomplish either (see jxos and their 'Isolates' mechanism they're having to shim into their system), which is why these OSes remain work-in-progress research projects. Then, once they do get it right, we won't be able to just 'port' all our current software over and take off, nope, all the software we use now will have to be rewritten in a type-safe language that that OS supports (or thrown out!), so the switching over process won't happen anytime soon. :(
It is a 'cool' idea though, if for no other reason than it avoids the overhead of the hardware assisted model, and eliminating modifiable pointers (at the source code level) in code will allow smarter static/jit compilers to safely do *far* more aggressive optimizations than they can do now, as modifiable pointers (especially if they can also be aliased) are the single biggest headache for any optimizing compiler.
I didn't say the GPL doesn't work, just that it doesn't work for business.
http://extjs.com/company
Any more overly-broad, sweeping generalizations that you want to make?
makes money through support, training and consulting services.
That does not contradict the GP's statement at all:
a business based largely on GPL licenced code
is a derivative work of whatever (shared) libraries it links to, and that the binary is therefore subject to their copyright.
No, only the part of the binary that is *their* code, not your code. Your code is always yours.
Because the code may actually exist somewhere else other than GPL code. If it does not exist, there may be people elsewhere working to bring it into existence under a different license.
This is just a variation of the GP's point. If the code is under a license you can't use, then it effectively doesn't exist, and with a proprietary license that you couldn't afford, you'd have exactly the same problem.
That's a lot different than having hundreds of companies reinventing the wheel in isolation.
Guess what hundreds of companies did back when there was no open source software community at all?
The current state of affairs is at least a major improvement.
Whereas if I had reinvented the wheel, I seriously doubt the company would have let me make it available to others even though we weren't a software house.
If your company wasn't in the business of monetizing software, then they shouldn't have had a problem using GPLed software. I think you've left something out of your example, because as it stands, I can't tell what the problem was.
I definitely would have had no time at all to support or maintain it for others.
There is *no* FOSS license that requires the author to provide support or maintenance. How is this a GPL-specific problem?
How is this payment to the original author?
They get modifications and improvements to their code contributed back to them. Is that really so hard to see?
I need to make the source for the modified kernel available to my customers, which they are free to redistribute, but the greater linux kernel community has no such right to the source unless they purchase one of the machines.
Or one, just one, of your customers uploads a copy of your source to the net somewhere, which they are free to do.
Yes, your example is theoretically possible, but it obviously isn't a common occurrence. A much more common example is modified GPLed stuff being used in-house, and thus never released because its never distributed, and yet that has not hurt the popularity or use of GPLed software either.
I see comments saying that the GPL means people have to give back. This is not, and has never been the case.
Does finding a (rare) exception to a rule, automatically invalidate the rule? If this were true then the more common exception I gave above would have already invalidated it.
So, how much can you trust open source software?
More than closed source, since at least I can read it.
Can you be sure it isn't infringing someones copyright?
If I can read it, so can others. If there's a problem, it is much more likely to come out eventually.
The answer is usually no, unless you wrote it yourself.
Even writing it yourself isn't a guarantee you won't be sued. See SCO v Linux.
As a developer, I will never release software under the GPL, but I will release software under actually free licenses like BSD or Apache.
That's called freedom of choice, and yes, its a good thing... unless you object to others choosing differently.
For a recent application, I wanted to use the ExtJS framework because of how awesome it is. This is a commercial product I'm developing. So our choices were to use the GPL license for ExtJS, and release all of our code also, or pay ExtJS for a proprietary license and have the right to do whatever we want to do with our code. We chose the option where we pay ExtJS for their work.
You may not realize this, but in this example, the GPL worked exactly the way the ExtJS developers intended it to.
It's about the freedom to use the code that I write the way that I want to use it without having another license tell me what I can and can't do with my own code.
This is exactly what you got in this example. You paid them for a different license to get the freedom that you wanted. You got your freedom, they get to keep their freedom, so what exactly are you complaining about?
Are you complaining that the ExtJS devs *also* released under the GPL so that anyone willing to abide by its terms could use their stuff without paying? Is that not their *own* freedom to do so? Are you placing your own freedom over theirs? Is that fair?
then you're missing the point and you don't understand business.
If you put yourself in the shoes of the ExtJS devs and thought about it from their perspective, maybe you'd begin to understand why some people use/prefer the GPL
Besides, judging from the ExtJS website, and the fact they made a nice chunk of change out of their transaction with your company, they also seem to understand business... yet they obviously aren't afraid of the GPL.
I'm sorry but I think you need to polish your anti-GPL argument some more, and FYI, next time don't use as an example GPL software that has been successfully commercialized by a for-profit company.
and some short (fair use) quotations.
Right, and what some people think is a valid "short, fair-use quotation", other people might think is a copyright violation!
Lawsuits over fair-use quotations are a regular occurrence (recent legal threats and lawsuits by AP, as an example), aided by the fact that the courts have not provided a clear guideline for determining 'how-much-is-too-much'.
Same problem here.
of the app's developer to use their lib in violation of the lib's license.
But the issue is precisely that the GPL explicitly only applies to distributing, not to using the work:
I shouldn't have used the word "use" there. My response was to the claim that its the end user that does the violating, so I wasn't careful about the use/distribute wording.
The FSF view is that a "derivative work" is created when the app's developer builds the app with that embedded information from their library, and that the GPL violation happens when that app is *distributed*.
The combination of the app and that embedded info, which is a copy or modification of part of their library, is, in their minds, a "derivative work".
The definition of a "derivative work" is the problem. That comes from copyright law, so the problem isn't so much with the GPL or any other license, but with the copyright law itself. The legal system, just like with the problem of fair-use quotations, has yet to give us a clear, precise definition of what is, and isn't, a "derivative work". Its the 'how-much-is-too-much' problem all over again, only applied to pieces of *software* instead of pieces of *text*.
Is the FSF pushing the "derivative work" concept too far? Possibly, I simply don't know, but then again, they do provide the LGPL as an alternative, and obviously, there are always other licenses to choose from.
guilt isn't a perfect motivator, but neither is a well-crafted license
Guilt doesn't have the power of copyright law behind it....
I'll admit I'm still dithering between GPLv3 and AGPL
Hi,
I'm just curious about why your dithering. From my quick look at them, isn't AGPL3 and GPL3 almost identical except for section 13, and since the same section in the GPL explicitly allows the combination of GPL & AGPL in the same project, it almost doesn't matter which one you use? Or are you just referring to which one you would automatically use as your "default license"?
Is there some other significant difference/connotation that I haven't noticed between them?
Thanks,
As this comment points out,
That post was the one my post was replying to.
if there is a violation going on (i.e., if the runtime combination in memory constitutes a derived work)
Please reread my first post concerning how a linker knows what to link to the program being run. At the time the program is built (by its developer, not the user), it has embedded within it information about the libraries, and their functions and data, it needs at runtime.
This embedded information, depending on specific circumstances, often goes beyond just the name of a library, thus it goes beyond simply a citation of one book from another, as in your example. That embedded information usually includes very specific info about function names and function signatures, variable names and their data types, and may even include constants, e.g. raw data or numbers that are defined in the library itself.
then it seems like the user is the one violating the license (he actually made the copy of the work).
This would only be true if its the user that does the actual building of the program from source, since the info I mentioned above gets embedded into the program at the time its built, not when run.
As I said in the first post, I don't necessarily agree that that info by itself constitutes copyright infringement, in my own mind it would depend on what that embedded information actually is, but that is the position of the FSF, at least.