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???
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.
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.
It's the intentions behind it. Switching to GPL3 means it is much more restrictive in how it can be used in commercial products. As a general guideline, if there's ever a question about Oracle's motivations when it comes to a choice between advancing open source and trying to force more people to their proprietary products, he answer is pretty straight forward.
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".
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!
It already was GPL-compatible, so that part hasn't changed. They've gone from a more liberal license (the old license was compatible with, among other things, the GPL v2) to a less liberal one. That's always going to piss off some people. Just look at the controversy when a project goes from BSD or MIT to GPL.
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.
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.
Has anyone ever been sued over an open source deployment done off license?
Um, yes, it happens all the time. The owners of BusyBox, for example, have not only sued, but won several cases, for example. And Oracle sued Google, in part because Google's Dalvik was under a less restrictive license than Java's GPL—and they only lost because Google was able to show that the parts they actually copied (the API) weren't subject to copyright. But that's a clear precedent for worry about what Oracle might do.
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.
you can use it for commercial products.. you just can't take the freedoms for yourself while restricting your users from those freedoms.
you could always just go for some bsd licensed db if you'd rather want that.
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.
Except with the AGPL, use is not free.
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.
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
Actually, "Open with as much Freedom as possible" would be releasing the code into the public domain.
The entire purpose of a license, ANY license, is to place restrictions on what can be done with the code.
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.
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é.
Yes, I do. Unless someone steals the closed-source authentication system in question, tying into it is not useful in the slightest.
If you think that not knowing the table names does not make all vectors of attack more difficult, you should probably leave the advice to people who understand security. :-)
In computer security (or any security, for that matter), the best defense is a layered defense . I'm quite good at performing security audits, having spent significant amounts of time over the years doing so. However, any sufficiently large chunk of code, no matter how well analyzed, stands some small risk of containing security holes. So in the event that I missed something, using nonstandard table names provides an additional defensive layer that makes any sort of compromise considerably more difficult.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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.
You've described this as if it weren't a big deal, but there is a lot of GPLv2 software that's going to require changes if the new version of BerkeleyDB is giong to be used with it. For Debian that means either a) sticking wtih an old version of BerkeleyDB before the license change, b) a LOT upstream projects changing their license (which realistally they likely can't), or c) switching away from BerkeleyDB to an alternative and patching the various source packages to make it work.
Just to give you a short list of packages affected (Ondej Surý gave an exhaustive list, which I'm greatly summarizing here):
apt
bind9
bitcoin
bogofilter
boxbackup
cfengine2
cfengine3
cyrus-imapd
cyrus-sasl2
dnshistory
dovecot
drac
dsniff
exim4
glusterfs
iproute
iproute2
lucene2
opendkim
openldap
nvi
pam
perdition
perl
php5
postfix
python2.7
python3.2
python3.3
reprepro
rpm
sendmail
spamprobe
squid
squid3
squidguard
subversion
tcpstat
webalizer
vacation
and many others. Regardless of the solution chosen, this change represents a lot of required work needed to fix something that before now wasn't broken.
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.
No they aren't.
The readers of documents I produce using open source tools aren't the user of those tools either.
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.
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).
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
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.
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.
And it is not, except by having special case terms in the license to allow it even though it would not usually be allowed.
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
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
Actually, "Open with as much Freedom as possible" would be releasing the code into the public domain.
Except, in most countries (like most of EU and USA) you as an author CANNOT release the code into public domain (unless you die, stay dead for 70-90 years, and hope copyright protection does not extend in that time, which is a hope against current trend of practically infinite copyright). For example, see http://en.wikipedia.org/wiki/Public_domain_in_the_United_States
The entire purpose of a license, ANY license, is to place restrictions on what can be done with the code.
That is totally incorrect. It is the copyright that places restrictions (remember "all rights reserved" phrase?). If there was no license at all, standard copyright would be in effect and you would have no right to copy, modify, translate, etc. work at all (except as governed under fair use and similar exceptions).
The license is actually copyright holder GIVING UP some of his/her copyright protections, sometimes (but not always, see WTFPL for example) in exchange for some other promise on users side (for example, proprietary licenses might allow you to to make 5 copies of some program IF you agree to give them e-mail to spam you; or GPL might allow you to copy that program without limits IF you agree you'll also allow others makes copies of your derived work, etc.)
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.
It's only "compatible" because GPL3 (and not GPL2, note!) explicitly allows combining GPL3 software with AGPL.
A great many of those packages are GPL2+, which is compatible with the AGPL. Of course, that means the overall license for the binary would end up AGPL, but the original code would remain under the GPL2+ license, just as BSD code included in a GPL'd binary remains BSD-licensed.
The only projects that would be affected would be those which chose GPL2-only, which in my surveys, is a very small number. Somehow, I seriously doubt that the Linux kernel is or ever was using bdb. :)
They sued because they wanted people to use Java ME instead, but if they'd actually tried to sue over Java ME, the case would never have gotten as far as it did, because Dalvik was based on Apache Harmony, which in turn was an implementation of Java SE. Not ME. There was absolutely no copying from ME, either actual or even alleged.
The patent part of the suit was more strongly related to Java ME, insofar as the patent licenses for SE didn't apply to mobile devices. However, since Google wasn't practicing their patents, that also got them nowhere.
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.
No Berkeley DB is a fine piece of kit, i spent several months building a web forum system with Berkeley DB as the database. It worked fine, Berkeley did exactly what the API promised with no extra messing about needed. I would recommend Berkeley for simple NoSQL applications.
You would be doing anyone you make such a recommendation to a disservice. BerkeleyDB was a nice piece of work for the 1980s. It is totally outclassed by LMDB today.
-- *My* journal is more interesting than *yours*...