
AGPL no more - hbbio
http://blog.opalang.org/2012/05/opa-license-change-not-just-agpl.html
======
kylemaxwell
I found the headline a bit misleading. Maybe it's just me, but when I see
"AGPL no more", it sounds like the FSF is deprecating the Affero GPL. And the
article isn't even about a project dumping the AGPL, but licensing different
components in different ways while retaining the AGPL for a major part of the
core.

I'd hope for better headline writing in the future.

~~~
hbbio
I thought the domain name next to it was giving a hint. Better headline might
have been: "Dual licensing business model does not work anymore" but that's
long.

------
asparagui
The future is BSD style licenses, not the GPL3 variants. RMS got a little too
clever for his own good.

Why on earth would you agree to give up your source code/competitive advantage
to save writing a few hundred lines of javascript? It's one thing to try and
write a kernel from scratch, but to sell your soul for a Javascript library
(looking @ you, Sencha Touch, which is mostly re-themed jQuery mobile) is
silly.

At least these licenses have a good purpose: they provide a shibboleth for
identifying the ideologically pure.

~~~
streptomycin
You seem to be implicitly assuming that "the future" is "a few hundred lines
of javascript".

~~~
sparkie
Also implicitly assuming that all code is written for competitive advantage,
and that licenses are aimed at developers.

------
protomyth
from the post: "The Opa compiler will remain an AGPL project."

The title on the blog post is "Opa License Change: Not just AGPL anymore"

~~~
kstenerud
From the post: "The standard library and the native backend will be licensed
under the GPL license with the so-called ClassPath exception, like Java. The
exception means you can link the GPL code with any code, opening the door to
license your application under any license."

~~~
protomyth
Yep, multiple parts having multiple licenses. My point was the AGPL is still
in the mix.

for completeness here is the list from the post:

1\. The Opa compiler will remain an AGPL project.

2\. The standard library and the native backend will be licensed under the GPL
license with the so-called ClassPath exception, like Java. The exception means
you can link the GPL code with any code, opening the door to license your
application under any license.

3\. The forthcoming Node.js backend will be licensed under the MIT license.

------
rmc
_most developers won’t release the source anyway while they develop for many
possible reasons: It’s not working yet, they are not proud of their code yet,
they don’t know what to do with it yet, etc._

Well under the AGPL they are required to release the code… Sorry, but that's
copyright law and that's the copyleft licence.

~~~
mikeash
No, they are only required to release the code when the distribute the result.
The license does not compel a developer to release the code before they've
started distributing it.

~~~
emillon
In the context of the AGPL, serving an application is like distributing a
binary, so they should distribute its sources too.

~~~
mikeash
Which probably doesn't apply while the stuff is still in development.

------
chimeracoder
Will the formerly AGPL components continue to be dual-licensed under the AGPL
as well?

If not, that's a problem, because the AGPL and GPL are incompatible, so that
means that nobody can use the AGPL for new forks/patches on the product
anymore.

(That's not quite true in that they can receive a copy of the product from
someone who received it under the original AGPL license and therefore can and
must redistribute it under the AGPL, but the point is that, when making
licensing changes, you should always _add_ a licensing option instead of
changing it, because the latter isn't really possible, and the former is more
explicit as to the outcome).

~~~
dalke
AGPLv1 and GPLv2 are not compatible. GPLv3 and AGPLv3 are compatible because
of clause 13 in both licenses. See
[http://en.wikipedia.org/wiki/Affero_General_Public_License#C...](http://en.wikipedia.org/wiki/Affero_General_Public_License#Compatibility_with_the_GPL)
for more details.

~~~
chimeracoder
Ah, I didn't realize that the project was released under the GPLv3 instead of
GPLv2.

------
ivix
Developers take note: License with AGPL at your peril, or rather at the peril
of your product, which most people will not touch if it is AGPL licensed.

~~~
naner
On the HN frontpage not far from this thread, there is a story about 10gen
raising $42M with their AGPL licensed MongoDB.

~~~
protomyth
from the MongoDB licensing page:
<http://www.mongodb.org/display/DOCS/Licensing>

"The goal of the server license is to require that enhancements to MongoDB be
released to the community. Traditional GPL often does not achieve this anymore
as a huge amount of software runs in the cloud. For example, Google has no
obligation to release their improvements to the MySQL kernel – if they do they
are being nice.

To make the above practical, we promise that your client application which
uses the database is a separate work. To facilitate this, the mongodb.org
supported drivers (the part you link with your application) are released under
Apache license, which is copyleft free. Note: if you would like a signed
letter asserting the above promise please request via email."

On the the other hand Opa's statement was "And because of the latter, every
program written in Opa, that links to the runtime, must itself be released
under the AGPL or the GPL."

Very different scenarios for developers.

~~~
naner
I was just indicating that "License with AGPL at your peril" is an
overreaction.

------
ArtB
What is the difference between LGPL and GPL with the classpath exception?

------
TazeTSchnitzel
Why not LGPL?

~~~
dalke
Most likely for reasons described in <http://www.gnu.org/philosophy/why-not-
lgpl.html> .

