[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-mediagoblin] Templates, CSS, Images, JS, licensing

From: Brett Smith
Subject: Re: [Social-mediagoblin] Templates, CSS, Images, JS, licensing
Date: Wed, 13 Apr 2011 22:02:55 -0400

On Wed, 2011-04-13 at 17:48 -0500, Christopher Allan Webber wrote:
>  - *Javascript:* Presumably it makes sense for this to be AGPL also?

Yes.  AGPLing Javascript is fine and generally keeping your licensing
situation as simple as possible is more important than picking The Most
Ideal License for every single piece.

>     Unless for some reason if it normal GPL makes sense, but it's
>     probably sane enough to stick with one *GPL, and private
>     modifications to javascript honestly aren't much of a concern.
>     (Excepting maybe greasemonkey scripts.)

I don't think even those would be a concern.  The AGPL's special
condition only kicks in if the software as modified interacts with a
user over a network.  Just sending HTTP requests to a server isn't going
to trigger it.  A Greasemonkey script that met the criteria would be...
quite exceptional.

>  - *CSS & images/assets:* My thoughts are that I'd prefer that
>     MediaGoblin ship with a really basic, very configurable base css and
>     images/assets.  I've thought that these should be CC BY (3.0
>     unported). will probably run a fancier, nicer
>     looking theme, and that might be CC BY-SA 3.0.

That all sounds fine to me.

>  - *Templates:* Maybe a bit trickier, because technically these contain
>     logic and thus would all under the AGPL.  If we want also people to
>     be able to configure the templates to be something else, we'd
>     probably have to do two things:
>      - explicitly declare in the codebase that there's an HTML exception

This may or may not be true depending on how the template logic
interacts with the rest of the code.  Is there simple example template
source to look at somewhere yet?  That would probably make it pretty
easy to tell.

>      - maybe license the templates under something like MIT / Apache?

This is the recommendation in the GPL FAQ, not because it's necessary to
accomplish the goal (of keeping the licensing of output pages
hassle-free), but because copylefting templates rarely seems worthwhile.
If you think your templates are heavyweight enough to be worth
copylefting, though, it's fair to consider.

>     There's this example with javascript, but the directionality here is
>     you put this in your javascript so as to not necessarily have to
>     have your HTML be GPL compliant:
>     Our situation is a bit different.  We want our *templates* to be
>     more liberally licensed, and not be bound to the AGPL of the
>     backend's python codebase.  In the equivalence of the above
>     description, our python code is the equivalent of that javascript
>     code.  Do we need to include in the header of *all* python files
>     that this is the case?  In the README.txt/COPYING.txt (w/ a separate
>     AGPLv3.txt or etc)?

For consistency and the avoidance of doubt, it would probably be best to
have an additional permission cover all of the Python, yes.  Some large
GNU projects like GCC have had to add substantial additional permissions
to their terms.  What they've been doing is keeping those permissions in
a separate file (COPYING.EXCEPTION or something) and then adding a
sentence to the standard license header pointing people there and saying
those apply too.  If your additional permission is brief -- three
sentences or less, I'd reckon -- you might as well just add it to the
headers, though.

>     I'm not totally against the templates being under the AGPL, maybe
>     CSS modifications is just "good enough" for many peoples'
>     customization needs, but I actually doubt it.  I'm still inclined to
>     believe we should make an AGPL exception for templates.

I'm inclined to agree.  GCC *could* require people to release their
software under the GPL, because GCC's output includes little bits of
GPLed code it puts in there.  But that's not the policy they follow,
because it would drive a lot of users and potential contributors away
for some extremely marginal benefit to free software generally.  I think
this is analogous.

Best regards,

Brett Smith

reply via email to

[Prev in Thread] Current Thread [Next in Thread]