The lack of explicit answers to questions about remote linking and the like are causing increasing problems with the GPL. Currently, you can not statically link to a GPLed library, nor can you dynamically link. However I believe you can dlopen a GPLed library as well as including the functionality in another program which you communicate to via RPC, provided that your program is functionally still useful without the helper program. Further, you may not link against a GPLed appliation but you may communicate with it via RPC, TCP, etc. Finally, you only need to give a copy of the source to a person who you give a copy of the binary to. This of course means that you can put a GPLed application on your webserver and you never have to give the source to anybody if you so choose, even if you make the output freely available, or if use of your application only makes sense by remote execution. So what does 'distribute' mean in this interconnected world? If I can ssh into a box and run a binary, has it been distributed to me? What if I can run it via a web server? Or a caching proxy? And I understand you don't have to release source provided you only use the application internally, but the definition of internally has a few surprises for most lay people.
Now, did anybody follow all that? And I'm not even sure I got it all right. The next version will be long overdue.
Re:Draft Copy?
by
mark-t
·
· Score: 3, Informative
I realize that I'm just being a pedantic pain in the arse by pointing this out here, but the GPL really only covers the issue of _copying_, not mere use.
Re:Changes to the GPL
by
mrchaotica
·
· Score: 3, Informative
mailing $15 for the source code when the binary is available free online goes against its principles
According to the GPL FAQ, that's already disallowed:
Does the GPL allow me to charge a fee for downloading the program from my site?
Yes. You can charge any fee you wish for distributing a copy of the program. If you distribute binaries by download, you must provide "equivalent access" to download the source--therefore, the fee to download source may not be greater than the fee to download the binary.
--
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Re:Changes to the GPL
by
DunbarTheInept
·
· Score: 3, Informative
The problem is over just what does and doesn't constitute "derivative code". If I publish a product in which my code has a shell script that calls out to gzip, just how derivative is my work? The fear companies have is over this feature. The LGPL is a bit clearer, but the GPL isn't too clear one way or the other. Some ways to read it might give the impression that as long as you ship a GPL tool alongside your own tool, and make any sort of call from your tool to the GPL tool (i.e. a shell script calling gzip), that your own tool is now GPL too.
--
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Re:GPL vs MS EULA's
by
0racle
·
· Score: 4, Informative
I have this bad habbit of bringing facts to the irrational discussions on Slashdot. they [b]must[/b] be publicly visible
-- "I use a Mac because I'm just better than you are."
Re:Patents and compatiability?
by
eison
·
· Score: 5, Informative
Afraid that is the *point* of the GPL.
The GPL is pushing a political agenda: "preserve, protect and promote the freedom to use, study, copy, modify, and redistribute computer software." (from front page of gnu.org)
That restriction is the #1 thing that does support that agenda - if people find GPLed code useful enough that they want to use it, they will need to let others do likewise when they distribute their code.
I find it's not always what I want to do with my code (my agenda is often more in line with BSD), but it strikes me as genius in this means to achieve its end.
-- is competition good, or is duplication of effort bad?
Not as simple as previously stated.
by
jbn-o
·
· Score: 4, Informative
The GPL works very well at the moment. Introducing a new version could confuse what is at the moment a very easy to understand concept-- if you alter GPLed code you have to let everyone use your alterations as GPLed code as well-- as well as creating schisms in OSS development.
Actually, private derivatives are allowed. Having the freedom to make derivatives one does not share with others in any form is required by the definition of free software:
You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist.
Also, use of a program (that is, merely executing the program) is not a power regulated by US copyright law. And the GPLv2 specifically states that it does not control this activity:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted [...]
So, no, "if you alter GPLed code you have to let everyone use your alterations as GPLed code as well" is untrue.
Also, you have (perhaps inadvertantly) repeated one of the most misleading parts of the article (and the editorial linked to the article): Associating the GPL with the open source movement profound miscredits who did what and what goals the GPL was written to achieve.
This latest revision of the GPL has almost nothing to do with "OSS" development. The open source movement (which doesn't like to talk about software freedom) did not exist when the current version of the GPL (version 2) was written. The free software movement (which is based on software freedom) predates the open source movement by over a decade. This upcoming version (version 3) of the GPL will be the first version of the GPL written since the open source movement started. As far as I know, nobody from the open source movement is writing the next revision of the GPL; it is still written by the people at the FSF (most notably, RMS and Eben Moglen, both of whom make it quite clear in their speeches that they are doing work to promote software freedom). So, the open source movement is receiving a great deal of credit for work it did not do and the danger of tying the GPL with the open source movement is that the open source movement's philosophy, which doesn't object to proprietary software, will be conflated with a license built to create and maintain a commons where software freedom is the rule.
Slashdot Mirror
Not to be mean, but RTFA:
The changes planned for the next release, Version 3, a draft of which is due next year,...
-dave
http://millionnumbers.com/ - own the number of your dreams
The lack of explicit answers to questions about remote linking and the like are causing increasing problems with the GPL. Currently, you can not statically link to a GPLed library, nor can you dynamically link. However I believe you can dlopen a GPLed library as well as including the functionality in another program which you communicate to via RPC, provided that your program is functionally still useful without the helper program. Further, you may not link against a GPLed appliation but you may communicate with it via RPC, TCP, etc. Finally, you only need to give a copy of the source to a person who you give a copy of the binary to. This of course means that you can put a GPLed application on your webserver and you never have to give the source to anybody if you so choose, even if you make the output freely available, or if use of your application only makes sense by remote execution. So what does 'distribute' mean in this interconnected world? If I can ssh into a box and run a binary, has it been distributed to me? What if I can run it via a web server? Or a caching proxy? And I understand you don't have to release source provided you only use the application internally, but the definition of internally has a few surprises for most lay people.
Now, did anybody follow all that? And I'm not even sure I got it all right. The next version will be long overdue.
I realize that I'm just being a pedantic pain in the arse by pointing this out here, but the GPL really only covers the issue of _copying_, not mere use.
File under 'M' for 'Manic ranting'
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
According to this slide the Affero GPL is a prototype.
get 7 free Japanese lessons.
The problem is over just what does and doesn't constitute "derivative code". If I publish a product in which my code has a shell script that calls out to gzip, just how derivative is my work? The fear companies have is over this feature. The LGPL is a bit clearer, but the GPL isn't too clear one way or the other. Some ways to read it might give the impression that as long as you ship a GPL tool alongside your own tool, and make any sort of call from your tool to the GPL tool (i.e. a shell script calling gzip), that your own tool is now GPL too.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I have this bad habbit of bringing facts to the irrational discussions on Slashdot.
they [b]must[/b] be publicly visible
Have you ever looked? Here let me help
Windows XP Home here
Windows 98 Downloads here
A whole bunch more
"I use a Mac because I'm just better than you are."
Afraid that is the *point* of the GPL.
The GPL is pushing a political agenda: "preserve, protect and promote the freedom to use, study, copy, modify, and redistribute computer software." (from front page of gnu.org)
That restriction is the #1 thing that does support that agenda - if people find GPLed code useful enough that they want to use it, they will need to let others do likewise when they distribute their code.
I find it's not always what I want to do with my code (my agenda is often more in line with BSD), but it strikes me as genius in this means to achieve its end.
is competition good, or is duplication of effort bad?
Actually, private derivatives are allowed. Having the freedom to make derivatives one does not share with others in any form is required by the definition of free software:
Also, use of a program (that is, merely executing the program) is not a power regulated by US copyright law. And the GPLv2 specifically states that it does not control this activity:
So, no, "if you alter GPLed code you have to let everyone use your alterations as GPLed code as well" is untrue.
Also, you have (perhaps inadvertantly) repeated one of the most misleading parts of the article (and the editorial linked to the article): Associating the GPL with the open source movement profound miscredits who did what and what goals the GPL was written to achieve.
This latest revision of the GPL has almost nothing to do with "OSS" development. The open source movement (which doesn't like to talk about software freedom) did not exist when the current version of the GPL (version 2) was written. The free software movement (which is based on software freedom) predates the open source movement by over a decade. This upcoming version (version 3) of the GPL will be the first version of the GPL written since the open source movement started. As far as I know, nobody from the open source movement is writing the next revision of the GPL; it is still written by the people at the FSF (most notably, RMS and Eben Moglen, both of whom make it quite clear in their speeches that they are doing work to promote software freedom). So, the open source movement is receiving a great deal of credit for work it did not do and the danger of tying the GPL with the open source movement is that the open source movement's philosophy, which doesn't object to proprietary software, will be conflated with a license built to create and maintain a commons where software freedom is the rule.
Digital Citizen