-extras repo policy
Owen Winkler
extras repo.
Please review and comment:
http://wiki.habariproject.org/en/Extras_Repository
Owen
Arthus Erea
modifications.
mikelietz
licenses. Unless somebody beats me to it.
-mikelietz
Michael Harris
The licensing section of this page is likely to be contentious,
especially this: "One example exception is GPL-licensed work. While
some authorities suggest that GPLv3 is compatible with ASL, in order
to remove any ambiguity over what is allowed no plugins or themes
should be committed to the extras repository that use any version of
the GPL license."
I am in favour of disallowing GPL licensed works. I think we should
make it as clear and simple as possible for contributors to know what
can and can't be put in the -extras repo. We all know that licensing
is hard, and because it's hard most people try not to think about it.
Let's make it easy for people to not think about it, even if it means
some stuff can't be put in -extras.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari
Chris Meller
Take, for example, some of the plugins Skippy has written lately... They include GPL code and so aren't included in Extras. Just today, moeffju was on IRC wanting to fix the plugin for the new ACL changes and wasn't able to because only Skippy is able to maintain them.
Likewise, michaeltwofish earlier mentioned wanting to port some themes to Habari, but not having the desire to commit to them as the sole maintainer. Disallowing GPLv3 from Extras causes these problems.
On a less "legal" or "technical" note, I just find that it rubs me the wrong way to say "We allow ASL or ASL-compatible code... oh, except the GPL. We don't like the GPL and won't let you play in our sandbox with it."
As I've been saying in the SuperGlobals thread: educate, don't eliminate. We should explain our reasons for loving the ASL and heavily encourage users to use only it, but not eliminate GPL entirely and prevent anyone from using the thousands of libraries licensed under it in their Extras plugins. That will only stifle creativity and de-centralize our centralized repository.
And, per the GPL site, every NOTICE that ships with GPL software says it is licensed under version 2 or any higher version [2] and that v3 is ASL-compatible [3]. Just to clear that up.
[1]: http://drunkenmonkey.org/irc/habari/2008-12-03#T23-31-28
[2]: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC4
[3]: http://www.gnu.org/licenses/rms-why-gplv3.html (very end)
Bertrand Russell - "I would never die for my beliefs because I might be wrong."
Michael Harris
> As I explained on IRC [1], I don't think it's right to refuse to accept GPL
> code to the -extras repository, since the GPLv3 is compatible with the ASL.
> If we want to hold Habari core to a higher standard, that's one thing.
> Holding Extras to that higher standard doesn't make any sense and seriously
> limits its usefulness.
>
> Take, for example, some of the plugins Skippy has written lately... They
> include GPL code and so aren't included in Extras. Just today, moeffju was
> on IRC wanting to fix the plugin for the new ACL changes and wasn't able to
> because only Skippy is able to maintain them.
>
> Likewise, michaeltwofish earlier mentioned wanting to port some themes to
> Habari, but not having the desire to commit to them as the sole maintainer.
> Disallowing GPLv3 from Extras causes these problems.
Yes, and it would be great to have somewhere shared to put that stuff.
I might provide it myself if I get a chance. But there _is_ going to
be stuff we won't host in -extras, even if we allow GPLv3, so it's not
disallowing GPLv3 that's causing these problems.
> On a less "legal" or "technical" note, I just find that it rubs me the wrong
> way to say "We allow ASL or ASL-compatible code... oh, except the GPL. We
> don't like the GPL and won't let you play in our sandbox with it."
I'm not saying anything about not liking GPL. I'm not talking about
legal or technical. I'm talking about able to be comprehended at a
glance.
Chris Meller
2008/12/4 Chris Meller <ch...@doesnthaveone.com>:
> As I explained on IRC [1], I don't think it's right to refuse to accept GPLYes, and it would be great to have somewhere shared to put that stuff.
> code to the -extras repository, since the GPLv3 is compatible with the ASL.
> If we want to hold Habari core to a higher standard, that's one thing.
> Holding Extras to that higher standard doesn't make any sense and seriously
> limits its usefulness.
>
> Take, for example, some of the plugins Skippy has written lately... They
> include GPL code and so aren't included in Extras. Just today, moeffju was
> on IRC wanting to fix the plugin for the new ACL changes and wasn't able to
> because only Skippy is able to maintain them.
>
> Likewise, michaeltwofish earlier mentioned wanting to port some themes to
> Habari, but not having the desire to commit to them as the sole maintainer.
> Disallowing GPLv3 from Extras causes these problems.
I might provide it myself if I get a chance. But there _is_ going to
be stuff we won't host in -extras, even if we allow GPLv3, so it's not
disallowing GPLv3 that's causing these problems.
Such as? I can't think of a single thing that we'd not want to include. Even if there were, that has nothing to do with splitting ASL-compatible hairs on licensing.
Also as I said on IRC, providing a separate location to house only GPL content is a stupid idea all the way around. It's an incredibly arbitrary line drawn more than doubling the management complexity. Not only are there now two "extras" repos, but we have to keep up with which plugins are in which repo, enforcing the rules for each, and handle moving plugins between the two.
One repo, looser rules. There's no reason to exclude GPL, save a "spiritual" one.
I'm not saying anything about not liking GPL. I'm not talking about
> On a less "legal" or "technical" note, I just find that it rubs me the wrong
> way to say "We allow ASL or ASL-compatible code... oh, except the GPL. We
> don't like the GPL and won't let you play in our sandbox with it."
legal or technical. I'm talking about able to be comprehended at a
glance.
I still think it's very clear. If it's in Extras, it's ASL-compatible. What more do you need to know?
It's up to the person putting it in Extras to determine if it's GPL or any other ASL-compatible license (or an incompatible license), just as if we only included ASL-licensed content. There shouldn't be any additional "overhead", and we've eliminated the "why not GPL?" question.
rick c
were at an end, but evidently not.
On Dec 3, 7:14 pm, "Chris Meller" <ch...@doesnthaveone.com> wrote:
> As I explained on IRC [1], I don't think it's right to refuse to accept GPL
> code to the -extras repository, since the GPLv3 is compatible with the ASL.
> If we want to hold Habari core to a higher standard, that's one thing.
> Holding Extras to that higher standard doesn't make any sense and seriously
> limits its usefulness.
>
> Take, for example, some of the plugins Skippy has written lately... They
> include GPL code and so aren't included in Extras. Just today, moeffju was
> on IRC wanting to fix the plugin for the new ACL changes and wasn't able to
> because only Skippy is able to maintain them.
>
> Likewise, michaeltwofish earlier mentioned wanting to port some themes to
> Habari, but not having the desire to commit to them as the sole maintainer.
> Disallowing GPLv3 from Extras causes these problems.
>
> On a less "legal" or "technical" note, I just find that it rubs me the wrong
> way to say "We allow ASL or ASL-compatible code... oh, except the GPL. We
> don't like the GPL and won't let you play in our sandbox with it."
>
the GPL does say it "won't let you play in our sandbox" regarding
other licenses. If any part of a piece of software uses GPL, my
understanding is that the entire piece of software has to be licensed
under the GPL. To quote from your third reference.
"..both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If
you include code under this license in a larger program, the larger
program must be under this license too.”
I would hardly call that playing well with others.
Further, the ASF position is to specifically disallow inclusion of
code in Apache products which uses any version of the GPL or LGPL
license ( http://www.apache.org/legal/resolved.html ). If the ASF
doesn't feel comfortable using GPL or LGPL code in ASL projects, I'd
feel more comfortable if we didn't do so either, even though your
third reference says the GPL3 is compatible with the ASL. There is
obviously a disconnect between the two parties.
GPL software has it's place, but providing server space for it would,
in my opinion, be counterproductive to encouraging people to use the
ASL.
I agree with Michael that simplicity and clarity have a lot going for
them. The ambiguity surrounding the compatibility between the GPL3/
LGPL and the ASL has engendered way too much discussion, enough to
show the situation isn't as clear as you may think. If the two primary
parties ever agree, inclusion of GPL/LGPL works may be worth
revisiting, but for now the lack of clarity is enough to warrant not
allowing them.
Rick
> As I've been saying in the SuperGlobals thread: educate, don't eliminate. We
> should explain our reasons for loving the ASL and heavily encourage users to
> use only it, but not eliminate GPL entirely and prevent anyone from using
> the thousands of libraries licensed under it in their Extras plugins. That
> will only stifle creativity and de-centralize our centralized repository.
>
> And, per the GPL site, every NOTICE that ships with GPL software says it is
> licensed under version 2 or any higher version [2] and that v3 is
> ASL-compatible [3]. Just to clear that up.
>
> [1]:http://drunkenmonkey.org/irc/habari/2008-12-03#T23-31-28
> [2]:http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC4
>
> On Wed, Dec 3, 2008 at 7:00 PM, Michael Harris <michael.twof...@gmail.com>wrote:
>
>
>
>
>
> > 2008/12/4 Owen Winkler <epit...@gmail.com>:
Michael Harris
>
> On Wed, Dec 3, 2008 at 7:29 PM, Michael Harris wrote:
>>
>> Yes, and it would be great to have somewhere shared to put that stuff.
>> I might provide it myself if I get a chance. But there _is_ going to
>> be stuff we won't host in -extras, even if we allow GPLv3, so it's not
>> disallowing GPLv3 that's causing these problems.
>
> Such as? I can't think of a single thing that we'd not want to include. Even
> if there were, that has nothing to do with splitting ASL-compatible hairs on
> licensing.
Such as other non-ASL-compatible licenses.
> Also as I said on IRC, providing a separate location to house only GPL
> content is a stupid idea all the way around. It's an incredibly arbitrary
> line drawn more than doubling the management complexity. Not only are there
> now two "extras" repos, but we have to keep up with which plugins are in
> which repo, enforcing the rules for each, and handle moving plugins between
> the two.
>
> One repo, looser rules. There's no reason to exclude GPL, save a "spiritual"
> one.
I actually didn't suggest that the "other place" be managed by the community.
>> I'm not saying anything about not liking GPL. I'm not talking about
>> legal or technical. I'm talking about able to be comprehended at a
>> glance.
>
> I still think it's very clear. If it's in Extras, it's ASL-compatible. What
> more do you need to know?
>
> It's up to the person putting it in Extras to determine if it's GPL or any
> other ASL-compatible license (or an incompatible license), just as if we
> only included ASL-licensed content. There shouldn't be any additional
> "overhead", and we've eliminated the "why not GPL?" question.
GPLv2 stuff isn't ASL compatible, right ? So I can't just take a GPLv2
theme, port it, and put it in -extras. If GPLv3 is ASL compatible, I
can change the theme and re-license it using GPLv3, then put it in
-extras.
This is exactly what I mean. That doesn't seem particularly
straightforward to me, and it certainly doesn't pass the "at a glance"
test.
Chris Meller
> On Wed, Dec 3, 2008 at 7:29 PM, Michael Harris wrote:Such as other non-ASL-compatible licenses.
>>
>> Yes, and it would be great to have somewhere shared to put that stuff.
>> I might provide it myself if I get a chance. But there _is_ going to
>> be stuff we won't host in -extras, even if we allow GPLv3, so it's not
>> disallowing GPLv3 that's causing these problems.
>
> Such as? I can't think of a single thing that we'd not want to include. Even
> if there were, that has nothing to do with splitting ASL-compatible hairs on
> licensing.
I actually didn't suggest that the "other place" be managed by the community.
> Also as I said on IRC, providing a separate location to house only GPL
> content is a stupid idea all the way around. It's an incredibly arbitrary
> line drawn more than doubling the management complexity. Not only are there
> now two "extras" repos, but we have to keep up with which plugins are in
> which repo, enforcing the rules for each, and handle moving plugins between
> the two.
>
> One repo, looser rules. There's no reason to exclude GPL, save a "spiritual"
> one.
GPLv2 stuff isn't ASL compatible, right ? So I can't just take a GPLv2
>> I'm not saying anything about not liking GPL. I'm not talking about
>> legal or technical. I'm talking about able to be comprehended at a
>> glance.
>
> I still think it's very clear. If it's in Extras, it's ASL-compatible. What
> more do you need to know?
>
> It's up to the person putting it in Extras to determine if it's GPL or any
> other ASL-compatible license (or an incompatible license), just as if we
> only included ASL-licensed content. There shouldn't be any additional
> "overhead", and we've eliminated the "why not GPL?" question.
theme, port it, and put it in -extras. If GPLv3 is ASL compatible, I
can change the theme and re-license it using GPLv3, then put it in
-extras.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This is exactly what I mean. That doesn't seem particularly
straightforward to me, and it certainly doesn't pass the "at a glance"
test.
Chris Meller
Thank you for the page, Owen. I had hoped the licensing discussions
were at an end, but evidently not.
I'll willingly say I don't like the GPL.
On Dec 3, 7:14 pm, "Chris Meller" <ch...@doesnthaveone.com> wrote:
> As I explained on IRC [1], I don't think it's right to refuse to accept GPL
> code to the -extras repository, since the GPLv3 is compatible with the ASL.
> If we want to hold Habari core to a higher standard, that's one thing.
> Holding Extras to that higher standard doesn't make any sense and seriously
> limits its usefulness.
>
> Take, for example, some of the plugins Skippy has written lately... They
> include GPL code and so aren't included in Extras. Just today, moeffju was
> on IRC wanting to fix the plugin for the new ACL changes and wasn't able to
> because only Skippy is able to maintain them.
>
> Likewise, michaeltwofish earlier mentioned wanting to port some themes to
> Habari, but not having the desire to commit to them as the sole maintainer.
> Disallowing GPLv3 from Extras causes these problems.
>
> On a less "legal" or "technical" note, I just find that it rubs me the wrong
> way to say "We allow ASL or ASL-compatible code... oh, except the GPL. We
> don't like the GPL and won't let you play in our sandbox with it."
>
Part of the problem is that
the GPL does say it "won't let you play in our sandbox" regarding
other licenses. If any part of a piece of software uses GPL, my
understanding is that the entire piece of software has to be licensed
under the GPL. To quote from your third reference.
"..both GPLv2 and GPLv3 are copyleft licenses: each of them says, "If
you include code under this license in a larger program, the larger
program must be under this license too."
I would hardly call that playing well with others.
Further, the ASF position is to specifically disallow inclusion of
code in Apache products which uses any version of the GPL or LGPL
license ( http://www.apache.org/legal/resolved.html ). If the ASF
doesn't feel comfortable using GPL or LGPL code in ASL projects, I'd
feel more comfortable if we didn't do so either, even though your
third reference says the GPL3 is compatible with the ASL. There is
obviously a disconnect between the two parties.
GPL software has it's place, but providing server space for it would,
in my opinion, be counterproductive to encouraging people to use the
ASL.
I agree with Michael that simplicity and clarity have a lot going for
them. The ambiguity surrounding the compatibility between the GPL3/
LGPL and the ASL has engendered way too much discussion, enough to
show the situation isn't as clear as you may think.
If the two primary
parties ever agree, inclusion of GPL/LGPL works may be worth
revisiting, but for now the lack of clarity is enough to warrant not
allowing them.
Owen Winkler
think there are a couple of points of fact to be made.
Michael Harris wrote:
>
> GPLv2 stuff isn't ASL compatible, right ? So I can't just take a GPLv2
> theme, port it, and put it in -extras. If GPLv3 is ASL compatible, I
> can change the theme and re-license it using GPLv3, then put it in
> -extras.
From what I'm reading, it's possible to take a GPL v2 product and
release it under a v3 license. This means that you could take any
theme, port it, and release it under GPL v3. Unfortunately, this would
do nothing for you.
While ASL is compatible with GPL v3, the reverse is not true. Consider:
http://www.fsf.org/licensing/licenses/compat.html
"A license p is compatible with a license q (or is q-compatible) if:
A work licensed under p can be distributed under the terms of q."
A work licensed under ASL can easily be distributed under the terms of
GPL v3, because the ASL is less restrictive. See GPLv3 section 5c:
http://www.gnu.org/licenses/gpl-3.0.html
No similar clause exists in the ASL 2.0.
Please review this diagram:
http://www.dwheeler.com/essays/floss-license-slide.html
"In this figure, the shaded boxes are the names of different FLOSS
licenses. An arrow from box A to box B means that you can combine
software with these licenses; the combined result effectively has the
license of B, possibly with additions from A."
So in converse, GPL is not compatible with ASL at all. You could not
distribute GPL code under the terms of ASL, because the ASL does not
require that derivative works be licensed as anything in specific.
In terms of how this affects Habari, as the baseball metaphor I
mentioned on the wiki page, consider the extras repo a farm team for the
core software offering. There is no occasion whatsoever when
GPL-licensed code would be brought into the majors.
So while it's true that the ASL is GPL-compatible, the restriction for
the repo is that contributions be ASL-compatible. Since no GPL
contributions would be ASL-compatible, it's fairly clear that they are
restricted from submission.
Also, I would remind participants in this thread that the purpose of the
extras repo is not to house every plugin or to have a central location
where plugins are hosted. The extras repo serves two purposes only:
1) Serve as a place to develop plugins and themes with public
participation to sound out whether either a contribution or a developer
is worthy of promotion to core or PMC, respectively.
2) Allow developers interested in contributing to Habari to house their
code and issue tracking at no cost to them.
There will always be people who do not use the extras repo. Even I have
plugins that are not in the extras repo for one reason or another. For
these people, a central distribution system is paramount, not a central
code repository. We have always had other plans for that, and no intent
to exclude any contribution from this distribution directory based on
license.
I think it does come down to a question of promoting our project's
ideals. That we draw a line is an important component in Habari's
reason for being. I do not believe it's worthwhile to devote our
resources to hosting code that is essentially contrary to our project's
ideals.
Even if GPL was somehow ASL-compatible, I believe it's perfectly
acceptable to say that we don't want it here based on what properties it
conveys, specifically in that it removes rights from the people whose
effort built the software. Those are not the principles upon which this
project was built.
Owen
Michael Harris
>>
> On Wed, Dec 3, 2008 at 9:45 PM, Michael Harris wrote:
>>
>> 2008/12/4 Chris Meller <ch...@doesnthaveone.com>:
>> >
>> > On Wed, Dec 3, 2008 at 7:29 PM, Michael Harris wrote:
>
> That still doesn't make it less confusing or annoying to users looking for
> plugins. 99% of them don't care in the slightest how it's licensed, they
> just want a convenient go-to location to find them. Don't screw the users
> because we're holier than the GPL. We want Extras to be the de facto
> location for Habari plugins. Excluding the GPL shoots that goal in the foot
> and only invites frustration and confusion.
So you're saying get rid of ASL compatibility for -extras completely ?
Because if you're _not_ suggesting that, then my understanding is
that, as I said, there are other non-ASL-compatible things that we
wouldn't put in -extras, and hence the potential problem of different
repositories already exists.
>> GPLv2 stuff isn't ASL compatible, right ? So I can't just take a GPLv2
>> theme, port it, and put it in -extras. If GPLv3 is ASL compatible, I
>> can change the theme and re-license it using GPLv3, then put it in
>> -extras.
>
> Yes, you can. Read my references. From the NOTICE file that, in order to use
> the GPL, you must include in every package:
>
> This program is free software; you can redistribute it and/or
> modify it under the terms of the GNU General Public License
> as published by the Free Software Foundation; either version 2
> of the License, or (at your option) any later version.
I did read your reference. I've read it before too. That suggests to
me that I can use a later version of the GPL, and that to put it in
-extras I need to re-license the software as GPLv3, because GPLv2
isn't ASL-compatible. If you're suggesting we dump ASL-compatibility
for -extras, then you can obviously ignore this.
> I don't know how you can make it much more straightforward.
> And from what perspective are you looking at this? From a user perspective,
> who cares? If anything, it's in Extras and is ASL-compatible so you're happy
> because it can't be too bad. From the developer perspective it's GPL so
> you're still good.
I'm talking from a developer perspective. I don't see "it's GPL so
you're still good," as I've explained above.
>> This is exactly what I mean. That doesn't seem particularly
>> straightforward to me, and it certainly doesn't pass the "at a glance"
>> test.
>
> Seems pretty straightforward to me. It's not backwards compatible, but
> you're free to upgrade at any time with or without a reason. I can pretend
> version 2 never existed and use version 3 for everything...
How can you pretend v2 never existed ? If I'm using a library that's
v2, or porting a theme, I have to make the decision to change the
license to v3 to put it in -extras. I have to understand enough about
licensing to know that I have to make the change.
I'm quite happy to be convinced that I'm completely wrong on this and
that it is simple, but you haven't managed that yet.
Michael Harris
>
> There *is* no lack of clarity. I suspect anyone who thinks there is of being
> totally illiterate.
Come on, ad hominem attacks don't move the debate forward at all.
Chris Meller
> There *is* no lack of clarity. I suspect anyone who thinks there is of beingCome on, ad hominem attacks don't move the debate forward at all.
> totally illiterate.
Arthus Erea
Chris J. Davis
participation to sound out whether either a contribution or a developer
is worthy of promotion to core or PMC, respectively.
2) Allow developers interested in contributing to Habari to house their
code and issue tracking at no cost to them.
Chris Meller
Chris J. Davis
Chris Meller
From reading this whole thread, I see this problem as one of purpose, not license.
So, I vote +1 for -extras being a repo that houses any plugin/class/theme that is built for Habari regardless of license. In our intro to -extras we explain the benefits of licensing your work under the ASL (possible inclusion in core, etc) but in no way mandate it.
Ali B.
The repo would be handy in providing a centralized hosting for all plugins in the next-to-come directory. And since we are not redistributing any ASL code with GPL code, there is no violation of any kind even if they are not compatible.
Owen Winkler
>
> For the record I am in favor of option 1. We need a centralized location
> for plugins and themes, and providing that for the community is a good
> thing, and serves our participation model.
The plugin and theme directory is a fine place to centralize
distribution, and may link to GPL-licensed projects and code that is
off-site.
Our participation model only works for us if our contributors are
submitting code that can be used in our project. If only for this
reason and none of the myriad of others, the repositories that our
project maintains should only house ASL-compatible code.
-1 for leaving our repository open to include potentially tainting code.
Owen
Chris Meller
The plugin and theme directory is a fine place to centralize
Chris J. Davis wrote:
>
> For the record I am in favor of option 1. We need a centralized location
> for plugins and themes, and providing that for the community is a good
> thing, and serves our participation model.
distribution, and may link to GPL-licensed projects and code that is
off-site.
Our participation model only works for us if our contributors are
submitting code that can be used in our project. If only for this
reason and none of the myriad of others, the repositories that our
project maintains should only house ASL-compatible code.
I believe that's what we're voting for. Allowing any ASL-compatible code in Extras.
-1 for leaving our repository open to include potentially tainting code.
Does "tainting" include GPLv3?
Arthus Erea
The goal of the repository should be twofold:
1) provide a central venue for communal development
2) facilitate introduction of developers to the Habari and allow them
to prove their worth
The Habari community and project have officially endorsed ASL as its
license of choice. By allowing communal development (1) under a
different license, we are in conflict with that choice. Additionally,
allowing GPL code could potentially make things more difficult if we
want to integrate it as a core plugin. Additionally, we should be
introducing developers to the ASL as part of (2).
However, we definitely should have a distribution directory which
allows any and all plugins/themes. The function of this directory is
to point people to Habari plugins, which does not conflict with
pointing people to GPL plugins.
~Arthus
Owen Winkler
>
>
> I believe that's what we're voting for. Allowing any ASL-compatible code
> in Extras.
No.
A +1 vote is to allow GPL-compatible code in the repo.
A -1 vote is to allow only ASL-compatible code in the repo.
GPL code is by nature not ASL-compatible. (Not to be confused with ASL
code being GPL-compatible, which it is.)
Owen
Sean Coates
> 3rd, 10:01 CDT.
From what I understand, php.net has had to deal with this exact
problem (GPLed extensions are not allowed in PECL as a result). Rasmus
has had to waste a lot of his time fighting off the FSF because of old
GPL extensions that have since been expunged.
I emailed him to ask his opinion on this matter. He's a busy guy, but
he's genuinely helpful whenever possible. I do expect to hear
_something_ back from him, but I'm not sure how long it will take.
It seems to me that we could learn a lot from his advice if he's
willing to share it.
Therefore, I think that a rushed vote (48h) might be too quick in this
case.
Then again, I'm new, and I don't know how these things work (-:
S
Chris J. Davis
process.
And to clarify, this is a vote as to the purpose of -extras. Don't
vote for licenses, vote for purpose.
Chris
Michael Bishop
extras repo to be made once and for all, and despite my attempts to
grasp the nuances of how GPL code relates to the Apache License, I'm
still not sure, and would love to have someone who's actually dealt
with the issue on such a scale weigh in on the topic. in what ever
fashion.
I know the arguments about letting things linger not being a good
thing, but this has gone on this long, and I for one would be all for
giving it more time so we can get the most accurate information and
input from someone who's had experience with the issue.
In summary, I'm reserving a vote in the hopes we can keep a civil
discourse on the subject going long enough to get the feed back Sean
has solicited.
~miklb
Michael Harris
> 1) Serve as a place to develop plugins and themes with public
> participation to sound out whether either a contribution or a developer
> is worthy of promotion to core or PMC, respectively.
>
> 2) Allow developers interested in contributing to Habari to house their
> code and issue tracking at no cost to them.
> Then we should be requiring all code submitted to it to be licensed under
> the ASL.
[snip]
> So, since it seems we have a difference of opinion on what -extras is, I
> call for a vote on the purpose of -extras. After we determine what it should
> be, we can clarify any license statements.
> So, I vote +1 for -extras being a repo that houses any plugin/class/theme
> that is built for Habari regardless of license. In our intro to -extras we
> explain the benefits of licensing your work under the ASL (possible
> inclusion in core, etc) but in no way mandate it.
> I call for 48 hours of voting on this subject from now, December 3rd, 10:01
> CDT.
To be clear, a +1 is a vote to remove any ASL requirement for -extras.
-1.
Non-ASL plugins will still be distributable when we have a plugin
distribution system.
Matthias Bauer
> Take, for example, some of the plugins Skippy has written lately... They
> include GPL code and so aren't included in Extras. Just today, moeffju
> was on IRC wanting to fix the plugin for the new ACL changes and wasn't
> able to because only Skippy is able to maintain them.
I was talking about the Persistence of Memory Plugin which is
AL2-licensed, it's just not in -extras yet. I did fix the plugin and
sent skippy the patch.
-Matt
Matthias Bauer
> And, per the GPL site, every NOTICE that ships with GPL software says it
> is licensed under version 2 or any higher version [2] and that v3 is
> ASL-compatible [3]. Just to clear that up.
>
> [1]: http://drunkenmonkey.org/irc/habari/2008-12-03#T23-31-28
> [2]: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC4
> [3]: http://www.gnu.org/licenses/rms-why-gplv3.html (very end)
Oh, and: That's only in the default notice. It's not mandatory to
automatically license under all later versions, and a number of people
and projects have dropped the "any higher version" clause.
-Matt
Matthias Bauer
> What is the purpose of -extras?
>
> If its purpose is to be the premiere place for plugins, themes and
> classes from the Habari community, for the Habari community, then we
> need to only have one license restriction:
>
> A recognized FOSS license.
>
> If this is to be a place as Owen put it:
>
> 1) Serve as a place to develop plugins and themes with public
> participation to sound out whether either a contribution or a developer
> is worthy of promotion to core or PMC, respectively.
>
> 2) Allow developers interested in contributing to Habari to house their
> code and issue tracking at no cost to them.
>
> Then we should be requiring all code submitted to it to be licensed
> under the ASL.
> So, since it seems we have a difference of opinion on what -extras is, I
> call for a vote on the purpose of -extras. After we determine what it
> should be, we can clarify any license statements.
>
> So, I vote +1 for -extras being a repo that houses any
> plugin/class/theme that is built for Habari regardless of license. In
> our intro to -extras we explain the benefits of licensing your work
> under the ASL (possible inclusion in core, etc) but in no way mandate it.
>
> I call for 48 hours of voting on this subject from now, December 3rd,
> 10:01 CDT.
I don't want to risk tainting the AL2 code with GPL fragments, and I
think that risk increases the closer together we bring differently
licensed source code. There might also be license technicalities like "I
can checkout the whole -extras repo, so you distribute code under the
GPL, so it all has to be GPL". I believe our repositories should house
only Apache 2.0 licensed code.
-1 for allowing other licenses.
-Matt
Matthias Bauer
> -1 for allowing other licenses.
Ok, let me clarify:
-1 on the original vote of making -extras general repo; thus: +1 on
allowing only ASL or ASL-compatible code.
-Matt
mikelietz
habari-extras
Let me say up front that -extras is not, in its current form, ideal.
I'd add to that the notion that a community-blessed plugins directory/
distribution site is needed ASAP.
To my understanding -extras is not meant to be a central storage and
distribution site for the majority of Habari plugins; it just happens
to be the largest collection of them (and /dist being the best place
to get plugins that run on versions newer than release).
It's a great place to store plugin code - I've added my own there for
many reasons, not the least of which is that if I drop the ball on a
bug or necessary update, it's more than likely that somebody else will
update and commit, and more people would see it there than on my site.
But I digress. In its address is 'habariproject.org' and that, to a
quick glance, makes it appear to be official Habari code and as such
would be subject to the Habari license (and its associated
compatibilities and whatnot). Again, this is purely at a quick glance
and I'm sure there are lots of counter examples, but I think that a
project's license should extend to all parts of it. I'm not saying
people can't code with whatever license they want to use, I'm just
saying that if they want said code to appear on -extras, they should
follow the established guidelines. Otherwise they can use other
repositories and storage, as many people already do.
My understanding of licenses is less than complete, and my opinion of
the GPL for themers and plugin developers is less than positive, but
I'm not voting against the GPL or any version of it. I'm voting
against compromising the licensing of Habari, and/or giving the
appearance of compromising it.
So what next? We need a directory/distribution site for themes and
plugins of all licenses. That could be part of hp.o, but it doesn't
have to be. It just needs to exist. A license-blind third party
repository would be great, too. But let's hold -extras up to the same
standards as the rest of the code you can get from
svn.habariproject.org (and having said that, I need to add some
documentation to my plugins if somebody else hasn't yet).
-mikelietz
Sean T Evans
Hash: SHA1
I'm voting -1
My logic is as follows. -extras is specifically set up to allow
community maintained development to proceed. In addition to housing
plugins/themes that the original developer (and thus license assigner)
have no involvement in (thereby forcing later community maintainers to
operate under a license they may have issues with), it's also a place
for developers who are still learning to work within the safety net that
the community can provide. Allowing multiple licenses, some of which
cannot be incorporated into others, we add a significant burden to our
developers.
If the -extras repository is to be community maintained, the members of
the community should not have to do a license review every time they
work on a ticket. Additionally, because we keep the entry requirements
for -extras so low, it benefits the people supporting newer developers
to not have to say "plugin x does something similar, but you can't use
that because plugin y that you're working on is a different license.
When (hopefully soon?) we get our plugin and theme directories up and
running, we should be much more license agnostic, but on our own
servers, we are justified in being more picky. To torture an analogy,
my friends may drink MGD, but I'm not going to keep it in my fridge for
them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJN/LumQpMBUWJpdsRAlFCAKDHhDY4+nHwnbsl1yk9qp2ScSJzBACg0wIG
pIR3yegwSwilURjAG5Cy1e8=
=v3NH
-----END PGP SIGNATURE-----
Christian Mohn (h0bbel)
Michael Bishop
On Dec 4, 9:53 am, mikelietz <cod...@gmail.com> wrote:
> But I digress. In its address is 'habariproject.org' and that, to a
> quick glance, makes it appear to be official Habari code and as such
> would be subject to the Habari license (and its associated
> compatibilities and whatnot). Again, this is purely at a quick glance
> and I'm sure there are lots of counter examples, but I think that a
> project's license should extend to all parts of it. I'm not saying
> people can't code with whatever license they want to use, I'm just
> saying that if they want said code to appear on -extras, they should
> follow the established guidelines. Otherwise they can use other
> repositories and storage, as many people already do.
>
also give extra's committers access to branches. If they aren't fully
cognizant of our licensing were we to allow any license in extras,
they may not know they can't use certain licensed code in a branch,
which would make our life even more difficult in reviewing code.
I understand that Chris's call to a vote was not about licenses, but I
don't think that's practical under the circumstances.
If I were pressed to vote now on what I understand, I'd echo Matthias
and vote -1 on the original vote of making -extras general repo; thus:
allowing only ASL or ASL-compatible code.
hp.o so that developers that create plugins/themes that are not
compatible with our license could still list and promote their work
via our official site, so that users still could have a single place
to browse the ever growing list of plugins and themes.
~miklb
Chris Meller
Geoffrey Sneddon
On 3 Dec 2008, at 23:23, Owen Winkler wrote:
> I've written a page on the wiki detailing the policy for use of the
> extras repo.
>
> Please review and comment:
> http://wiki.habariproject.org/en/Extras_Repository
To give my very quick opinion: everything in -extras should be able to
be moved to core. This means everything must be ASL-compatible. On
those grounds, a (non-binding) -1 on allowing any code which is
inversely compatible with the ASL into -extras.
--
Geoffrey Sneddon
<http://gsnedders.com/>
Caius Durling
I've written a page on the wiki detailing the policy for use of the
extras repo.
Please review and comment:
http://wiki.habariproject.org/en/Extras_Repository
Scott Merrill
> I haven't had time to read the whole thread, but I agree with what owen has
> written up there, especially highlighting that we only accept ASL licenced
> code into -extras with the intention it could be moved to core.
> What we do need however, is a place for any plugins/themes to be submitted
> and held—but -extras is "official" stuff that has been peer-reviewed by the
> act of it being submitted and therefore can be (mostly) trusted.
> +1 on the policy Owen has penned.
I am -1 on the inclusion of GPL code in the -extras repository.
I am +1 on a strict requirement that -extras contributions must be
licenses with an ASL-compatible license; with a strong preference
shown for the actual ASL license.
Ali B.
I don't want to risk tainting the AL2 code with GPL fragments, and I
think that risk increases the closer together we bring differently
licensed source code. There might also be license technicalities like "I
can checkout the whole -extras repo, so you distribute code under the
GPL, so it all has to be GPL". I believe our repositories should house
only Apache 2.0 licensed code.
After a brief discussion with Michael and Sean about this in IRC, and reading the Matt's above quoted note, which I very much agree with and even foresee if we allow conflicting licenses in -extras, I am changing my vote to +1 for allowing only ASL-compatible code in -extras.
Michael Harris
Ali B.
Sean Coates
I would still like to hear what Rasmus has to say, if he responds.
However, unless that reveals some sort of unexpected evidence to the
contrary, I think that allowing GPL code on hp.o is dangerous at best.
None of us want a run-in with the FSF, and the risks simply aren't
worth the "reward" of allowing a broader licensing regime on hp.o.
So, my vote for now is -1 (== no GPL code on hp.o)
I do think we should expedite some sort of automated plugin system in
light of this discussion, though...
S
rick c
Even though the focus of the vote is on what the purpose of -extras
is, whether to serve as a farm club for Habari development, or to
serve as a central clearing house of all code related to Habari. I'd
rather restrict -extras to code that has been licensed with an ASL
compatible license. I do want hp.o to be a central clearing house for
all extensions related to Habari, no matter how they're licensed, but
feel this would be best served by the web-based mechanism upon which
work has started (and which I hope is publicly available soon).
Rick
Chris Meller
-1 to all all recognized FOSS licensed code in -extras.
Even though the focus of the vote is on what the purpose of -extras
is, whether to serve as a farm club for Habari development, or to
serve as a central clearing house of all code related to Habari. I'd
rather restrict -extras to code that has been licensed with an ASL
compatible license. I do want hp.o to be a central clearing house for
all extensions related to Habari, no matter how they're licensed, but
feel this would be best served by the web-based mechanism upon which
work has started (and which I hope is publicly available soon).
Blake Johnson
distribution hub, since no other distribution method currently exists.
I suppose there is some value in having an extra base of code which
can always be merged into Habari core, but I rather imagine that any
other system we create will end up being a lot like a nice graphical
interface on top of a subversion repository + social features. So, why
not build this system in -extras rather than maintaining a separate
system?
In any case, I don't have strong feelings on this issue, so my vote is
+/-0.
--Blake
On Dec 3, 11:02 pm, "Chris J. Davis" <c...@chrisjdavis.org> wrote:
>
> So, since it seems we have a difference of opinion on what -extras is,
> I call for a vote on the purpose of -extras. After we determine what
> it should be, we can clarify any license statements.
>
> So, I vote +1 for -extras being a repo that houses any plugin/class/
> theme that is built for Habari regardless of license. In our intro to -
> extras we explain the benefits of licensing your work under the ASL
> (possible inclusion in core, etc) but in no way mandate it.
>
> I call for 48 hours of voting on this subject from now, December 3rd,
> 10:01 CDT.
>
>
> Chris
>
Sean Coates
> future community developers.
I don't really want to add fuel to the fire here, but I do want to say
this...
The potential for possibly "screwing over" future users of GPL-based
plugins (although we're not actually preventing anyone with GPL code
from distributing their plugins, we're just not offering to distribute
them on their behalf) is, in my opinion, a much lesser risk than the
potential of possibly screwing over everyone who has contributed code
to Habari with the intent of it being BSD-type Free (not GPL-type
Free), if the FSF ever decides to come after us for distributing code
that arguably links only against Habari (and thus making Habari
"inherit" the GPL license). I'm with the others in saying that I don't
fully understand the implications of this, but the preamble of GPLv3
indicates that the so-called viral clause is still in play.
This is a grey area, of course. I just prefer to be more safe than
more accommodating here.
S
