Frog CMS

I’ll make a stab at this one, Antoine, although I’m not the most knowledgeable about license types/implications!

As I understand it, what is AGPL’ed is the source code, and these are the files that include the AGPL License “header”, like this:

/**
   Frog CMS - Content Management Simplified. <http://www.madebyfrog.com>
   Copyright (C) 2008 Philippe Archambault <philippe.archambault@gmail.com>

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU Affero General Public License as
   published by the Free Software Foundation, either version 3 of the
   License, or (at your option) any later version.

   Bladibladiblah....

What you are producing using Frog CMS is not part of its code base. The license on your site is no more part of AGPL than the copyright of a book I write using MS Word is governed by its license terms.

Should you alter the source code of Frog, the license stipulates that your code must be released under the same license terms.

I think I have that right — but I am open to correction!

There is a nice explanation of AGPL 3.0 that I found helpful, although obviously it is one person’s take on things. My understanding is that Paragraph 13 is the specifically “Affero” bit, which pertains to software over networks. The Wikipedia AGPL page is worth a look too.

It would be good to hear from some of our Frog-using Web-pro’s, but in the meanwhile, I hope that helps.

One last ;) thing. You can check this thread and see the last two posts. They come from the core developer (mvdkleijn) and the project owner (philippe) respectively, and the interpretation there looks like the one I’m offering here!

@tuupola

Let’s do this the other way around then… lets assume here that neither AGPL nor (L)GPL are valid options. What do you suggest as an alternative?

For me, the MIT and especially the BSD licenses are unacceptable. They would allow anyone (including companies) to

• copy the source code
• rebrand it
• remove any links to the original and its authors
• then sell it as their own (closed-source) product.
  (unless I misunderstand the BSD license)

That to me personally is not acceptable.

There is reason why successfull projects (including Radiant) are MIT / BSD licensed. They give freedom to programmer to do they want.

All your points are true except this:

• remove any links to the original and its authors

MIT nor BSD license do not allow this. Frog is actually violating Radiant’s MIT licensed code by removing the copyright notes of original author. MIT license allows you to relicense to some other license but not remove the original copyright.

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Looking at code most of Frog admin JavaScript code is taken from Radiant. License is changed from MIT to AGPL (which is legal). Removing original authors copyright is violating MIT license.

If thinking the relationship between Radiant and Frog. What Frog has done is:

• copy the source code
• rebrand it

Copying here is debatable since it is a port. Clearly Frog is rebranded Radiant. Radiant license allows this. However Frog changing license to AGPL effectively takes away right for Radiant to take back any bugfixes / improvements made to Frog. If Radiant would take any code from Frog it would force Radiant to AGPL. This is problem of viral and restrictive licenses. Perfectly legal but feels unfair to Radiant.

If you ask my opinion which license should Frog be. I would say same as Radiant was – MIT.

To us (as web agency) AGPL is unacceptable for any larger project. Larger projects usually need customization. AGPL forces us to provide download link on website which uses customized code.

Which is a pity. Frog is the first PHP CMS I actually enjoy to use and hack. I personally have only two complaints: Prototype and license :) They should be jQuery and MIT. Then Frog would be perfect (for me).

I think most of the problems go away if plugin author can choose the license him/herself. This way you could for example make authentication plugin which works against your proprietary CRM system without being forced to present download links to your code (which might be considered a derivative work).

edit: @ricks – I’m sorry but I have to disagree. Look at it this way:

You spend hours/weeks/days in developing something with the intention of giving it away for free so people are better off. Now, a company comes along. Copies all your work and re-brands it as “Foobar CMS” for example.

They start selling it at € 1.500,- euros a piece. They never mention anything about the Open Source version. I personally wouldn’t want that.

About the JQuery thing: assuming we’re not talking about a personal preference for using JQuery instead of Prototype, I’m sure you can give a whole host of objective reasons to switch. ;-)

original post:

sigh I really wish all this sort of stuff/discussion wasn’t necessary… oh wel…

In response to this discussion, I’ve been digging into the (A)GPL license terms a little bit deeper.

Let me first see if I can’t give a reasonable summary of the problems people seem to be having with AGPL. (please correct me if I’m wrong!)

1. “I don’t want to be forced into making a site’s content or design available just because I’m using an AGPL licensed Frog CMS.”
2. “I don’t want to be forced into making a plugin that I wrote for Frog CMS available under AGPL.”

Now lets see if I can address these two points.

For the first problem: the AGPL is applicable only to the Frog CMS source code. The AGPL is not applicable to data used with the program. That means that any content you put into Frog CMS should be considered as you making use of Frog CMS. It does not mean your content now falls under the AGPL license.

A slightly more ambiguous problem is that of designs used for a Frog CMS hosted site. I personally consider a website design to fall under the category of “making use of Frog CMS”. Therefore the design would not automatically fall under the AGPL license. I must admit though that this is a bit of a grey area. (continue reading though because I think all this can be solved easily)

As for the second problem: according to the AGPL license, any plugin that was created for Frog would automatically be licensed under the AGPL. Sorry about that. :-)

However, I don’t think that was the intention of using the AGPL when Philippe switched Frog CMS to it.

Now… For a possible solution. Please keep in mind that I’m no lawyer and don’t pretend to give any form of legal advice here.

If (and I say if) I read the GPL and AGPL licenses correctly, the main difference between the two is that the AGPL forces you to make any modified version available online. That’s it.

I also seem to understand from the license texts that for both the AGPL and the GPL, we (as copyright holders to Frog CMS and license granters) have to option to waive any of the conditions.

My suggestion would then be: let us use GPL with an additional license attached to it. This additional license would grant people extra rights. Specifically, it would:

• Allow any code considered to be a “Frog plugin” to be made available under a license of the author’s choosing.
• Specifically mention that any website design, website content or code not specifically made available with the Frog CMS core releases do not fall under the main Frog CMS license.

As far as I understand the texts of the GPL this would be possible. I checked with the CreativeCommons site and came up with this page explaining the GPL in laymans terms.

“Any of the above conditions can be waived if you get permission from the copyright holder.”

My focus was on the sentence above which seems to agree with my interpretation of the license text.

What do you guys think?

If only my “private life” wasn’t intruding at the moment, I would like to participate more as the conversation unfolds.

But in brief, my sense is:

• it’s a pain to have these discussions, but better to have them and get it right
• it’s good to have these discussions, because it is a sign that Frog is “growing up” :)
• I don’t care which license is used as long as it accomplishes the intended project goals (which would include protection from commercialization of core code)
• it is important to respect the licenses of other projects’ code which Frog has used/uses/will use
• it is important to abide by the terms/conditions of our hosts, etc.
• it is important not to bind developers in the production of their own work in extending Frog (my own sense is that modifying is slightly different, and we can continue to chat about that one!)

My hunch is that Martijn has cracked it in the move from AGPL to GPL, with specific project qualifiers as he’s outlined. I believe we still need input from Philippe on this, whether on- or off-forum.

That’s a bit of a rapid post, so it should (for the moment!) be taken in the “FWIW” category.

I’m grateful for the even-tempered discussion, btw. These things can sometimes get fraught!

Tuupola,

The move away from the MIT license was undertaken by Philippe. I’m not sure what exactly his motives were.

As for the MIT/BSD vs. GPL licenses. It is a matter of perspective and philosophy I guess. You could describe the ideas behind both of them as follows (warning – oversimplified):

MIT/BSD – “We want anyone to be able to do anything with the software but we want recognition.”

(A/L)GPL – “We want anyone to be able to do anything with the software but we want recognition and we want you to share your changes back to us.”

The Creative Commons website has a nice “human readable” version of both the GPL and BSD licenses.

Sure, the GPL has the provision that your modified version of a piece of software has to have the same (GPL) license… but that’s the only way to make certain that modification are shared back to the community. If the license were to change to anything else, that “share your changes back” principle wouldn’t work anymore.

As you said, it might be our personal hangups ;-)

Anyway, getting back on topic.

1. Possible license risks.

These should be identified and stamped out immediately. Any files/source code that was copied from other sources should retain the appropriate copyright statements and such.

2. Restrictive licensing.

I (personally) wouldn’t call the GPL restrictive except for their clause about subclassed classes. We can simply override that clause by adding our own that specifies that what we consider “plugins” in Frog are exempt from the “thou shalt use GPL” clause. (i.e. you could use any license for a plugin while Frog itself was GPL)

Many companies are using, modifying and extending GPL licensed software.. so that can’t be the issue. (there’s just a lot of misinformation about the various licenses)

BTW. There are more license violations in Frog. Some helpers are taken from Code Igniter framework which is a bit modified BSD/Apache style licensed. Their license states:

1. A copy of this license agreement must be included with the distribution.

2. Redistributions of source code must retain the above copyright notice in all source code files.

3. Redistributions in binary form must reproduce the above copyright notice in the documentation and/or other materials provided with the distribution.

4. Any files that have been modified must carry notices stating the nature of the change and the names of those who changed them.

5. Products derived from the Software must include an acknowledgment that they are derived from CodeIgniter in their documentation and/or other materials provided with the distribution.

6. Products derived from the Software may not be called “CodeIgniter”, nor may “CodeIgniter” appear in their name, without prior written permission from EllisLab, Inc.

The problems:

• Email helper: Copyright changed, no mention of Code Igniter as original author.
• Upload: Copyright removed, no mention of Code Igniter as original author.
• Pagination: Copyright removed.

If Frog wants other people to play by the rules Frog should play by the rules too :)

We’ll add back the copyright statements before the release of 0.9.5! :-) (or sooner if I or David find the time)