As several people have said earlier, it would be sloppy not to include a citation to any software you use when you write a scientific text. I've more often experienced the opposite problem; trying to find an article to cite for a piece of software I've needed to use. At times you cannot find such articles and hence you are forced to refer to some web page inststead. Which of course will be down the exact day the referee reads your article. I've never met anyone who are reluctant to cite the software they use. After all, a scientific article on the software frees them from the responsibility of describing every piece of it themselves.
So, to the licensing issue; I'd strongly recommend sticking to one of the standard licenses. It really helps the people who want to use your code (and hence will cite your articles). For every new license your users must consider, they will be forced to decide wether or not they can use your code together with other stuff they need. If they want their program released as free software, and particularly if they want it included in e.g. Debian they will probably steer away from unusual or non-DFSG-compliant licenses. Your supervisor wants them to use your software (even though he might not know that) because usage generates citations.
Trust your users, they will cite you. (And give them the BibTeX entry to your article to make it easier for them.)
Even here in Europe where we do have maps from Google, Microsoft, $you_name_it, an open map does have advantages. First, open data allows you to highlight the map features that are important to you. One of the things that seems to become popular in openstreetmap is generating bicycle maps. Likewise, you can make a map that highlights schools and universities, hiking paths or churches. And you are allowed to publish the maps you make, without getting any written permission or paying royalties.
The second important advantage of open data is that you can bring them over to any device or convert them to any desired format. I'm currently using only OSM maps on my GPS device. I cannot do that with Microsoft's data (it is prohibited by the EULA, and it's probably not technically possible unless you're a Microsoft employee).
I suppose it will stick. A government is a large body and does have a lot of inertia, hence it will necessarily take some pushing to get this thing going. Lots of offices need ODF plugins for MS Office, scripts need to be changed to become compatible with these plugins, you may need new routines for storage and indexing, etc. There is broad political agreement on this in Norway though, so even if there should be some kind of political crisis during the next year, this decision is likely to stay. Together with the recent Dutch decision to prefer open standars this might be enough to get the ball rolling, at least in Europe.
Oh, FWIW, Norway and the Netherlands aren't very corrupt countries;->
I have a Samsung YP-Z5F that works
perfectly with Linux (Ubuntu in my case).
Pure plug and play, automatically popping up in rhythmbox.
Plays ogg files. (And because ogg has a better compression than mp3 at the same bit rate,
you either get better quality or more music on your 4GB.)
Long battery life.
But using Linux and preferring open formats for my music, I do need to look a bit closer at the players than a
windows user has to. The upside to this is that I won't end up depending on some weird proprietary software to be able to use
the device.
One of the reasons public key encryption is not more widespread is the lack of support in popular mailing software. Normal users do not feel that encryption is important enough to bother downloading and installing patches/modules to their MUAs. Now, if it was already part of the package and all you had to do was to click a button on the toolbar to turn on signing/encryption, it would be much more probable that people actually used it.
As for standards, (open-)PGP is the only encryption format widespread enough for practical use. It is also well-documented and there are conformant applications and libraries for most if not all popular platforms.
It's still a step in the right direction for the OSS community. If the codebase is good, a community for cleaning/improving the source will probably gather. If not, ideas may be extracted and used in other OSS databases, such as postgres or interbase.
Every large project going open source will add to the knowlege base of the open source community, so we should be grateful to them for giving us the code, no matter what their reasons might be.
btw; it's good to see that they've used GPL instead of following the trend of making new GPL-soundalike licenses.
* What SQL-based features does it have and lack? The only thing it seems to lack is the INTERVAL data type (for storing time intervals). * How does it compare to Postgres, Oracle and MySQL (in speed and features)? I've read a test on InterBase vs. Postgres, where InterBase came out best in just about everyting, except where multiple clients were working simultaneously (Postgres was far better in this respect). But since then IB has been changed from process-per-client to thread-per-client, so I guess that InterBase would win a comparison now.
Slashdot Mirror
A decade isn't very long in book years, so I'd recommend browsing through the top list from BBC's 2003 survey The Big Read.
--
E.R.
As several people have said earlier, it would be sloppy not to include a citation to any software you use when you write a scientific text. I've more often experienced the opposite problem; trying to find an article to cite for a piece of software I've needed to use. At times you cannot find such articles and hence you are forced to refer to some web page inststead. Which of course will be down the exact day the referee reads your article. I've never met anyone who are reluctant to cite the software they use. After all, a scientific article on the software frees them from the responsibility of describing every piece of it themselves.
So, to the licensing issue; I'd strongly recommend sticking to one of the standard licenses. It really helps the people who want to use your code (and hence will cite your articles). For every new license your users must consider, they will be forced to decide wether or not they can use your code together with other stuff they need. If they want their program released as free software, and particularly if they want it included in e.g. Debian they will probably steer away from unusual or non-DFSG-compliant licenses. Your supervisor wants them to use your software (even though he might not know that) because usage generates citations.
Trust your users, they will cite you. (And give them the BibTeX entry to your article to make it easier for them.)
Even here in Europe where we do have maps from Google, Microsoft, $you_name_it, an open map does have advantages. First, open data allows you to highlight the map features that are important to you. One of the things that seems to become popular in openstreetmap is generating bicycle maps. Likewise, you can make a map that highlights schools and universities, hiking paths or churches. And you are allowed to publish the maps you make, without getting any written permission or paying royalties.
The second important advantage of open data is that you can bring them over to any device or convert them to any desired format. I'm currently using only OSM maps on my GPS device. I cannot do that with Microsoft's data (it is prohibited by the EULA, and it's probably not technically possible unless you're a Microsoft employee).
I suppose it will stick. A government is a large body and does have a lot of inertia, hence it will necessarily take some pushing to get this thing going. Lots of offices need ODF plugins for MS Office, scripts need to be changed to become compatible with these plugins, you may need new routines for storage and indexing, etc. There is broad political agreement on this in Norway though, so even if there should be some kind of political crisis during the next year, this decision is likely to stay. Together with the recent Dutch decision to prefer open standars this might be enough to get the ball rolling, at least in Europe.
;->
Oh, FWIW, Norway and the Netherlands aren't very corrupt countries
- Pure plug and play, automatically popping up in rhythmbox.
- Plays ogg files. (And because ogg has a better compression than mp3 at the same bit rate,
you either get better quality or more music on your 4GB.)
- Long battery life.
But using Linux and preferring open formats for my music, I do need to look a bit closer at the players than a windows user has to. The upside to this is that I won't end up depending on some weird proprietary software to be able to use the device.As for standards, (open-)PGP is the only encryption format widespread enough for practical use. It is also well-documented and there are conformant applications and libraries for most if not all popular platforms.
This is probably a smart move by SAP. So what?
It's still a step in the right direction for the OSS community. If the codebase is good, a community for cleaning/improving the source will probably gather. If not, ideas may be extracted and used in other OSS databases, such as postgres or interbase.
Every large project going open source will add to the knowlege base of the open source community, so we should be grateful to them for giving us the code, no matter what their reasons might be.
btw; it's good to see that they've used GPL instead of following the trend of making new GPL-soundalike licenses.
* What SQL-based features does it have and lack? The only thing it seems to lack is the INTERVAL data type (for storing time intervals). * How does it compare to Postgres, Oracle and MySQL (in speed and features)? I've read a test on InterBase vs. Postgres, where InterBase came out best in just about everyting, except where multiple clients were working simultaneously (Postgres was far better in this respect). But since then IB has been changed from process-per-client to thread-per-client, so I guess that InterBase would win a comparison now.