Do I leave his name on it? Do I replace his with mine? Do I append my name to his, to create a list of copyright holders?
By including his code in yours, you have created a work that belongs to you but is derived from his. You both have various rights to it. You must keep his copyright notice intact.
If his code is a separate file, just don't change anything in it and you will be fine. Otherwise include his copyright in a comment above his code. It is not required in some cases to include his copyright in your documentation or README, but it is the polite thing to do. Something along the order of "Portions of this program Copyright by J. Random Hacker" is fine.
it would surely become unwieldy after the code had been handed around through 50 authors.
Look at the Linux source code:-)
I recommend (as a layman) all contributors assign their copyrights to the project copyright holder if they are specifically contributing to the project. (of course, if you are borrowing code from elsewhere you won't be able to do it) When it comes time to change the licensing (from GPLv2 to GPLv3), you won't have to get a hundred hackers to agree. Even tiny NASM with only two copyright holders can't agree on the licensing.
The more common names for these two types of licenses are "unrestricted" and "copyleft". In a nutshell they are defined as "no restrictions on this source code" and "this must always remain free in all incarnations." Unfortunately, these are mutually exclusive, and will always be at odds with each other.
You illustrate one big problem with slashdot: you think differences of opinions are trolls. The previous post was not a troll. If it were it would have simply said "the GPL is not free". But that is not what it said. It said in essence "the GPL is not free and here is why...". Big difference.
1) Use the license YOU want to use on your own projects. If you don't like copyleft licenses then don't use them. If you don't like unrestricted licenses then don't use them. Easy, isn't it? But by all means, don't go creating your own new license. There are enough good ones out there that it isn't necessary. There are still some licensing niches to fill in the OSS hierarchy, but I doubt your project fits that bill. The BSD, MIT, GPL, LGPL, MPL, QPL and Artistic licenses are sufficient to meet your needs.
2) Don't get religious over licensing. The well known licenses all have their place. As soon as you say "I will never use the BSD/GPL/QPL/whatever license" you will immediately run across a situation where you will need it. I am personally not fond of copyleft, but if I were to release a commercial open source product that faced competition, you can bet you bippy that I would seriously consider using the GPL. Likewise, don't let license bigotry get in the way of your helping out on other people's projects.
3) Assign your copyrights over to the author. Don't insist on holding on to the copyright for your bug fixes and minor contributions. That's so egotistical as to be stupid. You will get mentioned in the credits, so don't worry about it. You will make the author's life so much easier. If your are the original author or project maintainer, then insist that all copyrights be assigned to the you or the project. If you want your project to be "community based", then seriously consider assigning your copyright to the FSF, creating your own non-profit org, or placing it in the public domain. Do you really want the submitter of a five line bug fix to be in control of all licensing decisions from here on out?
If a solution could be found which did away with software ownership and still preserved the freeness of free software, I'm sure the FSF would jump all over it.
The only way to guarantee certain attributes of Free Software is to own the software. If you wish that all distributions of your authored software retain access to the source code, you have to have sufficient ownership rights in it order to assert that control. You cannot control something if you do not own it (unless you employ coercion).
There's nothing wrong or hypocritical with opposing software ownership, and then using it as a means to the end of free software.
If the FSF viewed software ownership like "fire", then fought fire with fire, that's okay. But reading throught the FSF pages, I get the distinct impression that they believe software ownership to be evil and immoral. If so, then owning software with a GPL label on it is still evil and immoral. It would be like fighting murder with murder. As my Mother always told me, two wrongs do not make a right.
As an aside, if the FSF ever got its wish and copyright law suddenly disappeared, nothing much would change. The vast majority of proprietary licenses are not predicated on copyright law, but on contract law. Lack of copyright law would not affect the Microsoft EULA in any way. What would happen is that those people who wished to protect their software ownership rights (whether the be Free or proprietary) would find other ways to do so besides relying on government recognition. Take a look at this Free Nation article for an anarcho-capitalist look at copyright law. The Free Nation site also has other articles on intellectual property from a libertarian perspective, including the one mentioned at GNU.
And that, in a nutshell, is the irony. You shouldn't own software. It's derivitives shouldn't be owned either. They only way to prevent owned derivitives is to own the original.
I think the FSF just started off on the wrong premises. None of their conclusions would have been affected if they had admitted it's okay to own software. In some ways their arguments could even have been strengthened by admitting that it's okay. After all, how can you share what you don't own?
A common misconception. Only the author of a work is allowed to change the copyright or licensing.
What you CAN do with a BSD program is to wrap it with a GPL license. But any recipient has full legal authority to remove the "wrapper" from all BSD parts. Because of this, wrapping a bare BSD application with the GPL is pointless. It does serve a purpose, however, when you wish to combine a BSD module with a GPLd module.
In reference to a Qt/Embedded version of Kicker, the licenses are in conflict. The BSD license gives the users many permissions that the GPL does not. You can indeed by sued by Trolltech for exercising the rights given you by the Kicker authors.
The BSD license is considered compatible with the GPL because you can include BSD code within GPL code, and distribute the whole under the GPL. But the reverse is not allowed. You cannot include GPL code within BSD code and distribute the whole under the BSD license. You would have to remove the GPL code first. And since Qt/Embedded is GPL, you could not distribute Kicker under the the author's own license without first "removing" Qt/Embedded.
But this is not how copyright law defines distribution, and the GPLv2 clearly states it is operating under copyright law.
If my friend uses my modified GIMP over the network, he is not receiving GIMP. No portion of the binary is being transmitted to him. What is the legal difference between his using my GIMP locally on my machine or using it remotely on my machine?
I don't see any substantial difference between downloading a binary and running it locally, and running that binary remotely on someone's web server
In the former, I have actually distributed GIMP to you. You now possess a copy of it. In the latter you do not possess a copy of it, since the software has not been transmitted to you.
...programs covered more free, because it means that improvements will make it back to the community...
This is not the freedom of Free Software, but closer to the openness of Open Source. Contributing back to the community is merely a side effect of Free Software, not its goal. Users only have the right to source code for those programs they possess of copy of.
I do not restrict your freedom by putting a lock on my own door. I can only do that by putting a lock on *your* door.
There is a way for the GPL to restrict this modified GIMP of mine and still be operating under copyright law. And that is to start regulating Public Performance. This would be a very radical thing to do, and the implications of opening this pandora's box should be thought out long and hard.
Okay, that's interesting, and one I haven't heard before.
You say "after linking must be under the GPL". Does this mean only temporarily while the user is running the program, or that that the author must distribute it under the GPL after linking it at build time? In other words, would Debian (as an example) offer the application under the BSD license, or would they have to offer it under the GPL? In the case of the latter, the GPL is still effectively telling me what license to use.
If any of these are illegal, then isn't this extremely unfriendly to every known license other than the GPL, including the BSD licenses and public domain licenses?
You could cut the irony with a knife. On one hand, the FSF does not want people to own software. On the other hand, they explicitly discourage the use of public domain. That they could sue you for refusing to own your work that linked to libreadline seems par for the course. It's okay if you give your stuff to the FSF, but give it to the public and you'd better get a lawyer.
Using 'printf' won't make your application a derivative of anything. You can't copyright an API, especially not the C API. You can only copyright the implementation. RMS could have kept glibc under the straight GPL and he couldn't have stopped anyone from using 'printf' on GNU or Linux systems.
The analogy does not work for static libraries. But it does work for dynamic libraries, and is almost perfect for runtime libraries.
If a take a particular binary and translate its machine code into English, I would find something very similar to "this program references routines in libreadline.so", and "jump to this relocatable address." In neither case is code from the library actually included in the application. All that are there are references. Of course, header files could be written so that using them places library code directly into the application (macros or inlines), but the basic concept of dynamic linkage is still referencing.
Most literary works do not strictly require the reader to look up and read all of the references in the bibliography or footnotes, while most software applications do. But I don't think the manner in which a work is used has any bearing upon its derivation.
The "direction" comes from derivation and ancestry. The word is not in the GPL, but "direction" is an easy metaphor to understand. All code that is distributed as part of a GPL package must not add any additional restrictions, but the package must always be distributed under the terms of the GPL. So I could include a BSD licensed module in a GPL package since the BSD license is compatible with the GPL. But I could not use a GPLd module in a BSD package, because the BSD license would be changing the distribution terms of the module.
As for the wrapper stuff, that was the argument that RMS used. I do not have his exact quote readily available, so I apologize if I erred in its paraphrase. It was in response to a question as to why Free but non-GPL applications should not be able to link with GPL libraries.
No, there is a "direction" to compatibility. You can link a GPL application to a BSD library, but you cannot do the reverse. The argument that RMS makes is that someone could write a BSD wrapper for a GPL library, then link a proprietary application to the BSD library, thus circumventing the GPL.
No, it is a good example. Copyrighted works should be treated the same as any other copyrighted works. That current law treats software differently than literary works only illustrates the technical ignorance of some legislaters and judges.
Fair Use is kept deliberately vague and loosely defined in law, since listing some specific Fair Use rights would imply that any unlisted rights were forbidden. To my mind, and in every direction that I look at it from, dynamically linking to a library is Fair Use. That's the whole point of creating a libary to begin with. If the GPL doesn't want non-GPL applications dynamically linking to GPL code, then it should stop pretending that it is operating under copyright law, and come right out and admit it's really a EULA. Copyright law gives me the right to freely reference a work, and so should the GPL.
But if loosening the current GPL protections is against the spirit of the current license, then wouldn't tightening the protections be the same?
I see the spirit of the GPL as being a set of permissions (with conditions) granted to the user over and beyond what copyright allows. But some of these GPLv3 proposals I have seen would have to add a restriction on top of what copyright imposes, particularly with regards to the ASP "loophole". In or other words, the GPLv2 is a copyright based license, but the GPLv3 could end up being a contract based license.
But the embedded version is not dual licensed under the QPL. This is a serious mistake on Trolltech's part. Konqueror was just ported to work with Qt/Embedded, and it's cool! But it is ILLEGAL to port Kicker or KWin over. Kicker and KWin are under the BSD license. They cannot link to a GPL library. I have written a Qt application that would be perfect on a palmtop, but it cannot use Qt/Embedded since it is under the BSD license.
I am so glad that RMS is still in the comments gathering stage. Some of the proposals I've seen for GPL are very unfree (in both the FSF and the dictionary sense). These proposals seem to be more about protecting the author's sensibilities rather than eliminating the traditional restrictions normally tied to software.
1) Further restrictions upon linkage. Dynamic and runtime linkage is *using* the software in the manner it was meant to be used. And the freedom to use the software in any way is the FIRST freedom listed by the FSF. It's sensible at times to restrict what libaries an application can link to, because that could co-opt the application and make it unfree. But the reverse is impossible. There is no way to make a libary unfree by using it for an unfree application. No derivative work is being made under copyright law. Nothing is being modified or distributed with additional restrictions. The only thing being hurt is the author's sensibilities.
In RMS' zeal to prevent proprietary authors from using his libraries, he ends up hurting Free Software authors who use non-GPL licenses. The GPLv3 should be looking at ways to include non-GPL but Free Software authors in the community, instead of seeking further ways to exclude them. As it now stands, software in the public domain or under a BSD, MIT or other "copycenter" license cannot use GPLd libraries, such as readline or Qt/Embedded. Some proposals for the GPLv3 would further alienate these freedom loving folk.
Looking at the various dynamic (not static) libraries in existance, the only ones that I know of that dictate the terms of the application's licensing are are small subset of "Free" Software libraries. (there may be some proprietary licenses that do this, I am just not aware of any) Microsoft doesn't care how I license my MFC application. RogueWave doesn't care how I license my Tools++ application. Only the FSF demands I use a specific license for my own original and non-derivative works.
2) New restrictions upon use. That RMS is even contemplating this scares me. By *use* I mean the ASP "loophole". Again, this is another case where the only harm is harm to the author's sensibilities. RMS and the GPLv2 allows me to modify GIMP (as an example) for my own private use. They do not restrict my friends from coming over to my residence and using the modified GIMP on my computer. But the GPLv3 will regulate how my friends can use my modified copy of GIMP if they do so over the internet instead of physically walking to my residence. Where is the logic in this?
There are parts in the GPL v 2 that need cleaning up and clarifying. Please do so. But don't add new unprecedented restrictions. If the only thing being hurt is your sensibilities then leave it out.
Corel had the right idea. They did it the wrong way.
Linux and BSD are at a crossroads. The operating systems are complete. They are stable. Now its time to do something with them. Distributions now need to differentiate themselves by their target audience. One of these audiences is the average non-hacker desktop user. Corel was correct to target this market. Some other distros are making a mistake by trying to make a one-size-fits-all distribution.
But they did it the wrong way. The set it up so that they were always "following" Debian. They forked KDE, making the users ask "keep the Corel file manager or upgrade to KDE 1.1.2?" They bombed on marketing. It wouldn't install on a lot of systems.
But their target market still needs their own distribution. They don't want to wade through six or seven CDs trying to figure out what packages they need and what they don't. They want an easy to use installer, not a GUI wrapper. They want it small enough to be able to learn it. They want a browsable package installer/updater. They want compatibility with other distributions.
All of the parts are there, but only Corel ever got around to putting it all together. Some distros need to become the "server" distros, others the "hacker" distros, and some could be the "kitchen sink" distros. But at least one needs to be the "man on the street" distro.
You gave the answer right there: Module-2 is a great teaching language. That is a good enough reason to teach it for beginning CS students. But at the same time it shouldn't be used for upper division course work.
When I went to university, the first CS class was Pascal. That was a primo decision on their part. I learned how to program instead of how to fiddle with syntax. Today, Pascal would still be a good choice for CS101, but I would also add Java and Python. After that, the next class was assember (PDP-8).
Then, to our horror of horrors, we were thrust into "real" programming. "This is Unix, this is C, you know nothing of them, but the first assignment is due this friday". It was rough those first five days, but since we were firmly grounded in programming as opposed to syntax, we made the transition with flying colors.
The word "hacker" predated computers by decades. It meant someone who who did "quick and dirty" work with no regard to quality. In the building trades, a contracter who works quick and dirty is called a "hack". A general contracter who is behind budget will tell his foreman to "go get a hacker". Or consider the hack writer. He wants to write the next great novel, but he has to feed his family so he hacks out romances.
Does this meaning fit today's computer hackers and "crackers"? Scary, ain't it?
Where's the evidence that it's due to deregulation? In fact, where's the evidence that the industry was even deregulated to begin with? The fact was that it was not deregulated. It was only opened up for potential competition. The PUC is still firmly in place. The monopoly rights of the utilities was taken away, the regulation was not.
There are many problems with the current power "shortage". But I don't see any of these problems arising from too many power providers. Quite the opposite. There are too few providers and even fewer producers. The California population keeps on growing while the power produced keeps on shrinking. It's next to impossible to get government (read 'regulated') approval to create a new power plant. In the meantime the older plants are starting to fall apart. The industry wants to build a huge plant in San Jose but politics is stopping it. They also want to create dozens of mini plants but they can't do that either. We really need nuclear plants to avoid the pollution of gas/coal plants, but even suggesting it is political suicide here.
The potential competitors of PG&E and Edison would have to be nuts to enter the California market. Which is why the only alternatives you see are resellers of out-of-state surplus (as if they would have any in the middle of winter) and tiny environmental producers like wind or solar. Power production needs a huge economy of scale backed by an army of lawyers. What we really need is inexpensive point production, like microplants or personal fuel cells.
Slashdot Mirror
Do I leave his name on it? Do I replace his with mine? Do I append my name to his, to create a list of copyright holders?
:-)
By including his code in yours, you have created a work that belongs to you but is derived from his. You both have various rights to it. You must keep his copyright notice intact.
If his code is a separate file, just don't change anything in it and you will be fine. Otherwise include his copyright in a comment above his code. It is not required in some cases to include his copyright in your documentation or README, but it is the polite thing to do. Something along the order of "Portions of this program Copyright by J. Random Hacker" is fine.
it would surely become unwieldy after the code had been handed around through 50 authors.
Look at the Linux source code
I recommend (as a layman) all contributors assign their copyrights to the project copyright holder if they are specifically contributing to the project. (of course, if you are borrowing code from elsewhere you won't be able to do it) When it comes time to change the licensing (from GPLv2 to GPLv3), you won't have to get a hundred hackers to agree. Even tiny NASM with only two copyright holders can't agree on the licensing.
Shouldn't it actually be copyrighted and released under the GPL, et al?
It already is. All original works are copyrighted by default. If you want to get formal about it just include the single line "Copyright 2000 by me".
The more common names for these two types of licenses are "unrestricted" and "copyleft". In a nutshell they are defined as "no restrictions on this source code" and "this must always remain free in all incarnations." Unfortunately, these are mutually exclusive, and will always be at odds with each other.
You illustrate one big problem with slashdot: you think differences of opinions are trolls. The previous post was not a troll. If it were it would have simply said "the GPL is not free". But that is not what it said. It said in essence "the GPL is not free and here is why...". Big difference.
When all else fails, use your common sense.
1) Use the license YOU want to use on your own projects. If you don't like copyleft licenses then don't use them. If you don't like unrestricted licenses then don't use them. Easy, isn't it? But by all means, don't go creating your own new license. There are enough good ones out there that it isn't necessary. There are still some licensing niches to fill in the OSS hierarchy, but I doubt your project fits that bill. The BSD, MIT, GPL, LGPL, MPL, QPL and Artistic licenses are sufficient to meet your needs.
2) Don't get religious over licensing. The well known licenses all have their place. As soon as you say "I will never use the BSD/GPL/QPL/whatever license" you will immediately run across a situation where you will need it. I am personally not fond of copyleft, but if I were to release a commercial open source product that faced competition, you can bet you bippy that I would seriously consider using the GPL. Likewise, don't let license bigotry get in the way of your helping out on other people's projects.
3) Assign your copyrights over to the author. Don't insist on holding on to the copyright for your bug fixes and minor contributions. That's so egotistical as to be stupid. You will get mentioned in the credits, so don't worry about it. You will make the author's life so much easier. If your are the original author or project maintainer, then insist that all copyrights be assigned to the you or the project. If you want your project to be "community based", then seriously consider assigning your copyright to the FSF, creating your own non-profit org, or placing it in the public domain. Do you really want the submitter of a five line bug fix to be in control of all licensing decisions from here on out?
If a solution could be found which did away with software ownership and still preserved the freeness of free software, I'm sure the FSF would jump all over it.
The only way to guarantee certain attributes of Free Software is to own the software. If you wish that all distributions of your authored software retain access to the source code, you have to have sufficient ownership rights in it order to assert that control. You cannot control something if you do not own it (unless you employ coercion).
There's nothing wrong or hypocritical with opposing software ownership, and then using it as a means to the end of free software.
If the FSF viewed software ownership like "fire", then fought fire with fire, that's okay. But reading throught the FSF pages, I get the distinct impression that they believe software ownership to be evil and immoral. If so, then owning software with a GPL label on it is still evil and immoral. It would be like fighting murder with murder. As my Mother always told me, two wrongs do not make a right.
As an aside, if the FSF ever got its wish and copyright law suddenly disappeared, nothing much would change. The vast majority of proprietary licenses are not predicated on copyright law, but on contract law. Lack of copyright law would not affect the Microsoft EULA in any way. What would happen is that those people who wished to protect their software ownership rights (whether the be Free or proprietary) would find other ways to do so besides relying on government recognition. Take a look at this Free Nation article for an anarcho-capitalist look at copyright law. The Free Nation site also has other articles on intellectual property from a libertarian perspective, including the one mentioned at GNU.
And that, in a nutshell, is the irony. You shouldn't own software. It's derivitives shouldn't be owned either. They only way to prevent owned derivitives is to own the original.
I think the FSF just started off on the wrong premises. None of their conclusions would have been affected if they had admitted it's okay to own software. In some ways their arguments could even have been strengthened by admitting that it's okay. After all, how can you share what you don't own?
A common misconception. Only the author of a work is allowed to change the copyright or licensing.
What you CAN do with a BSD program is to wrap it with a GPL license. But any recipient has full legal authority to remove the "wrapper" from all BSD parts. Because of this, wrapping a bare BSD application with the GPL is pointless. It does serve a purpose, however, when you wish to combine a BSD module with a GPLd module.
In reference to a Qt/Embedded version of Kicker, the licenses are in conflict. The BSD license gives the users many permissions that the GPL does not. You can indeed by sued by Trolltech for exercising the rights given you by the Kicker authors.
The BSD license is considered compatible with the GPL because you can include BSD code within GPL code, and distribute the whole under the GPL. But the reverse is not allowed. You cannot include GPL code within BSD code and distribute the whole under the BSD license. You would have to remove the GPL code first. And since Qt/Embedded is GPL, you could not distribute Kicker under the the author's own license without first "removing" Qt/Embedded.
But this is not how copyright law defines distribution, and the GPLv2 clearly states it is operating under copyright law.
...programs covered more free, because it means that improvements will make it back to the community...
If my friend uses my modified GIMP over the network, he is not receiving GIMP. No portion of the binary is being transmitted to him. What is the legal difference between his using my GIMP locally on my machine or using it remotely on my machine?
I don't see any substantial difference between downloading a binary and running it locally, and running that binary remotely on someone's web server
In the former, I have actually distributed GIMP to you. You now possess a copy of it. In the latter you do not possess a copy of it, since the software has not been transmitted to you.
This is not the freedom of Free Software, but closer to the openness of Open Source. Contributing back to the community is merely a side effect of Free Software, not its goal. Users only have the right to source code for those programs they possess of copy of.
I do not restrict your freedom by putting a lock on my own door. I can only do that by putting a lock on *your* door.
There is a way for the GPL to restrict this modified GIMP of mine and still be operating under copyright law. And that is to start regulating Public Performance. This would be a very radical thing to do, and the implications of opening this pandora's box should be thought out long and hard.
Okay, that's interesting, and one I haven't heard before.
You say "after linking must be under the GPL". Does this mean only temporarily while the user is running the program, or that that the author must distribute it under the GPL after linking it at build time? In other words, would Debian (as an example) offer the application under the BSD license, or would they have to offer it under the GPL? In the case of the latter, the GPL is still effectively telling me what license to use.
If any of these are illegal, then isn't this extremely unfriendly to every known license other than the GPL, including the BSD licenses and public domain licenses?
You could cut the irony with a knife. On one hand, the FSF does not want people to own software. On the other hand, they explicitly discourage the use of public domain. That they could sue you for refusing to own your work that linked to libreadline seems par for the course. It's okay if you give your stuff to the FSF, but give it to the public and you'd better get a lawyer.
Using 'printf' won't make your application a derivative of anything. You can't copyright an API, especially not the C API. You can only copyright the implementation. RMS could have kept glibc under the straight GPL and he couldn't have stopped anyone from using 'printf' on GNU or Linux systems.
The analogy does not work for static libraries. But it does work for dynamic libraries, and is almost perfect for runtime libraries.
If a take a particular binary and translate its machine code into English, I would find something very similar to "this program references routines in libreadline.so", and "jump to this relocatable address." In neither case is code from the library actually included in the application. All that are there are references. Of course, header files could be written so that using them places library code directly into the application (macros or inlines), but the basic concept of dynamic linkage is still referencing.
Most literary works do not strictly require the reader to look up and read all of the references in the bibliography or footnotes, while most software applications do. But I don't think the manner in which a work is used has any bearing upon its derivation.
The "direction" comes from derivation and ancestry. The word is not in the GPL, but "direction" is an easy metaphor to understand. All code that is distributed as part of a GPL package must not add any additional restrictions, but the package must always be distributed under the terms of the GPL. So I could include a BSD licensed module in a GPL package since the BSD license is compatible with the GPL. But I could not use a GPLd module in a BSD package, because the BSD license would be changing the distribution terms of the module.
As for the wrapper stuff, that was the argument that RMS used. I do not have his exact quote readily available, so I apologize if I erred in its paraphrase. It was in response to a question as to why Free but non-GPL applications should not be able to link with GPL libraries.
No, there is a "direction" to compatibility. You can link a GPL application to a BSD library, but you cannot do the reverse. The argument that RMS makes is that someone could write a BSD wrapper for a GPL library, then link a proprietary application to the BSD library, thus circumventing the GPL.
No, it is a good example. Copyrighted works should be treated the same as any other copyrighted works. That current law treats software differently than literary works only illustrates the technical ignorance of some legislaters and judges.
Fair Use is kept deliberately vague and loosely defined in law, since listing some specific Fair Use rights would imply that any unlisted rights were forbidden. To my mind, and in every direction that I look at it from, dynamically linking to a library is Fair Use. That's the whole point of creating a libary to begin with. If the GPL doesn't want non-GPL applications dynamically linking to GPL code, then it should stop pretending that it is operating under copyright law, and come right out and admit it's really a EULA. Copyright law gives me the right to freely reference a work, and so should the GPL.
But if loosening the current GPL protections is against the spirit of the current license, then wouldn't tightening the protections be the same?
I see the spirit of the GPL as being a set of permissions (with conditions) granted to the user over and beyond what copyright allows. But some of these GPLv3 proposals I have seen would have to add a restriction on top of what copyright imposes, particularly with regards to the ASP "loophole". In or other words, the GPLv2 is a copyright based license, but the GPLv3 could end up being a contract based license.
Fortunately the QPL is still applicable, too.
But the embedded version is not dual licensed under the QPL. This is a serious mistake on Trolltech's part. Konqueror was just ported to work with Qt/Embedded, and it's cool! But it is ILLEGAL to port Kicker or KWin over. Kicker and KWin are under the BSD license. They cannot link to a GPL library. I have written a Qt application that would be perfect on a palmtop, but it cannot use Qt/Embedded since it is under the BSD license.
I am so glad that RMS is still in the comments gathering stage. Some of the proposals I've seen for GPL are very unfree (in both the FSF and the dictionary sense). These proposals seem to be more about protecting the author's sensibilities rather than eliminating the traditional restrictions normally tied to software.
1) Further restrictions upon linkage. Dynamic and runtime linkage is *using* the software in the manner it was meant to be used. And the freedom to use the software in any way is the FIRST freedom listed by the FSF. It's sensible at times to restrict what libaries an application can link to, because that could co-opt the application and make it unfree. But the reverse is impossible. There is no way to make a libary unfree by using it for an unfree application. No derivative work is being made under copyright law. Nothing is being modified or distributed with additional restrictions. The only thing being hurt is the author's sensibilities.
In RMS' zeal to prevent proprietary authors from using his libraries, he ends up hurting Free Software authors who use non-GPL licenses. The GPLv3 should be looking at ways to include non-GPL but Free Software authors in the community, instead of seeking further ways to exclude them. As it now stands, software in the public domain or under a BSD, MIT or other "copycenter" license cannot use GPLd libraries, such as readline or Qt/Embedded. Some proposals for the GPLv3 would further alienate these freedom loving folk.
Looking at the various dynamic (not static) libraries in existance, the only ones that I know of that dictate the terms of the application's licensing are are small subset of "Free" Software libraries. (there may be some proprietary licenses that do this, I am just not aware of any) Microsoft doesn't care how I license my MFC application. RogueWave doesn't care how I license my Tools++ application. Only the FSF demands I use a specific license for my own original and non-derivative works.
2) New restrictions upon use. That RMS is even contemplating this scares me. By *use* I mean the ASP "loophole". Again, this is another case where the only harm is harm to the author's sensibilities. RMS and the GPLv2 allows me to modify GIMP (as an example) for my own private use. They do not restrict my friends from coming over to my residence and using the modified GIMP on my computer. But the GPLv3 will regulate how my friends can use my modified copy of GIMP if they do so over the internet instead of physically walking to my residence. Where is the logic in this?
There are parts in the GPL v 2 that need cleaning up and clarifying. Please do so. But don't add new unprecedented restrictions. If the only thing being hurt is your sensibilities then leave it out.
Corel had the right idea. They did it the wrong way.
Linux and BSD are at a crossroads. The operating systems are complete. They are stable. Now its time to do something with them. Distributions now need to differentiate themselves by their target audience. One of these audiences is the average non-hacker desktop user. Corel was correct to target this market. Some other distros are making a mistake by trying to make a one-size-fits-all distribution.
But they did it the wrong way. The set it up so that they were always "following" Debian. They forked KDE, making the users ask "keep the Corel file manager or upgrade to KDE 1.1.2?" They bombed on marketing. It wouldn't install on a lot of systems.
But their target market still needs their own distribution. They don't want to wade through six or seven CDs trying to figure out what packages they need and what they don't. They want an easy to use installer, not a GUI wrapper. They want it small enough to be able to learn it. They want a browsable package installer/updater. They want compatibility with other distributions.
All of the parts are there, but only Corel ever got around to putting it all together. Some distros need to become the "server" distros, others the "hacker" distros, and some could be the "kitchen sink" distros. But at least one needs to be the "man on the street" distro.
Yea, but algore invented English to begin with.
You gave the answer right there: Module-2 is a great teaching language. That is a good enough reason to teach it for beginning CS students. But at the same time it shouldn't be used for upper division course work.
When I went to university, the first CS class was Pascal. That was a primo decision on their part. I learned how to program instead of how to fiddle with syntax. Today, Pascal would still be a good choice for CS101, but I would also add Java and Python. After that, the next class was assember (PDP-8).
Then, to our horror of horrors, we were thrust into "real" programming. "This is Unix, this is C, you know nothing of them, but the first assignment is due this friday". It was rough those first five days, but since we were firmly grounded in programming as opposed to syntax, we made the transition with flying colors.
The word "hacker" predated computers by decades. It meant someone who who did "quick and dirty" work with no regard to quality. In the building trades, a contracter who works quick and dirty is called a "hack". A general contracter who is behind budget will tell his foreman to "go get a hacker". Or consider the hack writer. He wants to write the next great novel, but he has to feed his family so he hacks out romances.
Does this meaning fit today's computer hackers and "crackers"? Scary, ain't it?
Yeah, I've heard about that one, from someone who's been there and seen it.
From what I understand, California can't use the same system, or use it as efficiently due to the geography.
Where's the evidence that it's due to deregulation? In fact, where's the evidence that the industry was even deregulated to begin with? The fact was that it was not deregulated. It was only opened up for potential competition. The PUC is still firmly in place. The monopoly rights of the utilities was taken away, the regulation was not.
There are many problems with the current power "shortage". But I don't see any of these problems arising from too many power providers. Quite the opposite. There are too few providers and even fewer producers. The California population keeps on growing while the power produced keeps on shrinking. It's next to impossible to get government (read 'regulated') approval to create a new power plant. In the meantime the older plants are starting to fall apart. The industry wants to build a huge plant in San Jose but politics is stopping it. They also want to create dozens of mini plants but they can't do that either. We really need nuclear plants to avoid the pollution of gas/coal plants, but even suggesting it is political suicide here.
The potential competitors of PG&E and Edison would have to be nuts to enter the California market. Which is why the only alternatives you see are resellers of out-of-state surplus (as if they would have any in the middle of winter) and tiny environmental producers like wind or solar. Power production needs a huge economy of scale backed by an army of lawyers. What we really need is inexpensive point production, like microplants or personal fuel cells.