> I think that all source files in the "plugins" directory in SVN are part of the core and should use the same license. However, 3rd party plugins made available on the wiki or through personal websites can use whatever license they want.
Part of this issue is that "addons" can't use whatever license they
want. For example, I think I understand Benny to be saying that you
can't mix GPLv2 and AGPL, so AGPL isn't currently an option. Maybe you
can use AGPL if it is cleanly separated from the rest (not sure how to
do that with all of the imports, subclassing, etc). In any event that
would be tricky. It would be easier if core gramps is GPLv3, then
there is no issue, and indeed addon authors can then use a more
protective license, if they want. (They might not be able to use
something incompatible with the GPL, but that isn't the issue here.)
>> > * allow Doug to decide now if the code in src/web is
>> AGPL v3 or sticks
>> > with the rest of GRAMPS to be GPLv3
>> I'm sensitive to Brian's point about putting undo
>> requirements for
>> those that want to run a customized gramps-connect on the
>> web. But
>> this can be done easily:
>> 1) If you want to run a customized version of
>> gramps-connect on the
>> web, start with an SVN version of gramps
>> 2) If you create a new file based on old ones: "svn add
>> 3) Produce a list of your customized changes with: "svn
>> diff >
>> 4) Put a link to that file on your gramps-connect
>> 5) You are now legit!
>> We could even put support for this in gramps-connect so
>> that it could
>> have a link, run the diff on the fly, and download it.
> The rules don't require you to show a diff of the changes you made. It only requires that you make the source code available. So, you could set up a simple script in Gramps-Connect that zips up all the .py files on the server into a package and allows the user to download it. It could even create a new archive with each new request so that the website maintainer doesn't have to generate a new one every time they make a minor change.
(Yes, that would be easier to do, but perhaps not as nice. Maybe we
could do both. But this is a detail we can work on.)
>> Note that if we stay with the status quo (GPLv2), it just
>> means that
>> people will be able to host a server without making the
>> available. Brian has said that he personally doesn't mind
>> that, but
>> that doesn't seem to be the spirit that the founding
>> fathers of gramps
> Speaking of founding fathers... I have a query out to Don to get his take on it.
>> intended. More importantly though, I don't think that is
>> what some
>> current contributors want. But they should speak up, one
>> way or
>> another, so that this decision is a voice of the gramps
> Your right, current contributors should speak up. So far, here is how I perceive the climate:
> Should we switch to GPLv3?
> Benny: YES!
> Doug: Sure.
> Brian: I'd rather not.
> My personal perception is that neither staying with GPLv2+ nor switching to GPLv3 will discourage people from contributing. You can find plenty of examples of projects on both sides that have healthy contributor communities. I think that's why a lot of projects like Wordpress don't bother switching - in the end, GPLv3 is irrelevant from a practical perspective and is mostly useful as a idealism. The project will neither suffer nor benefit from switching.
If ancestory.com (for example) started tweaking and selling the
production of someone's gramps addon reports without sources, I could
see that that would be a little discouraging to the addon author. In
light of that, GPLv3 does no harm, and only allows additional
protection from that annoyance. That isn't just an idealism, in my
Brian also said:
"As for gramps-addons, they can do whatever they want as far as I'm
concerned because that is a different project and can have it's own
Gramps-addons is still a part of the gramps community of projects, and
so we don't need to be too divisive. "They" are just a subset of us,
and we want to make sure that the community can trust the codebase to
the extent possible, and have reasonable expectations. It isn't an
"anything goes" project, but the write-privileges controls are
released a bit from the core. But that doesn't mean there needs to be
any different policy between the two projects. I guess we should have
a Gramps-addon Policy that says that it has the same policy as
Gramps-core. I can't think of anything that would or should be
We should probably look at how Firefox handles their add-ons...