Habari-extras repo is now functional, and a few questions arose
today. First, should versioning be preserved in moving from the gcode
repo?
Second, are all items in extras going to be strictly attributed to
Community, with no individual credits. Owen brought up, "It also
helps keep the license valid. If you're tracking all contributors
because of license requirements, that's a great place to do it, I
think." (This was more specifically to the notion of being able to
have more than one author credit in the plugin itself).
Finally, how will downloadable versions of the plugins/themes be made
available on hp.o. We still need to have that latest dev release as a
download, so that dove tails into the extras question.
Also how will we handle bug/enhancement tickets. Currently habari-
extras doesn't have a way to view/create tickets. Will all tickets be
handled in the main issue tracker? I'd suggest keeping them separate,
to keep the core code issues easier to monitor.
> Habari-extras repo is now functional, and a few questions arose > today. First, should versioning be preserved in moving from the gcode > repo?
I don't think it's terribly important to retain versioning on what little currently exists. If the individual authors want to do so, they should of course feel free; but I don't think it's something we should mandate.
> Second, are all items in extras going to be strictly attributed to > Community, with no individual credits. Owen brought up, "It also > helps keep the license valid. If you're tracking all contributors > because of license requirements, that's a great place to do it, I > think." (This was more specifically to the notion of being able to > have more than one author credit in the plugin itself).
I think it makes the most sense to give attribution to the community. The SVN commit log will maintain individual contributions, if that ever becomes an issue for someone. But my understanding was that anyone with commit access to -extras could conceivably make changes to anything in the -extras repository. As such, I make make gigantic changes to your theme. Should you get the public credit? Should I? By crediting "the Habari Community", we sidestep some of those power plays, and we reinforce the notion that from the community comes great stuff.
> Finally, how will downloadable versions of the plugins/themes be made > available on hp.o. We still need to have that latest dev release as a > download, so that dove tails into the extras question.
The core Habari repository can easily be made into a tarball with something like this in a post-commit hook: svn export /path/to/repo /path/to/export; cd /path/to/export; tar zcf /path/to/downloads/habari-latest.tar.gz *;
We could do the same for -extras, so that the latest version is always packaged. The real question is: should we provide individual tarballs / zipfiles for the individual components in the repository, or should we only provide a single habari-extras.tar.gz download containing everything?
> Also how will we handle bug/enhancement tickets. Currently habari- > extras doesn't have a way to view/create tickets. Will all tickets be > handled in the main issue tracker? I'd suggest keeping them separate, > to keep the core code issues easier to monitor.
We have a trac installation for -extras, I think we should use it for issue tracking. We can also use the wiki there for documentation of the individual components.
Michael Bishop wrote: > Habari-extras repo is now functional, and a few questions arose > today. First, should versioning be preserved in moving from the gcode > repo?
I think this is an all-or-nothing prospect that has already passed us by if there is revision history in the subversion database. That said, I think there isn't so much in there to be too concerned about preserving the versioning.
> Second, are all items in extras going to be strictly attributed to > Community, with no individual credits. Owen brought up, "It also > helps keep the license valid. If you're tracking all contributors > because of license requirements, that's a great place to do it, I > think." (This was more specifically to the notion of being able to > have more than one author credit in the plugin itself).
I think that it's fine if people want to attribute code to the community, but I also think that there must be a place for recognition somewhere in our project.
Granted, I agree completely with keeping names out of individual components of the core code, and I likewise concur with doing the same for contributed code (such as adding code comments that say "this line/function was added by so-and-so"). Still, copyright attribution should be maintained for the contributors, and I see no good reason why this information couldn't exist in the place that is meant to hold it - the plugin info record.
Being that the revision log will likely not distributed with the plugin, leaving the subversion log as the sole record of contribution will likely not distribute proper copyright attribution or recognition with the conventional zip or tar file as including actual names in a specific place in the plugin.
It should be up to contributors to include their own attribution information in the plugin info. If you leave that out of your commit, then you don't get it unless someone adds it for you.
Assignment of attribution is less of an issue to me than committing referral links in themes and other spurious practices against which we should have strict rules. Also, attribution is of less concern to me than stating an explicit license for the code, which should be ASL if we're keeping in our repo, with the understanding that committing code there allows community access to edit it.
> Finally, how will downloadable versions of the plugins/themes be made > available on hp.o. We still need to have that latest dev release as a > download, so that dove tails into the extras question.
A post-commit hook already is connected to the main repo to create "nightlies" (which are actually immediately in-sync with the repo) of the core distribution here: http://habariproject.org/dist/habari_head.zip
We could provide a similar functionality for plugins and themes within the repo.
There is curerntly no branching or tagging in the extras repo. Is this intentionally omitted, or was some other plan in place to deal with that?
> Also how will we handle bug/enhancement tickets. Currently habari- > extras doesn't have a way to view/create tickets. Will all tickets be > handled in the main issue tracker? I'd suggest keeping them separate, > to keep the core code issues easier to monitor.
I can edit the Trac instance to enable that feature. I think that the separate repo should have its own Trac to keep the noise level down on the main repo.
On Jan 17, 8:19 pm, Owen Winkler <epit...@gmail.com> wrote:
> Michael Bishop wrote:
> > Habari-extras repo is now functional, and a few questions arose
> > today. First, should versioning be preserved in moving from the gcode
> > repo?
> I think this is an all-or-nothing prospect that has already passed us by
> if there is revision history in the subversion database. That said, I
> think there isn't so much in there to be too concerned about preserving
> the versioning.
So it'd be safe for me to just export the contrib repo and commit to
extras? Skippy mentions "individual authors", which there are none,
they are all "Community" plugins. Which leads to the second
question... (of which I have no further for, I'll hope others chime
in. I am also not concerned personally with attribution, just think
it should be completely fleshed out now)
> Assignment of attribution is less of an issue to me than committing
> referral links in themes and other spurious practices against which we
> should have strict rules. Also, attribution is of less concern to me
> than stating an explicit license for the code, which should be ASL if
> we're keeping in our repo, with the understanding that committing code
> there allows community access to edit it.
Are you saying even extras? So if I have a theme that's based on a CC
licensed template, it can't be added?
> > Finally, how will downloadable versions of the plugins/themes be made
> > available on hp.o. We still need to have that latest dev release as a
> > download, so that dove tails into the extras question.
> A post-commit hook already is connected to the main repo to create
> "nightlies" (which are actually immediately in-sync with the repo) of
> the core distribution here: http://habariproject.org/dist/habari_head.zip
> We could provide a similar functionality for plugins and themes within
> the repo.
> There is curerntly no branching or tagging in the extras repo. Is this
> intentionally omitted, or was some other plan in place to deal with that?
That was another question I meant to ask. contrib never had branches/
tags so something would need to be put in place to accommodate
working code as well as work-in-progress.
I think individual download files should be provided. I can see the
distro growing quickly, and not everyone wants to download 50 plugins/
themes when they want/need just one. Plus, versioning might be a
problem with the single download approach.
> I can edit the Trac instance to enable that feature. I think that the
> separate repo should have its own Trac to keep the noise level down on
> the main repo.
On Thu, 2008-01-17 at 20:19 -0500, Owen Winkler wrote: > Michael Bishop wrote: > > Also how will we handle bug/enhancement tickets. Currently habari- > > extras doesn't have a way to view/create tickets. Will all tickets be > > handled in the main issue tracker? I'd suggest keeping them separate, > > to keep the core code issues easier to monitor.
> I can edit the Trac instance to enable that feature. I think that the > separate repo should have its own Trac to keep the noise level down on > the main repo.
> Owen
My fear is that by placing a strong line between plugin/theme downloading/bug tracking etc. we run the risk of relegating these things to second-class status. If we share a bug tracking system between core and plugins/themes that keeps many eyes on them, and hopefully will reduce the "real developer" vs. "plugin/theme developer" gap.
Although it would create a much more... vibrant trac system, I think from the perspective of building community, the benefit outwheighs the extra work.
The subject of licensing for -extras came up again today in IRC, so it
was suggested that it be brought up again on the mailing list.
Here are a couple thoughts that came to mind while thinking about it.
If code is credited to the community, does the Habari community then
become responsible (from a legal perspective) for making sure that the
code is licensed properly? If someone modifies a WP plugin to work
with Habari, and changes the license to something incompatible with
the original, does this open us up to liability because it's the
project's name on it?
Other than that thought, I think I'm generally in favor of allowing a
wider array of licenses if it can be done. This will give us the
ability to port more things from other platforms (ie CC-BY licensed
themes). Perhaps suggestion of requiring any license to be GPL
compatible is a good starting point.
> On Thu, 2008-01-17 at 20:19 -0500, Owen Winkler wrote:
> > Michael Bishop wrote:
> > > Also how will we handle bug/enhancement tickets. Currently habari-
> > > extras doesn't have a way to view/create tickets. Will all tickets be
> > > handled in the main issue tracker? I'd suggest keeping them separate,
> > > to keep the core code issues easier to monitor.
> > I can edit the Trac instance to enable that feature. I think that the
> > separate repo should have its own Trac to keep the noise level down on
> > the main repo.
> > Owen
> My fear is that by placing a strong line between plugin/theme
> downloading/bug tracking etc. we run the risk of relegating these things
> to second-class status. If we share a bug tracking system between core
> and plugins/themes that keeps many eyes on them, and hopefully will
> reduce the "real developer" vs. "plugin/theme developer" gap.
> Although it would create a much more... vibrant trac system, I think
> from the perspective of building community, the benefit outwheighs the
> extra work.
I think the terms for adding projects to the extras repo should be kept reasonably simple but also address the beliefs of our community. This is my opinion for what rules we should adhere to:
All plugins must be ASL2-licensed to be submitted to the repo.
This is a practical concern because alternative licenses may have additional requirements that are incompatible with Habari itself or with the idea that anyone with access to the extras repo has access to alter any code in it.
I dislike the idea that everything must be attributed to the Habari Project when submitted to the repo. While the ASL license on the plugin will probably not bother someone who is already using Habari, being unable to publish copyright information on produced plugins is a bit strange.
We should insist that contributors who do not add their copyright information to the plugin upon commit release their rights on the contribution. If you want to retain copyright, it is very simple to alter the code to add it.
At any time, any plugin can be submitted for proprietorship by the Habari Project. At that time, the current copyright holders will be contacted to vet their claim of ownership and release their claim to the Habari Project. Until this happens, NO plugins should be attributed to the Habari Project, and in reality, this should probably only happen when a plugin is being considered for core inclusion.
Regarding themes, it is my opinion that themes must be dual-licensed. They need a license for the code (ASL2) and a license for the output it produces. I suggest that the output license for themes in our repo be a Creative Commons license that requires the allowance of modifications (to be consistent with the idea that anyone can edit the files in the repo).
Also, we should specifically note in advance that the appropriate place for copyright placement for a theme is in the theme information file, NOT as part of the public display of the theme. A theme in the repo must not require the copyright or any specific author link to be displayed or maintained in derivative works, although these may be included part of the raw theme. The goal being that themes should benefit the community, not constitute linkfarms for theme authors.
Plugin and theme authors that wish to fulfill commercial aspirations would do well to contribute decent themes to the repository which would be the easiest way to garner a reputation for quality work and involvement with the community.
One of the goals with a central repository should be that it be THE central repository, and we should make good efforts to keep this part of the community from fragmenting while making sure that our property is protected for the reuse we intended.
Owen Winkler wrote: > I think the terms for adding projects to the extras repo should be kept > reasonably simple but also address the beliefs of our community. This > is my opinion for what rules we should adhere to:
> All plugins must be ASL2-licensed to be submitted to the repo.
> This is a practical concern because alternative licenses may have > additional requirements that are incompatible with Habari itself or with > the idea that anyone with access to the extras repo has access to alter > any code in it.
> I dislike the idea that everything must be attributed to the Habari > Project when submitted to the repo. While the ASL license on the plugin > will probably not bother someone who is already using Habari, being > unable to publish copyright information on produced plugins is a bit > strange.
> We should insist that contributors who do not add their copyright > information to the plugin upon commit release their rights on the > contribution. If you want to retain copyright, it is very simple to > alter the code to add it.
"Release their rights" in what fashion? Simply their right to be credited? Also, it seems that committing to -extras is (under current structure) releasing rights to have any kind of control in any case, as anyone with commit access would then be able to modify your code anyway.
> At any time, any plugin can be submitted for proprietorship by the > Habari Project. At that time, the current copyright holders will be > contacted to vet their claim of ownership and release their claim to the > Habari Project. Until this happens, NO plugins should be attributed to > the Habari Project, and in reality, this should probably only happen > when a plugin is being considered for core inclusion.
> Regarding themes, it is my opinion that themes must be dual-licensed. > They need a license for the code (ASL2) and a license for the output it > produces. I suggest that the output license for themes in our repo be a > Creative Commons license that requires the allowance of modifications > (to be consistent with the idea that anyone can edit the files in the repo).
Is there a CC license that meets these requirements? I'm also not sure that the respective licenses _don't_ cover the whole of a work. Books don't need a separate copyright for their cover and their text. Perhaps a bad analogy, but it seems similar to me.
> Also, we should specifically note in advance that the appropriate place > for copyright placement for a theme is in the theme information file, > NOT as part of the public display of the theme. A theme in the repo > must not require the copyright or any specific author link to be > displayed or maintained in derivative works, although these may be > included part of the raw theme. The goal being that themes should > benefit the community, not constitute linkfarms for theme authors.
If our policy is that the themes cannot credit the designer, are we going to forbid links the Habari Page as well? It seems to me that to do otherwise would be hypocritical.
> Plugin and theme authors that wish to fulfill commercial aspirations > would do well to contribute decent themes to the repository which would > be the easiest way to garner a reputation for quality work and > involvement with the community.
> One of the goals with a central repository should be that it be THE > central repository, and we should make good efforts to keep this part of > the community from fragmenting while making sure that our property is > protected for the reuse we intended.
Unfortunately it seems to me that what we're looking at doing will be much too restrictive to allow it to become THE central repository. In order to use -extras you will have to 1)Use our license 2)Surrender all oversight of your work 3)Depend entirely on people reading NOTICE files to receive any credit for your work.
I'm honestly not sure where the point of compromise is between the openness that we desire, protecting Habari from liability for licensing issues, and recognizing good work in whatever form it appears.
Was the intention of -extras ever to be the "one stop source for all plugins Habari"? I didn't think so, but I might be wrong. I wanted access to it when it was created to be able to put my code somewhere, and I don't see the huge problem in assigning copyright to the Habari project. Others might see it otherwise though, but IMO they could publish their code elsewhere besides in any official Habari svn repository.
As for the one stop source, I think there are other methods to make that happen without everyone having to host their code on -extras. Not sure how it should work, but I'm sure there are ways to accomplish that.
-----Original Message----- From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On
Behalf Of Sean T. Evans Sent: 5. februar 2008 19:31 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: migrating -contrib to -extras
Owen Winkler wrote: > I think the terms for adding projects to the extras repo should be kept > reasonably simple but also address the beliefs of our community. This > is my opinion for what rules we should adhere to:
> All plugins must be ASL2-licensed to be submitted to the repo.
> This is a practical concern because alternative licenses may have > additional requirements that are incompatible with Habari itself or with > the idea that anyone with access to the extras repo has access to alter > any code in it.
> I dislike the idea that everything must be attributed to the Habari > Project when submitted to the repo. While the ASL license on the plugin > will probably not bother someone who is already using Habari, being > unable to publish copyright information on produced plugins is a bit > strange.
> We should insist that contributors who do not add their copyright > information to the plugin upon commit release their rights on the > contribution. If you want to retain copyright, it is very simple to > alter the code to add it.
"Release their rights" in what fashion? Simply their right to be credited? Also, it seems that committing to -extras is (under current structure) releasing rights to have any kind of control in any case, as anyone with commit access would then be able to modify your code anyway.
> At any time, any plugin can be submitted for proprietorship by the > Habari Project. At that time, the current copyright holders will be > contacted to vet their claim of ownership and release their claim to the > Habari Project. Until this happens, NO plugins should be attributed to > the Habari Project, and in reality, this should probably only happen > when a plugin is being considered for core inclusion.
> Regarding themes, it is my opinion that themes must be dual-licensed. > They need a license for the code (ASL2) and a license for the output it > produces. I suggest that the output license for themes in our repo be a > Creative Commons license that requires the allowance of modifications > (to be consistent with the idea that anyone can edit the files in the repo).
Is there a CC license that meets these requirements? I'm also not sure that the respective licenses _don't_ cover the whole of a work. Books don't need a separate copyright for their cover and their text. Perhaps a bad analogy, but it seems similar to me.
> Also, we should specifically note in advance that the appropriate place > for copyright placement for a theme is in the theme information file, > NOT as part of the public display of the theme. A theme in the repo > must not require the copyright or any specific author link to be > displayed or maintained in derivative works, although these may be > included part of the raw theme. The goal being that themes should > benefit the community, not constitute linkfarms for theme authors.
If our policy is that the themes cannot credit the designer, are we going to forbid links the Habari Page as well? It seems to me that to do otherwise would be hypocritical.
> Plugin and theme authors that wish to fulfill commercial aspirations > would do well to contribute decent themes to the repository which would > be the easiest way to garner a reputation for quality work and > involvement with the community.
> One of the goals with a central repository should be that it be THE > central repository, and we should make good efforts to keep this part of > the community from fragmenting while making sure that our property is > protected for the reuse we intended.
Unfortunately it seems to me that what we're looking at doing will be much too restrictive to allow it to become THE central repository. In order to use -extras you will have to 1)Use our license 2)Surrender all oversight of your work 3)Depend entirely on people reading NOTICE files to receive any credit for your work.
I'm honestly not sure where the point of compromise is between the openness that we desire, protecting Habari from liability for licensing issues, and recognizing good work in whatever form it appears.
On Feb 5, 6:28 pm, "Christian Mohn" <h0b...@gmail.com> wrote:
> Was the intention of -extras ever to be the "one stop source for all plugins
> Habari"? I didn't think so, but I might be wrong. I wanted access to it when
> it was created to be able to put my code somewhere, and I don't see the huge
> problem in assigning copyright to the Habari project. Others might see it
> otherwise though, but IMO they could publish their code elsewhere besides in
> any official Habari svn repository.
> As for the one stop source, I think there are other methods to make that
> happen without everyone having to host their code on -extras. Not sure how
> it should work, but I'm sure there are ways to accomplish that.
I don't think habari-contrib was meant for that, but now that it's at
hp.o, the idea is not to have numerous repos for plugins/themes, at
least that's my take.
> Christian-----Original Message-----
> From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On
> Behalf Of Sean T. Evans
> Sent: 5. februar 2008 19:31
> To: habari-dev@googlegroups.com
> Subject: [habari-dev] Re: migrating -contrib to -extras
> Owen Winkler wrote:
> > I think the terms for adding projects to the extras repo should be kept
> > reasonably simple but also address the beliefs of our community. This
> > is my opinion for what rules we should adhere to:
> > All plugins must be ASL2-licensed to be submitted to the repo.
> > This is a practical concern because alternative licenses may have
> > additional requirements that are incompatible with Habari itself or with
> > the idea that anyone with access to the extras repo has access to alter
> > any code in it.
> > I dislike the idea that everything must be attributed to the Habari
> > Project when submitted to the repo. While the ASL license on the plugin
> > will probably not bother someone who is already using Habari, being
> > unable to publish copyright information on produced plugins is a bit
> > strange.
> > We should insist that contributors who do not add their copyright
> > information to the plugin upon commit release their rights on the
> > contribution. If you want to retain copyright, it is very simple to
> > alter the code to add it.
> "Release their rights" in what fashion? Simply their right to be
> credited? Also, it seems that committing to -extras is (under current
> structure) releasing rights to have any kind of control in any case, as
> anyone with commit access would then be able to modify your code anyway.
> > At any time, any plugin can be submitted for proprietorship by the
> > Habari Project. At that time, the current copyright holders will be
> > contacted to vet their claim of ownership and release their claim to the
> > Habari Project. Until this happens, NO plugins should be attributed to
> > the Habari Project, and in reality, this should probably only happen
> > when a plugin is being considered for core inclusion.
> > Regarding themes, it is my opinion that themes must be dual-licensed.
> > They need a license for the code (ASL2) and a license for the output it
> > produces. I suggest that the output license for themes in our repo be a
> > Creative Commons license that requires the allowance of modifications
> > (to be consistent with the idea that anyone can edit the files in the
> repo).
> Is there a CC license that meets these requirements? I'm also not sure
> that the respective licenses _don't_ cover the whole of a work. Books
> don't need a separate copyright for their cover and their text. Perhaps
> a bad analogy, but it seems similar to me.
> > Also, we should specifically note in advance that the appropriate place
> > for copyright placement for a theme is in the theme information file,
> > NOT as part of the public display of the theme. A theme in the repo
> > must not require the copyright or any specific author link to be
> > displayed or maintained in derivative works, although these may be
> > included part of the raw theme. The goal being that themes should
> > benefit the community, not constitute linkfarms for theme authors.
> If our policy is that the themes cannot credit the designer, are we
> going to forbid links the Habari Page as well? It seems to me that to do
> otherwise would be hypocritical.
> > Plugin and theme authors that wish to fulfill commercial aspirations
> > would do well to contribute decent themes to the repository which would
> > be the easiest way to garner a reputation for quality work and
> > involvement with the community.
> > One of the goals with a central repository should be that it be THE
> > central repository, and we should make good efforts to keep this part of
> > the community from fragmenting while making sure that our property is
> > protected for the reuse we intended.
> Unfortunately it seems to me that what we're looking at doing will be
> much too restrictive to allow it to become THE central repository. In
> order to use -extras you will have to 1)Use our license 2)Surrender all
> oversight of your work 3)Depend entirely on people reading NOTICE files
> to receive any credit for your work.
> I'm honestly not sure where the point of compromise is between the
> openness that we desire, protecting Habari from liability for licensing
> issues, and recognizing good work in whatever form it appears.
> I think that it's fine if people want to attribute code to the > community, but I also think that there must be a place for recognition > somewhere in our project.
Having commit access to the -extras repository should be its own level of recognition, in part. I mean, we can't simply grant commit access to everyone who asks: we need some sort of vetting process.
That, or we start granting granular permissions to the repository, so that you can only commit to your projects (which may be a good idea).
> Granted, I agree completely with keeping names out of individual > components of the core code, and I likewise concur with doing the same > for contributed code (such as adding code comments that say "this > line/function was added by so-and-so"). Still, copyright attribution > should be maintained for the contributors, and I see no good reason why > this information couldn't exist in the place that is meant to hold it - > the plugin info record.
If a plugin is committed to the -extras repository, and that repository provides write access to all projects to all members, maintaining copyright of individual projects could become problematic. If I modify your -extra hosted plugin, I have a copyright interest in that project now. If lots of people work collaboratively (which, I believe, was one of the original goals for this repository), the plugin's info field may be insufficient to properly document the contributors.
Perhaps we require that all -extras hosted projects contain a NOTICE file, per the Apache requirements: this makes each project more akin to Habari itself, whereby we list contributions in this file, rather than in the source code. This is just one idea.
> Being that the revision log will likely not distributed with the plugin, > leaving the subversion log as the sole record of contribution will > likely not distribute proper copyright attribution or recognition with > the conventional zip or tar file as including actual names in a specific > place in the plugin.
A NOTICE file could be included in generated archives.
> Assignment of attribution is less of an issue to me than committing > referral links in themes and other spurious practices against which we > should have strict rules. Also, attribution is of less concern to me > than stating an explicit license for the code, which should be ASL if > we're keeping in our repo, with the understanding that committing code > there allows community access to edit it.
I concur. Affiliate links and linkfarm attempts should be explicitly forbidden.
I also agree that the use of the Apache license be mandatory for -extras hosted projects.
> There is curerntly no branching or tagging in the extras repo. Is this > intentionally omitted, or was some other plan in place to deal with that?
In Subversion, a branch works upon the entire repository from which the branch is created. I did not create a top-level /branches directory because I don't think we want the entire repository branched when a single plugin branches.
We could have /trunk, /branches, and /tags directories inside the individual project directories, with well-written documentation explaining how to branch or tag just one project.
> > Also how will we handle bug/enhancement tickets. Currently habari- > > extras doesn't have a way to view/create tickets. Will all tickets be > > handled in the main issue tracker? I'd suggest keeping them separate, > > to keep the core code issues easier to monitor.
> I can edit the Trac instance to enable that feature. I think that the > separate repo should have its own Trac to keep the noise level down on > the main repo.
Each project should then be its own component within that Trac instance, so that reports can be filed against individual projects within the repository, and granular reports and feeds can be generated.
> I dislike the idea that everything must be attributed to the Habari > Project when submitted to the repo. While the ASL license on the plugin > will probably not bother someone who is already using Habari, being > unable to publish copyright information on produced plugins is a bit > strange.
If we don't make the Habari Project the "owner" of contributed projects, how do we properly manage potentially many people with write access to lots of disparate projects?
Do we say for individual projects "all contributions to this project relinquish copyright to those contributions to the original author" ? This allows the original author to maintain copyright on all their projects' code, but potentially discourages the kind of collaborative ecosystem we had previously envisioned.
> At any time, any plugin can be submitted for proprietorship by the > Habari Project. At that time, the current copyright holders will be > contacted to vet their claim of ownership and release their claim to the > Habari Project. Until this happens, NO plugins should be attributed to > the Habari Project, and in reality, this should probably only happen > when a plugin is being considered for core inclusion.
What does it mean, in a legal sense, for the Habari Project to have proprietorship and/or copyright on a contributed project?
Michael Bishop wrote: > So, from all of this, how would this pertain to leaving a link to the > original designer of an "open" HTML/CSS design in a theme for extras?
If the license requires only that the copyright notice remain intact, then the rest of the theme is fair game, including any links in output.
A CC-attribution license requires that the attribution appears in a place specified by the author. If that includes a link in the output, then that's where the attribution needs to appear.
Personally, I'm not interested in distributing themes that require you to link to the author on your public site. I think that the wording on the CC-by license is poor, that there should be an alternative for attribution that allows derivative works to include proper attribution without keeping the link format as requested by the author.
I think themes such as this might be ok for the extras repo, but:
1) The idea of the extras repo is to build plugins and themes that might eventually be promoted to core. 2) The core will never include a CC-by license.
So I wonder if we should bother allowing CC-by themes in the extras repo at all.
