The GPL absolutely does not "grant unrestricted permission to use", and if it did, I think decryption access is a different animal anyway. The exact language of the GPL is:
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,...
The last sentence says that the licence agreement adds no restrictions to use. Thus the restrictions found in copyright law are not increased, but they certainly are not waived either.
If this was in doubt, the first sentence clearly states that nothing in the licence grants decryption access, since this is something legally distinct from "copying, distribution and modification".
As for who has to approve licencing decryption access, anyone who owns any copyrights on encrypted material has a legal claim if their individual copyright is violated. Copyright law is very clear that the rights of the author of a derivitive work do not extend to the derivitive parts. If I wrote part of the code, then if you remove a TPM that allows you access to my contribution, then you had better have permission from me and if all you have is the GPL, you don't have it.
OK, so it's a protocol, like say ftp or http, but different. So it seems, as per the bugzilla discussion, that the problem should be solved by creating a mozilla plugin to handle URL's written torrent://domain.name/localpath/file.torrent.
I would expect that mozilla can have a plugin that asks to handle a given protocol when it is encountered. Anybody know if my expecation is reality?
Finally, how exactly do they know what the total bandwidth of distributing RH9 via BitTorrent was?
Can somebody explain what makes BitTorrent unique from other P2P systems? I'm not familiar with it. I don't quite understand why this request would be any different than asking Mozilla to include gnutella.
What seems rather important here is that P2P appears to be the only solution to at least one other problem besides the "How do we get free music". If So, building a solution to the browser problem into Mozilla seems like a good thing, although I'd prefer SVG support first. On the flipside, what exactly prevents Joe Anybody from creating BitTorrent as a browser plugin?
Yes, the reaction clearly affect them. This is a way for them to backpedal without losing face. Firebird should accept this as a reasonable response and make some positive "feel good" statements about Mozilla so we can all just move on.
I would doubt that it would go up to the court for the same reason that Napster didn't -- the Circuits aren't split, the issues are statutory, not Constitutional, and the legislature is completely able to change the law.
BitKeeper doesn't bother me because I can always choose not to use it. If you are a kernel hacker and BitKeeper bothers you, then you should stop contributing to Linux and create a GPL source code management tool that has the features that people want.
DRM bothers me because it is an attempt to outlaw the general purpose computer based on the belief that it is too dangerous to empower ordinary people with it's full capabilities.
Linux is wrong
on
Linus on DRM
·
· Score: 2, Informative
I disagree with Linus. Although my belief doesn't really matter because I am not a kernel hacker, I do expect that many Linux contributors may disagree as well. Unless all the contributors agree with his position, the potential is there for one of them to make the legal claim that distributing a DRM-signed GPL'd work for use in a DRM machine without providing the private key as part of the source code is a violation of their copyrights (traditional and/or DMCA). In this case, unless Linus is willing to play politics and fight his way through a lawsuit to prove his position, then regardless of his beliefs or the legal correctness of those beliefs, there will be no DRM-signed Linux. I also predict that he would lose, if he chose to fight in court.
An "external" DRM-signature that allows verification of the origin of a particular piece of code is perfectly fine UNTIL that signature's presence is enforced by the hardware as a condition for exectuion. At that point, the signature becomes functionally part of the instructions to the machine that enable the whole to be executed, and I believe that because the DRM machine is requiring the presense of both in order to execute that they are a combined work in the context of use on that machine.
This signature, when enforced by hardware, also becomes part of an overall technological protection measure within the meaning of the DMCA. The DMCA requires the "authority of the copyright holder" to get access to a work protected by a technological protection measure (TPM). Nothing in the GPL authorizes the removal of a TPM, so if Linus unilaterally places a TPM on his copy of Linux (which the DRM-signature is) then he needs the authority of all the copyright holders to access the protected copy, which would include running it on a machine that enforces DRM. No text in the DMCA supports the position that if unprotected copies exist means that access to a TPM protected version is allowed.
Putting TPMs on other people's work without their approval results in a TPM protected work that no one can use. The GPL does NOT provide DMCA access rights either (it provides copying and modification rights but not TPM-access rights).
A 4th book on Ruby that I kind of like is _Ruby Developer's Guide_ by Robert Feldt, Lyle Johnson, Michael Neumann (Editor), Lyle Johnson, Jonothon Ortiz.
This has a series of chapters on more applied topics that would be good for the Slashdot programmer audience: DBI, XML, SOAP, Performace, Parsers, etc... The book is a little wordy, but the topics covered are very useful and it imparts a lot of useful information for people who don't want to relearn basic syntax.
Many people who might like ruby better are happy enough with perl and python. Perl has a much larger class library because it's the established player. Many people who were dissatisfied with perl's loosy-goosy style and OO approach probably already left and went to python.
At some point many potential switchers say "OK, maybe ruby is slightly better at this and has this other advantage, but I can live without that slight advantage because I get a bigger community and class library to draw from by staying with [perl|python]"
Personally, I don't find that argument persuasive because I think it's good to know more langagues and I give my first look to ruby and fall back to python or perl only if I need class libraries that I don't want to write myself.
Ruby is a competitor to both Python and Perl. In some sense, it is an attempt to combine the best features of each. My belief is that it succeeds well at this goal. It offers an even purer OO approach than python, while offering much of perl's strong syntactic sugar.
It is extremely uncool of the Phoenix project to have create this mess. They need to back off and reverse their horrendous decision to rename their project to "Firebird". That name is taken. Period. "Our lawyers said it is OK" is just not accepatable.
Frankly, if Phoenix-Firebird does not reverse course, this is going to get very ugly. I would suspect that the fallout will severely damage both projects. The open source community needs to not allow this to happen. Phoenix-Firebird created this mess and ONLY they can get out of it. The open source community needs to pressure them to not continue down the road to conflict and discord.
Well, mysqlimport or LOAD DATA INFILE seems like it would be a MUCH better MySQL solution than building an INSERT for each row. Why the author of the original article did not use this method is rather perplexing.
However, I don't see how the CREATE TABLE AS SELECT or INSERT AS SELECT could possibly work here unless MySQL has a way to link a table from an external source.
What's to understand? One year programming approaches that obey property P are "hot" and the next year it's property Q. Q might refine P or it might be exclusive from P altogether or it might overlap but not imply property P.
It's all a question of which buzzwords people are concentrating on and more importantly thinking in terms of.
If Aspect oriented programming adopts a programming model that does not include inheritance, then the implied value judgement is that on the whole, inheritance causes more problems than it solves and is best not offered as an option.
Whether you agree with that or not is up to you, but "surely" you can't speak for everybody. (and please stop calling me Shirley).
Mozilla's Firebird browser isn't going to be confused with a relational database. Trademark onflicts only arise when there is customer confusion.
I doubt that the people at the Firebird project will see it that way. What is Phoenix/Firebird going to do when they trademark their name (if they haven't done so yet).
It is VERY UNCOOL of Phoenix to pick "Firebird" as a name, because it is taken in the open source world. If I was working on the Firebird RDBMS, I'd be pissed.
Here's another example from real world use that shows that MySQL is a toy compared to a real database like Oracle. You shouldn't have to write that much code to freaking load data. For industrial strength uses the method given will be horribly slow because it doesn't use bind variables. This results in each INSERT statement being different and having to be parsed separately by the RDBMS. SLOW!
Frankly, even the overhead of having to construct the INSERT sql string is waste. You also don't want to maintain the indexes in the target table for each row update. MySQL doesn't have transactions, so you don't have to worry about commit-frequency, but if your load stops in the middle somewhere, I'm not sure what you do.
Oracle provides a loader utility called sql*loader that eliminates the overhead of the per-row maintenance. It has a mode called "Direct Load" which can bypass trigger processing and directly write binary datablock output. This is the fastest way to load data. Of course bypassing triggers is of no interest to MySQL users because MySQL doesn't have triggers, but if it did you'd have another thing to worry about with loading data into MySQL.
As an alternate to sql*loader, you could use external tables or Oracle Generic Connectivity to create an oracle table whose data was supplied by a flat file or ODBC connection. Then you would type
INSERT INTO target_table
VALUES ( [[field_list]] )
(SELECT [[field_list]] from external_table)
or (faster)
CREATE TABLE target_table AS (SELECT * from external_table)
Both of which would blow away the proposed method speed-wise.
Instead of removing them, there should be a better filtering ability based on project activity. A project which hasn't moved in 6 months could be labelled "dormant" and if it hasn't moved in 1 year it should be labelled "abandoned".
Good question. I have three good answers to why XML makes it easy to "have a common design".
1) It's much easier to switch your app from one XML format to another because you don't have to rewrite the whole world of 3rd party XML tools. Parsers, validators, syntax checkers, marshalling, etc...
2) XSLT is much easier than other kinds of file converters (especially if I have to write them to deal with your junky non-XML file format), so maybe we don't have to adopt a common schema but rather we just write two transforms. Oh, and we can use it to convert to HTML and SVG and the open office formats and... Can your data format do that?
3) The XML format is just flat out better. A bunch of really bright people got together and designed a format that had a lot of nice properties. For example, what you call bloat is better called "readability" and compressed XML, contrary to your assertion, is a very compact data format.
XML schema has far greater capabilities in this regard than DTD's.
I certainly agree that 3rd normal form schemas have advantages above even this. The only problem is that RDBMS schemas are tightly coupled to the individual database application that uses them and can't really exist without, well, an RDBMS. Both properties hamper system integration issues.
You might examine Oracle 9iR2's XML database capabilities, by the way.
Slashdot Mirror
The GPL absolutely does not "grant unrestricted permission to use", and if it did, I think decryption access is a different animal anyway. The exact language of the GPL is:
...
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,
The last sentence says that the licence agreement adds no restrictions to use. Thus the restrictions found in copyright law are not increased, but they certainly are not waived either.
If this was in doubt, the first sentence clearly states that nothing in the licence grants decryption access, since this is something legally distinct from "copying, distribution and modification".
As for who has to approve licencing decryption access, anyone who owns any copyrights on encrypted material has a legal claim if their individual copyright is violated. Copyright law is very clear that the rights of the author of a derivitive work do not extend to the derivitive parts. If I wrote part of the code, then if you remove a TPM that allows you access to my contribution, then you had better have permission from me and if all you have is the GPL, you don't have it.
Why wouldn't BitTorrent be useful for 100KB images on a slashdotted website?
OK, so it's a protocol, like say ftp or http, but different. So it seems, as per the bugzilla discussion, that the problem should be solved by creating a mozilla plugin to handle URL's written torrent://domain.name/localpath/file.torrent .
I would expect that mozilla can have a plugin that asks to handle a given protocol when it is encountered. Anybody know if my expecation is reality?
Finally, how exactly do they know what the total bandwidth of distributing RH9 via BitTorrent was?
Can somebody explain what makes BitTorrent unique from other P2P systems? I'm not familiar with it. I don't quite understand why this request would be any different than asking Mozilla to include gnutella.
What seems rather important here is that P2P appears to be the only solution to at least one other problem besides the "How do we get free music". If So, building a solution to the browser problem into Mozilla seems like a good thing, although I'd prefer SVG support first. On the flipside, what exactly prevents Joe Anybody from creating BitTorrent as a browser plugin?
You know your a scumbag when...
Slashdotters support AOL and MS when they attempt to stomp on you.
Yes, the reaction clearly affect them. This is a way for them to backpedal without losing face. Firebird should accept this as a reasonable response and make some positive "feel good" statements about Mozilla so we can all just move on.
I would doubt that it would go up to the court for the same reason that Napster didn't -- the Circuits aren't split, the issues are statutory, not Constitutional, and the legislature is completely able to change the law.
BitKeeper doesn't bother me because I can always choose not to use it. If you are a kernel hacker and BitKeeper bothers you, then you should stop contributing to Linux and create a GPL source code management tool that has the features that people want.
DRM bothers me because it is an attempt to outlaw the general purpose computer based on the belief that it is too dangerous to empower ordinary people with it's full capabilities.
I disagree with Linus. Although my belief doesn't really matter because I am not a kernel hacker, I do expect that many Linux contributors may disagree as well. Unless all the contributors agree with his position, the potential is there for one of them to make the legal claim that distributing a DRM-signed GPL'd work for use in a DRM machine without providing the private key as part of the source code is a violation of their copyrights (traditional and/or DMCA). In this case, unless Linus is willing to play politics and fight his way through a lawsuit to prove his position, then regardless of his beliefs or the legal correctness of those beliefs, there will be no DRM-signed Linux. I also predict that he would lose, if he chose to fight in court.
An "external" DRM-signature that allows verification of the origin of a particular piece of code is perfectly fine UNTIL that signature's presence is enforced by the hardware as a condition for exectuion. At that point, the signature becomes functionally part of the instructions to the machine that enable the whole to be executed, and I believe that because the DRM machine is requiring the presense of both in order to execute that they are a combined work in the context of use on that machine.
This signature, when enforced by hardware, also becomes part of an overall technological protection measure within the meaning of the DMCA. The DMCA requires the "authority of the copyright holder" to get access to a work protected by a technological protection measure (TPM). Nothing in the GPL authorizes the removal of a TPM, so if Linus unilaterally places a TPM on his copy of Linux (which the DRM-signature is) then he needs the authority of all the copyright holders to access the protected copy, which would include running it on a machine that enforces DRM. No text in the DMCA supports the position that if unprotected copies exist means that access to a TPM protected version is allowed.
Putting TPMs on other people's work without their approval results in a TPM protected work that no one can use. The GPL does NOT provide DMCA access rights either (it provides copying and modification rights but not TPM-access rights).
What is FirebirdSQL !?!?
Is there another open source database besides Firebird?
A 4th book on Ruby that I kind of like is _Ruby Developer's Guide_ by Robert Feldt, Lyle Johnson, Michael Neumann (Editor), Lyle Johnson, Jonothon Ortiz.
This has a series of chapters on more applied topics that would be good for the Slashdot programmer audience: DBI, XML, SOAP, Performace, Parsers, etc... The book is a little wordy, but the topics covered are very useful and it imparts a lot of useful information for people who don't want to relearn basic syntax.
Many people who might like ruby better are happy enough with perl and python. Perl has a much larger class library because it's the established player. Many people who were dissatisfied with perl's loosy-goosy style and OO approach probably already left and went to python.
At some point many potential switchers say "OK, maybe ruby is slightly better at this and has this other advantage, but I can live without that slight advantage because I get a bigger community and class library to draw from by staying with [perl|python]"
Personally, I don't find that argument persuasive because I think it's good to know more langagues and I give my first look to ruby and fall back to python or perl only if I need class libraries that I don't want to write myself.
Ruby is a competitor to both Python and Perl. In some sense, it is an attempt to combine the best features of each. My belief is that it succeeds well at this goal. It offers an even purer OO approach than python, while offering much of perl's strong syntactic sugar.
If Phonix continues on this path, I hope that someone will fork their project, just to change the name.
I for one, would use the forked version.
It is extremely uncool of the Phoenix project to have create this mess. They need to back off and reverse their horrendous decision to rename their project to "Firebird". That name is taken. Period. "Our lawyers said it is OK" is just not accepatable.
Frankly, if Phoenix-Firebird does not reverse course, this is going to get very ugly. I would suspect that the fallout will severely damage both projects. The open source community needs to not allow this to happen. Phoenix-Firebird created this mess and ONLY they can get out of it. The open source community needs to pressure them to not continue down the road to conflict and discord.
Well, mysqlimport or LOAD DATA INFILE seems like it would be a MUCH better MySQL solution than building an INSERT for each row. Why the author of the original article did not use this method is rather perplexing.
However, I don't see how the CREATE TABLE AS SELECT or INSERT AS SELECT could possibly work here unless MySQL has a way to link a table from an external source.
What's to understand? One year programming approaches that obey property P are "hot" and the next year it's property Q. Q might refine P or it might be exclusive from P altogether or it might overlap but not imply property P.
It's all a question of which buzzwords people are concentrating on and more importantly thinking in terms of.
If Aspect oriented programming adopts a programming model that does not include inheritance, then the implied value judgement is that on the whole, inheritance causes more problems than it solves and is best not offered as an option.
Whether you agree with that or not is up to you, but "surely" you can't speak for everybody. (and please stop calling me Shirley).
Mozilla's Firebird browser isn't going to be confused with a relational database. Trademark onflicts only arise when there is customer confusion.
I doubt that the people at the Firebird project will see it that way. What is Phoenix/Firebird going to do when they trademark their name (if they haven't done so yet).
It is VERY UNCOOL of Phoenix to pick "Firebird" as a name, because it is taken in the open source world. If I was working on the Firebird RDBMS, I'd be pissed.
Frankly, even the overhead of having to construct the INSERT sql string is waste. You also don't want to maintain the indexes in the target table for each row update. MySQL doesn't have transactions, so you don't have to worry about commit-frequency, but if your load stops in the middle somewhere, I'm not sure what you do.
Oracle provides a loader utility called sql*loader that eliminates the overhead of the per-row maintenance. It has a mode called "Direct Load" which can bypass trigger processing and directly write binary datablock output. This is the fastest way to load data. Of course bypassing triggers is of no interest to MySQL users because MySQL doesn't have triggers, but if it did you'd have another thing to worry about with loading data into MySQL.
As an alternate to sql*loader, you could use external tables or Oracle Generic Connectivity to create an oracle table whose data was supplied by a flat file or ODBC connection. Then you would typeor (faster)Both of which would blow away the proposed method speed-wise.
I suspect IBM will want to be able to import MS Office files into their system... perhaps they'll share some code with the OpenOffice gang.
I suspect they were already doing this via the Apache Jakarta POI project.
I don't think computer is the right word for the commonality. Networks connect computers -- which means they are something different than computers.
How about "Information Technology" instead of computer? They you are, drumroll, an "IT administrator".
This term is not glamourous, but descriptive, and likely to actually be comprehended without inspiring buzzword apprehension.
Instead of removing them, there should be a better filtering ability based on project activity. A project which hasn't moved in 6 months could be labelled "dormant" and if it hasn't moved in 1 year it should be labelled "abandoned".
Good question. I have three good answers to why XML makes it easy to "have a common design".
... Can your data format do that?
1) It's much easier to switch your app from one XML format to another because you don't have to rewrite the whole world of 3rd party XML tools. Parsers, validators, syntax checkers, marshalling, etc...
2) XSLT is much easier than other kinds of file converters (especially if I have to write them to deal with your junky non-XML file format), so maybe we don't have to adopt a common schema but rather we just write two transforms. Oh, and we can use it to convert to HTML and SVG and the open office formats and
3) The XML format is just flat out better. A bunch of really bright people got together and designed a format that had a lot of nice properties. For example, what you call bloat is better called "readability" and compressed XML, contrary to your assertion, is a very compact data format.
XML schema has far greater capabilities in this regard than DTD's.
I certainly agree that 3rd normal form schemas have advantages above even this. The only problem is that RDBMS schemas are tightly coupled to the individual database application that uses them and can't really exist without, well, an RDBMS. Both properties hamper system integration issues.
You might examine Oracle 9iR2's XML database capabilities, by the way.