Slashdot Mirror
Oracle Quietly Switches BerkeleyDB To AGPL
WebMink writes "A discussion in the Debian community reveals that last month Oracle quietly disclosed a change for the embedded BerkeleyDB database from the quirky Sleepycat License to the Affero General Public License (AGPL) in future versions. AGPL is only compatible with GPLv3 and treats web deployment as a trigger to license compliance, so developers using BerkeleyDB will need to check their code is still legally licensed. Even if they had made the switch in the interests of advancing software freedom it would be questionable to force so many developers into a new license compatibility crisis. But it seems likely their only motivation is to scare more people into buying proprietary licenses. Oracle are well within their rights, but developers are likely to treat this as a betrayal. As a poster in the Debian thread says, "Oracle move just sent the Berkeley DB to oblivion" because there are some great alternatives, like OpenLDAP's LMDB."
BrownDB will now be created to complement MariaDB and the other forks Whoracle has forced with their greed.
Mod me down, my New Earth Global Warmingist friends!
Say it ain't so!
Where is your God now RMS, WHERE IS HE???
Has anyone ever been sued over an open source deployment done off license? This seems to be much ado about nothing.
I thought we liked the GPL around here?
Isn't Oracle using a GPL compatible license exactly what we want and should support?
Even as the copyright holder, Oracle can't do jack about existing versions released under other licenses(even if they went full nuclear, and actually terminated all downloads/media purchases under any prior license, there are still third party mirrors. So, Version X-1 is Sleepycat forever.
Is BerkeleyDB a project where Big New Features or Much Needed Upgrades are something that happens frequently, meaning that if you aren't running Version X, you might as well go home? If so, Oracle has actual leverage. If not, it seems likely that a maintained-if-not-terribly-active version can exist in perpetuity, with Oracle having to offer serious advantages in order to retain their status as the standard against which 3rd party development is done.
license shmicense i use what i want.
AGPL is not good. AGPL is horribly evil. It means that I, as a sysadmin installing a piece of software, cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes, even though those changes cannot possibly be of any use to anyone outside my server team except for attackers wishing to discover security bugs, learn the names of database tables, etc. for nefarious purposes.
I don't know about anyone else, but I personally have an absolute zero tolerance policy for Affero. It has no valid place among reasonable open source and free software licenses, as it is the antithesis of software freedom.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Not true, it has good use in webapplications. Think about something like phpbb where they want to release full code for it, but don't want people to modify it even if "only for their server".
So, all projects should be Open with as much Freedom as possible UNLESS they're run by Oracle??? Am I supposed to support the GPL or not???
Please /., tell me how I'm supposed to think on this!!!
AGPL is a perfectly fine license, and I use it myself for certain projects. I'm not sure it's quite appropriate for this case though.
It is intended to attack the software-as-a-service loophole in the GPL, which allows people to take software (e.g. WordPress Multisite) and because it never leaves the server it is running on, it's not being distributed, and so changes are not distributed. And so users cannot take the modified software and run it on their own server.
Like the GPL, the AGPL is a license for end users. It allows them (the end users) to ensure that they always have access to the source code of the software they use.
And frankly, I think that if anyone really cares, they can just fork from the last "good" version.
The only issue that I can just think of (and pointed out in the Debian thread), is that for software that uses the database, they may have to be re-licensed. AGPL is irrelevant though, it would still be the case if BerkeleyDB was re-licensed to GPL or another strong copyleft (OMG virus!) license.
Also, the Infoworld article is simply wrong. If someone uses BerkeleyDB for a webapp, they don't have to make the whole app AGPL, merely GPL3 (which means that if it's an internal only (not distributed) webapp, that nothing changes). Just because it is GPL3, it doesn't mean that it has to be distributed. Though, as pointed out, you can continue to buy a proprietary license if you want.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
They built up a substantial developer interest, they hired a few people, they got some excited customer names, and they got bought. Their founder is now off suggesting *REALLY, REALLY BAD* database ides such as putting a "provenance aware" BDB database into the filesystem. (This failed in WinFS for much the same reasons it's a bad idea for BDB: it's a huge CPU hit and it's not possible to stabilize or recover from the inevitable corruption.)
It had achieved its limits. Errors are unrecoverable, it doesn't scale, and atomic transactions weren't, which led inevitably to errors. The open source world abandoned BDB years ago for precisely these reasons: Oracle bought it to get the customer list and put the existing customers out of their unsupportable misery, and migrate them to something usable and fixable, such as Oracle or MySQL now that they also bought Sun Microsystems.
So exactly how many custom changes do you make to large projects for your own little in-house needs?
. . . unintended consequences.
GPLv3 = poison pill
As an embedded developer, I sympathize with why one would find the AGPL evil... though at the risk of going down a 'they came for the X, but I was not an X' line. Back end developers did not seem to understand why embedded developers were uncomfortable with GPLv3, which was written in such a way as to not anger the more network and infrastructure oriented projects but really put the screws on embedded ones.
That's what happened with iText (a Java library for manipulating PDFs.) It was LGPL, the author got tired of well-heeled organizations using it without contributing either blood or treasure (including, I hear, some who were violating LGPL) and switched new versions to AGPL (with the option of a paid commercial license.)
Some went along, the project (under AGPL) is still going, but many others just keep using the last LGPL version. It ain't exactly broke.
Bah, I must be getting old, because this looks completely unreasonable to me.
From FSF's very own "Four Freedoms":
Freedom 0: The freedom to run the program for any purpose.
From the DFSG:
6. No discrimination against fields of endeavor
With this non-free piece of shit license, you can't take parts of the code and reuse them in about anything else than pretty much just a web service. Want a mail server (both exim and postfix use bdb)? An IMAP server? A networked lift control (don't laugh, I've seen a wifi-connected one)? An IRC bot? Sorry.
I'm a strong proponent of the GPL, but AGPL is a train wreck akin to GnonFDL (literal reading of which prohibits using a technology known as "door lock" from protecting your machine).
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Why is this not LGPL? (Keep the "viral" self contained to the library), or GPL (Application level viral-ability). AGPL? That "infects" everything (Airborne meta-viral!)
Either the developers/lawyers at Oracle don't understand their own product ... or worse that they are nefariously trying to end of life BDB.
How does this work in the USA? If you obtain it from them directly, they are giving you a copy, you aren't copying it yourself - so that's not copyright infringement. Copying software as an essential step in using it does not count as copyright infringement in the USA - so installing it on your server doesn't count as copyright infringement. Responding to incoming web queries doesn't copy any of their work - so that's not copyright infringement. So if you aren't doing anything that is protected by copyright, why do you need a license?
Bogtha Bogtha Bogtha
So exactly how many custom changes do you make to large projects for your own little in-house needs?
Easily one of the lamest questions you could ask.
Serious answer: It's a database program. He/she needs to create a schema. That schema would be covered under the AGPL.
ironically though it should be more RMS friendly.
it's entirely reasonable. it's just not the kind of open and free you're looking for :)
(in fact, most gpl web sw is quite irrelevant that it is such.. because the end users can't get the code)
world was created 5 seconds before this post as it is.
Are you sure the damage is just limited to the configuration changes you made? The attorneys in my organization believed that the language could be extended to anything that runs on the same set of servers, and anything that interacted with the same database.
And it's even worse for libraries (e.g. iText) - there, the thought was that it could require sharing every bit of code used to run the web site. Not surprisingly, we're not using or contributing to anything licensed under the AGPL.
PHPB is precisely the sort of situation where AGPL is unacceptable, because it infects code that has no legitimate association with the software itself. For example, on a website that I run, I currently use a heavily customized PHPBB setup that hooks into the (non-open-source) login system used for the site that it is integrated into. None of those changes would be even slightly useful to anyone but me.
Further, without the ability to migrate the actual data, being able to replicate the service itself is basically useless, which means that putting something like PHPBB under a horrible license like AGPL would buy you absolutely nothing.
Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.
Check out my sci-fi/humor trilogy at PatriotsBooks.
i doubt AGPL requires you to release your data or scripts, since they are not part of the software. If you change the actual code of the database itself, then you need to release the changes. Do you hardcode you table names into the database itself?
Lots of them, actually. Any website is likely to have an authentication system already. Any website wanting to add features using existing open source technology is going to want to tie into that system. This common use case is fundamentally incompatible with Affero, because that authentication system cannot necessarily be made open source, and the AGPL does not provide a linking exception.
Also, before I adopt any piece of software these days, I do a thorough security audit. Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.
In short, anything I touch usually experiences a major fork and a large-scale rewrite prior to deployment. And that's not even counting all the minor stuff like skins, custom icons, etc., much of which often involves minor code changes because of inadequate class and ID attributes in HTML output, the need to manipulate the order of large blocks in ways that makes CSS unhappy, etc.
Check out my sci-fi/humor trilogy at PatriotsBooks.
AGPL is horribly evil. It means that I, as a sysadmin installing a piece of software, cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes, even though those changes cannot possibly be of any use to anyone outside my server team except for attackers wishing to discover security bugs, learn the names of database tables, etc. for nefarious purposes
Sigh. Just the usual red herring.
You never know how useful those changes might be to others.
Besides, if you're that bad at coding that knowing your table names yields a vector of attack... you should probably better leave that to others.
BDB is embedded, which means your code that reads/writes database access in fact does need to be AGPL too.
Michael J. Ryan - tracker1.info
The Affero GPL gives parties the implicit right to audit your software code. If you run affero, you might find a bailiff at your door serving an order for an inspection of your server.
I don't think your interpretation is right: AGPL affects source code, not configuration files. As long as you ship an "example config file" when a user requests the source code, should be enough.
who cares. the sooner it gets killed off the better
Well, I know that a lot of folks moved away from Berkeley DB several years ago when Oracle first acquired it (and by "moved away", I mean "ran away") and embraced SQLite. Now might be a good time for the rest of the open source community to do the same.
Alternatively, for situations where SQLite is insufficient, IMO, PostgreSQL is usually a good alternative.
Better yet, adopt a middleware library like PDO so that with a small amount of effort (rewriting CREATE/ALTER TABLE queries, anything involving triggers or automatic time/date stamping, and a few other rough edges), it can be ported to arbitrary backend databases.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The "example config file" is not in the license language: http://www.gnu.org/licenses/agpl.html
So basically, AGPL is just poisoning the well waters here intentionally?
Life is not for the lazy.
Oh, it's relevant. The principle users of web software are the admins. They configure the software, they maintain the installation, they monitor what people are doing to it, etc. The GPL does something useful for those folks; it ensures that someone won't fork these tools, create their own versions of them, and sell them without giving their changes back. So it serves a useful purpose.
The AGPL, by contrast, adds additional restrictions on the site admins, but adds nothing of value for the so-called "users". Random website guests do not have direct access to the database (and it would be disastrous to give them such access), making their ability to spin off their own copy of the site largely moot except in very limited circumstances. And even if they somehow could get their data, for the most part, what makes a site valuable is usually the community, not the data, which means it would mostly be useless anyway.
In other words, it's a solution in search of a problem—maybe if someone were writing Google Docs under the AGPL... but nobody is ever going to do that, realistically—nobody sane, anyway.
Ironically, the software that Affero builds, given that it involves payment systems, is again precisely the sort of software where private customization is most crucial to the success of the software, and where again no end user could usefully take advantage of the changes anyway.
Check out my sci-fi/humor trilogy at PatriotsBooks.
AGPL is horribly evil.
Wow, so I might have reserved that word for something like "genocide" or "the holocaust", but if you want to use it for a license which you happen to have a dislike for, I guess that works.
After all this is slashdot, and perspective is SO passé.
Don't worry, I'm sure that in a few days Oracle will announce that this change was just a bug, just like when they did it with the MariaDB man pages a few weeks back. It's all an innocent mistake made by their software. Oracle is our friend and only has the best of intentions for everything it does.
(The above was intended to be somewhat tongue-in-cheek; I have no real opinion of the change or whether it is good or bad for the end-uses. It just amuses me that Oracle would attempt something like this after getting spanked for a similar change they made just a few weeks back. Did they think nobody would notice? They don't have such a good reputation to begin with; better to be above-board rather than try to silently slip in a new re-licensing).
Who is talking about a configuration file? Have you ever tied a piece of software into a different authentication system? This isn't a config file change. It's potentially thousands of lines of code changes throughout the software, depending on how the software was written and how many assumptions it makes about the nature of the authentication system. (For example, my current authentication system does not use cookies. Any software that assumes cookie-based authentication tokens requires considerable changes.)
Check out my sci-fi/humor trilogy at PatriotsBooks.
Yes just ignore the other freedoms.
The use of the BerkeleyDB do not put any restrictions on your software, as long as you do not statically link it.
A database connection is not covered by the GPL or AGPL and do not make it a derivative work.
As long as you use, for example Debian, you already comply with the AGPL license, because Debian distribute the sources already.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
As long as you use, for example Debian, you already comply with the AGPL license, because Debian distribute the sources already.
Alter a single bit and you need to distribute your modified version. Which for most networking protocols is impossible or impractical.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
I don't have any sympathy for embedded projects that are uncomfortable with GPL V3. It was specifically designed to prevent the TIVO situation. I heartily approve of that. Let me tweak the software, for heavens sake.
Configuration files aren't under AGPL. The source code itself is. System admins don't need and generally aren't capable of making C-langauge source changes for using software in normal configs.
The FSF has a definition of the term "free software".
Software under AGPL is not not free software according to that definition. It violates freedom 0.
Yet the FSF approved AGPL! This was an ethical disaster.
A key difference between free software licenses and commercial software EULAs was that the latter was a two way bargain. The copyright owner, who the law gives the exclusive right to make copies (including, for computer software, making temporary copies in RAM to use the software) grants you via the EULA permission to do that, in exchange for you agreeing not to do some things that otherwise would be allowed under copyright law. For example, you might have to agree to not reverse engineer the software, or to sell it when you are done with it.
The free software licenses, on the other hand, only grant you permissions. They do not require you to give up anything.
Until AGPL. AGPL goes beyond just granting you permission to do things that copyright law says require permission. It places restrictions on what you do with the software on your own machine. It is a EULA.
If you are talking about thousands of lines of code changes to dozens of files ... yes you should be make it public. It becomes an example for the next person looking to use an authentication system.
Alternatively you could write an authentication layer make it BSD and make that public.
Think about something like phpbb where they want to release full code for it, but don't want people to modify it even if "only for their server".
So in other words, it's not really Free Software. Got it.
Dewey, what part of this looks like authorities should be involved?
Some of the best C programmers I know are system administrators. Going into the source code to something really helps when you're debugging why a specific service doesn't work or program X hammers the NFS share with 4 kB requests.
phpBB is currently under the GPLv2. The person you replied to didn't say they are unwilling to share their source code, just that such work would be unproductive. Do you always rant about straw men like this?
The AGPL in question is actually AGPL3 (implemented using the GPL3 extension mechanism). AGPL is a derivative of GPL2.
I am becoming gerund, destroyer of verbs.
The use of the BerkeleyDB do not put any restrictions on your software, as long as you do not statically link it.
The Sleepycat license doesn't trigger based on linking; it's triggered by compiling against it. See The Sneaky Sleepycat License and comments from Oracle's forums. The existing license was already very "viral" in terms of how aggressively it required either open source distribution or a commercial license.
Altering BerkleyDB has nothing to do with this. The existing Sleepycat license has always said that compiling against their libraries and distributing the result requires that you either release your application as open source, or buy a commercial license. You can't assume it acts like a GPL or BSD license, it's really aggressive in its own unique way. This is not Oracle taking a regular open-source product and giving it a restrictive commercial license. BerkleyDB always had such a commercial license clause. The change Oracle is making is mainly about closing the loophole where you could avoid even compiling against the database by building a SAAS interface to it.
Oracle clearly has the legal right to do what they are doing, and there is no morality in business, so that is the only right that matters.
Do they actually have the legal right? I contributed patches to BDB 1.0; I don't remember being asked for an assignment of rights so that they could legally change the license. The SleepyCat license only applied to the newer code added by Margo, which, if you wanted to use the newer code, you accepted the license on the aggregate work, and if not, you could excise the new work from the code by using an older version.
It's not clear to me from TFA exactly what the license change means, or if this is merely hand-wringing, since so far it has not changed the tar ball contents, and therefore the license declaration within the tar ball. However, if their intent is to relicense *all* the code, not just the SleepyCat portion of the new code, then that's a problem.
Depending on your application, this could be a good thing or a bad thing, mainly for commercial works. Under Sleepycat:
This is more aggressive than the traditional GPL view of linking, where function calls count as linking but IPC and sockets don't.
Oracle, of course, takes a very broad view of "accompanying software" and "uses the DB software"; if you distributed something like a virtual machine image with a proprietary PHP frontend to a Cyrus IMAP server (which uses BDB), then Oracle would say that the PHP frontend must be open sourced or paid for with a license, even though the PHP frontend is just using a generic IMAP connection and is in no way a derivative work of the IMAP server.
The AGPL is not as viral when it comes to traditional software distribution, but it does impose distribution requirements on user-facing server software that pwouldn't have been under the GPL.
I can't really begrudge Oracle for trying to make money off of BDB; rather, I blame free software developers for unwittingly using a license that has always been more viral than the GPL, especially for projects like Python that were never GPL to begin with. I think this is because Oracle never enforced the licensing restrictions against fully free software projects, just against ones that mixed commercial and free components.
Full disclosure: the company I worked for had to pay Oracle a bunch of money every year for licensing BDB.
There is a database included in the jdk called javadb. Same as derby, which came from cloudscape.
You are a confused man and it appears you might have never used ether one of those.
The use cases are completely different. You cannot seriously talk about substituting BerkeleyDB with PostgreSQL (not that it wouldn't work, but it is so far at each extremes of persistence spectrum when it comes to functionality and operational overhead that they might as well be from different planets).
If the license would say that you need to share your modifications, then that is what you agreed to.
It can be unproductive, but that is not the issue. The issue is that you agreed to the license.
I have offered the alternative: to negotiate a different license. Sure it means that you probably have to pay.
But you are a hypocrite if you take a free product, and demanding that the developer is using a less restrictive license.
And you are more a hypocrite if you make up some arguments, like sharing your modifications is unproductive, the license the developer choose is "unacceptable", the license is "horrible", etc.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
I find it extremely hard to believe that a court would consider a schema to be a "derivate work".
Dilbert RSS feed
because that authentication system cannot necessarily be made open source
What? Why not? There are plenty of open source authentication systems. In fact, I'd say it's extremely reckless to use a security system that hasn't been widely vetted, and that requires available source.
Besides, it's not true that it would necessarily require open sourcing the authentication system. If you're using something with a service interface, then only the "bridge" that extends the webapp to talk to it should have to be open sourced.
Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.
Irrelevant. None of the (A)GPL licenses require you to give anything back. All you need to do is inform your users that a copy can be arranged if they ask for it, nothing more.
Dilbert RSS feed
It forces proprietary developers to spend time and money writing their own code instead of milking the free software cash-cow. If nothing else, that makes it worthwhile.
Dilbert RSS feed
Free software advocates would argue that your users are "running" your software, and thus are owed the source code.
If you are running a forum you ARE running software as a service.
Your description and outrage is how MANY people feel about the GPL vs the LGPL.
If you depend on the high-availability, replicated functionality available in recent BerkeleyDB systems, then PostgreSQL can potentially be used as an alternative where many lightweight database systems (SQLite, for example) cannot be seriously considered.
I have no idea what the NoSQL space is like these days, so there may be better choices over there. I've never used those parts of BerkeleyDB (those features didn't even exist until years after I last touched BerkeleyDB), so I can't say how they compare performance-wise.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Is still unencumbered, correct? Sad to see yet another 'classic' piece of code go the way of the dodo due to greedy companies.
Because I spent a lot of time on that software, and I'm not really interested in giving it away? Look, the only reason I'm modifying the open source software at all is so that users don't have to create two login accounts. That hardly warrants giving away the source code for an existing login system that is an entirely separate piece of software in its own right, merely so that the open source software can use that login system. Any software whose license demands such a thing is going to get no more than a laugh and an eye roll from me as I search for other software whose license isn't so utterly absurd.
And this is not to say that I won't at some point choose to give away that source code. I will not, however, even consider using a piece of software whose license would force that decision and the timing thereof.
None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)
You missed my point entirely. The point I was trying to make was that even as a user of software whose license does not require me to give the changes back, I do at least make the attempt if those changes would potentially benefit anyone else. I'm not averse to giving back changes. However, as a site admin, I absolutely require the right to be able to make the final decision as to which changes I make publicly available and which changes I don't. It's fine if you don't agree with me, and it's fine if you decide to license your software under AGPL because of it, but if you do, I guarantee that I won't use your software. Ever. Even if I don't need to modify it initially. Why? Because it locks me into a situation where if I ever needed to modify it in the future for any reason, those changes would have to be public, no matter how sensitive those changes might be. That isn't an acceptable risk to me.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Larry kills another one. The ultimate bait-and-switch operation is Oracle.
Organization? You must be joking..
PHPBB is licensed under GPL, not under AGPL. The GPL requires you to share your source code modifications with anyone to whom you distribute the software. PHPBB being a server-side app, none of the software is distributed. At all. Therefore, its license says that I am under no obligation to make available local modifications.
I'm not demanding that the developer use a less restrictive license. I'm saying that I'm glad the developer chose to use the less restrictive license because had the developer used AGPL, it would have prevented me from even considering its use.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Our product used open source. We gave back a significant amount. Library work, bugfixes, drivers, management was supportive of contributing. But, our final device required a network of trust, people using them (and, more importantly, underwriters and regulators) needed to know that OTHER people were not running modified software and cheating other users.
So when GPLv3 came out, we had to stick to GPLv2, which ment participating less. Then we switched to Windows, which ment we did not participate at all anymore.
When an embedded device connects to other devices, sometimes the integrity of the network is more important then individual's desire to get a leg up or tinker.
It's a question of scale. Consider an ant attacking another ant; it's murder from an ant's perspective, but on the human scale, we don't care. Same deal for AGPL vs. the holocaust. In the context of licensing, AGPL is horribly evil. In the context of human civilization as a whole, it's below the noise floor. :-)
Check out my sci-fi/humor trilogy at PatriotsBooks.
AGPL is not good ... cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes
I dont know berkleyDB, can you explain the reasonaing behing concluding that "site configuration" changes are part fo the program.
Does it not have seperate config files or something... maybe you could submit a patch ?
He never said that. He suggested SQLite as an alternative to Berkeley DB.
He only suggested PostgreSQL if you have DB needs greater than what SQLite can offer, but that doesn't cover BDB; basically, he's saying that you can cover most of your database needs with one of those two databases: SQLite on the low end, and PostgreSQL on the high end.
If you are using anything Oracle could exert any legal argument over, stop using it immediately. Look at the Federal Government, they are running away from it at light speed so that now you much show a major justification to use any Oracle products. Even the Feds have been screwed too many times by this company. So if you are using anything that they can exert a legal claim to - switch to something else. This is a company best killed...
Because I spent a lot of time on that software, and I'm not really interested in giving it away?
So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.
None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)
Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?
Have you read Matasano Security's critique of JavaScript cryptography? Last time it was discussed on Hacker News, the only real objection was that you could use a browser extension to implement the crypto - nobody had a solution for pure, extension-less cryptography.
Dilbert RSS feed
See, that is why you are a hypocrite.
Oh how glad the developers of PHPBB must be that dgatwood is using their software.
In that discussions I sometime wish that there would be no GPL, AGPL or BSD or any other open source software so that people like you would not get a free ride.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
How does forcing developers into not making use of Free software help anyone?
Syllable : It's an Operating System
That's news to me. I think you might underestimate sysadmins.
Syllable : It's an Operating System
In the same way that increasing the cost of whips would help the slaves.
Dilbert RSS feed
Just now many databases do these wankers own anyway?
yeah you're talking sweedish and I'm talking greek. The network is never to be assumed safe. If you have to make that assumption, you've already failed.
Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.
I'll give an example of a use of AGPL. I develop game software with a handful of other devs. I'm the only coder. Prior to game release I license all my contributions under the AGPL so that if I quit, I can take my code with me. However, if they want to sell my code as closed source, they'll need to make it to completion and have me dual license under BSD. At that point we can sell a closed source version of the game software. At any time after sales begin, any member of the dev team can then release the source code as AGPL or BSD. So, there's no "we can't release source without rights holder permissions". We worked that out ahead of time.
In this way I don't have to trust anyone and they don't have to trust me. We do trust each other, but the system is future proof against falling outs (which is frequent in the indie game dev community). No one can just take their ball and go home -- Were I to leave the project I could still use the engine on other projects, and they could still make a game, and get another coder, but the end result would have to be open source. Compliance with AGPL is actually built into the game engine. In addition to containing an archive of the source as an asset during builds, any scripts or mods are necessarily transferred from the server to the client at run-time so that the game can function. A BSD licensed version can simply transfer pre-compiled bytecode instead of textual scripts, and remove the compressed source code from the asset library.
So, here we have a use case that's not exactly aligned with the intended goal of AGPL, unless a goal is to prevent anyone from benefiting from your code without you also benefiting from the additions too. It's actually directly opposite to your claim that I wish to prevent competition, I actually want to ensure competition can exist and ensure no complete loss of effort is possible. Sure, I run the risk of a team member bolting and releasing code under AGPL, but that doesn't prevent us from re-licensing as BSD down the road.
I'd love to release everything open source all the time (and do this for all software that's not game related) but it exponentially increases the number of cheaters in online games (don't give a damn about offline cheats). I've experienced this several times in online game communities, in both directions, closed to open, and open to closed. Until more effective community management systems are in place, games remain unique pieces of software where it's OK to not give users every tool they need to cock-up the game for everyone else (so long as the game respects the end-user, i.e., doesn't have non-features like DRM / spyware). One bad apple spoils the bunch, so griefers affect far more people than themselves. I agree that AGPL isn't the right choice for all projects, but to say it's never applicable except in some narrowly defined scope is just silly; I'm not arrogant enough to make such claims, I'm sure other use cases exist.
P.S. The saying "Security through Obscurity is No Security at all" is utterly false. All security is security through obscurity, and every bit of obscurity counts. 512 bits is 1/2 as secure as 513 bits of obscurity -- Obscurity increases security exponentially, DERP! If the obscurity was no hindrance then "open source" wouldn't even need to exist, eh? It's true that where there's a will, there's a way, so why not require sterner wills to brave harmful ways?
Exactly. If "the schema" would fall under AGPL, then "the data" they put in the DB would probably also fall under the AGPL.
In the same vein, any novel written in a GLP text editor would have to be GPL, and any song recorded with a GPL recording software would have to be GPL. There still is a difference between "modifying the software" and "putting data into the software the way you are supposed to"
Come again? The word "hypocrite" doesn't just mean someone who disagrees with you or does things you don't like. It means someone who says one thing while simultaneously doing the opposite. Nothing I have said or done in this thread even remotely qualifies as hypocrisy.
Free ride? Hardly. I spent about half a decade maintaining a Linux distro on a platform that only a few thousand people ever cared about. I've released quite a bit of software as Open Source, both on my own and through my employer. I'm one of the open source advocacy people within my company, actively encouraging development teams to release software as open source.
I'm not being a hypocrite here. You are. You're insisting that I'm somehow doing evil by using software well within the terms under which it was licensed, and you're arguing that in order to use open source, I should be forced to release everything I do, no matter how distantly related, as open source. Unlike what I'm doing, your argument is hypocrisy—claiming to support the GPL while simultaneously attacking people who use GPLed software in full compliance with the license, thus giving the entire Free Software movement a bad name.
Oh, but they are. You see, the only way to get more eyes on the code fixing bugs is to actually have other programmers using that code. When I use a piece of software, I invariably find bugs. Lots of bugs. And I fix those bugs and submit patches. Therefore, it is in PHPBB's best interest to have more people like me using their software—actual programmers, rather than mere end users with no programming skills who leech off their efforts and contribute nothing back. In exchange for me finding and fixing bugs, PHPBB's license allows me to keep private my site integration changes that would not benefit anyone and that are nobody else's business. This strikes a good balance between the needs of the admin/user and the needs of the developer.
The AGPL instead fails to strike a balance. It represents the effect of our entitlement-driven society on the Open Source movement, demanding that every change be made available even if you do not redistribute the modified software. And that changes the delicate balance between site developer and software developer in a way that makes it much less useful to me.
You can disagree with me all you want to, but disagree with me by pointing out reasons why you disagree. Name-calling ranks right up there with Godwin's law; it automatically means that the debate is over and you have lost.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Actually, that's a great analogy, but not for the reasons you think. By increasing the cost of the whips, the plantation owners require more output from the slaves to cover the extra cost of the whips, so they drive the slaves even harder.
In much the same way, by making contributions back from the community an absolute demand as the AGPL does (and, to a lesser degree, the GPL does), developers who cannot or are unwilling to comply with those requirements must reinvent the wheel, thus increasing market fragmentation and reducing the number of eyes looking at any one implementation. This, in turn, reduces the quality of all of the offerings and hurts the Free Software community every bit as much as it hurts the businesses. In order to make up for the loss of developers, those community developers must work even harder if they want their software to be seen as a viable alternative to the commercial equivalent.
Check out my sci-fi/humor trilogy at PatriotsBooks.
In this case, it's one line of JavaScript that queries a PHP script that fetches a database record out of a different database and inserts a cookie into the browser while simultaneously blowing a matching user record into PHPBB's database, coupled with lots of changes to rip out every place with a login/logout button, a password change button, or an account creation button. None of that is going to be all that useful to... well, anybody, really. It is entirely a site-specific hack. It's also going away because I found a different bulletin board suite that is actually based on XHR requests so it can integrate with my authentication system correctly. (By contrast, making PHPBB integrate with it properly would have required a near-complete rewrite of PHPBB.)
Check out my sci-fi/humor trilogy at PatriotsBooks.
Incidentally, the only reason it interfaces with PHPBB's code at all is because PHPBB has a specific way of sanitizing the UTF-8 data for certain fields, and there's no good way to replicate that. So for compatibility, it has to use PHPBB's function, which would put that piece under the GPL if it were distributed (which it isn't). If it were under AGPL instead of GPL, it would have to be redistributed, and would reveal details that I don't want to reveal.
Really, there are large chunks of PHPBB that would be better off under a less restrictive license like the LGPL, if only so that third-party plug-ins that call back into parts of PHPBB aren't forced to be GPL-licensed. But that's not my decision to make.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The same thing that prevents an attacker from grabbing cookies out of the browser's cookie store. Third-party JavaScript does not have access to client-side storage unless it was served from my origin, and the code running on my origin is vigilant about ensuring that third-party JavaScript cannot be injected. (For the one part of my site that allows HTML submission, I have a whitelist of HTML tags and attributes that are allowed, and anything not on that whitelist gets eaten.) Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.
Check out my sci-fi/humor trilogy at PatriotsBooks.
In this case, it is my code to do with as I wish. The point I was trying to make is that it is not true for every case, particularly when you're working for a company that may have contradictory agreements with other companies.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Then publish the patch file to rip out everything. For the one line of javascript just publish a generic version of the line. Now you qualify.
That's fine; I rather work harder than help the slave owners.
Dilbert RSS feed
Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.
Well, if you used cookies, you could set them as HttpOnly, which would prevent even your JavaScript code from accessing them.
That said, I was thinking more about that scheme vis-a-vis using HTTPS, and in particular in the case of a man-in-the-middle attack. The problem with JS crypto is that you can't securely deliver the code to the browser, so all bets are off if you have an attacker that can modify the stream.
Dilbert RSS feed
leveldb, google?
I know tobacco is bad for you, so I smoke weed with crack.
You say infect, I say liberate.
Prove to me that you have the right to control code you've written. Prove to me that it's not derivative of public domain work.
Hint: You can't.