cc-licenses AT lists.ibiblio.org
Subject: Development of Creative Commons licenses
List archive
- From: drew Roberts <zotz AT 100jamz.com>
- To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
- Subject: Re: [cc-licenses] Restricting Derivative Works
- Date: Mon, 26 Jun 2006 15:42:24 -0400
First I am going to reply to something from the bottom:
>Phil's choice of license has broadcasted what he wants.
>Freedom is not his highest priority.
I was not aware that Phil had already settled on a license, but was rather
looking for input to accomplish a particular objective.
Next, you clearly misunderstood some of my suggestions and so are arguing
against a system I never contemplated.
On Monday 26 June 2006 12:45 pm, Greg London wrote:
> On 6/26/06, drew Roberts <zotz AT 100jamz.com> wrote:
> > On Monday 26 June 2006 10:17 am, Greg London wrote:
> > > The AGPL is copyleft. Phil's project isn't.
> >
> > My point was that you can come up with new copyleft
> > licenses and perhaps new copyleft like schemes.
>
> And my point is that this is a non-sequitor.
> Phil's project isn't Free, Libre, or Shared.
>
> > look at the mods I suggested. How is it that if a project adopted
> > the ideas I suggested that contributors would not end up with pretty
> > much copyleft protection?
>
> This may create a copyleft scenario, but it isn't Free because
> it creates way more overhead to contribute than something like
> the BSD advertising clause. The BSD license is nearly public
> domain, but people protested the overhead associated with
> the advertising clause, so it was removed.
>
> So, you could just as easily craft some sort of copyleft license,
> a license where the work and any derivative of teh work all
> must be put under the same license, but you could add things
> to the license that create extra overhead that hinders contributions,
> that hinders people from creating their own derivatives, that hinders
> people from forking the project if they wish.
>
> There is overhead associated with Attribution in early CC licenses,
> and it was fixed by allowing people to assign attribution to a single
> site.
>
> So, it isn't enough to be copyleft, like some hypothetical scheme
> that you come up with to replace Phil's scheme, and it isn't enough
> to be almost Public Domain like BSD or CC-BY. Small demands
> placed in a copyleft of Public Domain license will make the license
> be not Free, even though the license it copyleft or Public Domain.
>
> Specific licenses, such as the latest versions of GNU-GPL and
> CC-BY-SA are written to be copyleft and to also avoid any
> bolt-ons (advertising clauses, accumulating attribution) that add too
> much overhead to weigh down any Free project.
>
> > How would someone in Phil's position have any advantages?
>
> Maintaining someone at an advantage is only one problem.
> Even with a license such as the old BSD license with its
> advertising clause, no one is at an advantage, but the
> overhead can become problematic to the point that
> contributions become too much work.
>
> Phil's approach keeps his contributers at a serious
> disadvantage compared to his position.
> Your approach may solve the problem so that no one
> is at an advantage over anyone else, but it still has
> overhead problems of having to report all mods back
> to Phil.
>
> So when Alice starts her fork, she has to notify Phil.
> And when Bob wants to fork off of Alice's version,
> he has to notify Alice and Phil. And when Charlie
> wants to fork off of Bob's version, he has to notify
> Bob, Alice, and Phil.
Here is where you misunderstand. There would be no reporting back as all mods
must be created and maintained on the one wiki site. (If this is onerous to
anyone, it will be to Phil.)
>
> The effect is cumulative, exactly like the BSD advertising
> clause, exactly like requiring individual attribution in the
> early CC-BY licenses. Every fork'ed generation becomes
> more and more work to create, which in a sense, keeps
> Phil's version at an advantage, because Phil doesn't have
> to notify anyone.
Actually, like I say, Phil will have to commit to hosting all forks which may
become burdensome to him.
>
> This is the effect of any cumulative license requirement:
> The first version is always easiest to modify because
> it has the least cumulative requirements. Which means
> that the first version is always at an advantage over
> everyone else.
This does not apply. Start with any version "on wiki" and make your new
version based on that right there "on wiki." No problem.
>
> The only way to keep the field completely level so that
> no one is at an advantage and so no overhead accumulates
> no matter what version you fork off of, you have to allow
> anyone to create a derivative off of any version they wish,
> and you can't require that they notify you of those modifications.
>
> > Look, if I am mistaken and the mods I suggested would
> > behave other than I imagine, please point out the problem.
> > I am all ears. If they would behave like I imagine, but three
> > are still major problems, point them out, I have tried to.
>
> They would behave like you imagine, but there are
> still problems with the approach that make them
> not Free.
>
> > I don't think so. From what I grasp, he is cool with anyone
> > forking and making their own version "on wiki" and then
> > taking them "off wiki" in a BY-ND like fashion. He just
> > doesn't want forked versions existing in the wild that are
> > not also "on-wiki." (That is what I understand his desires to be.)
>
> Exactly. He has created a licensing and contract scenario
> that maintains his version of the work at an advantage.
> What if Alice wants to create a Fork of the project?
> And then Bob wants to take Alice's version and fork that?
> and Charlie wants to fork Bob's version?
They are all hosted right there on Phil's wiki. Then anyone pulls the version
they want off of the wiki under a BY-ND license and packages and sells it
however they want. No problem.
>
> Charlie has to notify Bob, Alice, and Phil.
> Therefore it is easier to modify Phil's version,
> therefore Phil has created a legal requirement
> that demands his version maintain an advantage
> over all other versions.
Nope. Does not apply, see above.
>
> > So, if he commits as a part of the copyright grant or
> > assignment process to also not go off wiki as anything
> > other than BY-ND, everyone will be on equal footing.
>
> except Phil legally establishes himself as gate keeper.
> the work is not Free, you have to get Phil's permission.
> If Alice makes a mod that Phil doesn't like, Phil can revert it.
Obviously, Phil would have to legally commit not to do this, and in fact,
commit to host all forks or to allow a new site to form around any fork he
was unwilling to host with no further obligations back upstream at that
point.
> If Alice wants the modification in the work, she cannot create
> her own fork without Phil's PERMISSION. If you need someone's
> permission, you are not on equal footing with them.
How do you permission as being necessary as long as the starting conditions
are right?
>
> > Anyone can fork "on-wiki"
>
> As long as Phil permits it. Will Phil also agree to allow forks
> of the work "on-wiki"? Or will he be able to reject modifications
> if he doesn't like them?
He would have to or what I am thinking would not apply and others would not
be
protected.
>
> And again, see all the problems with "overhead".
> Actually, with Phil's approach, you can't have multiple
> generation forking because only Phil can fork.
> It prevents cumulative overhead from forking, but
> only because it doesn't allow forking at all.
I don't see the overhead. I do see that there could be no private mods. This
lack of privacy could be problematic. Can anyone find links to this
discussion re the GPL?
>
> > What am I missing/overlooking? Would this not work?
>
> All Rights Reserved "works", It gets people to create books
> and software and all sorts of things.
> So the question isn't whether it "works".
Not works like that, works as in basically gives the benefits of BY-SA or the
GPL except that it does not allow for mods that are kept private.
>
> The question is whether it's Free/Shared or not.
>
> And every hoop you've tried to jump through,
> every hypothetical suggestion you've come up with,
> every piece of legal maneuvaring you've suggested,
> ends up with a scenario that maintains Phil at an
> advantage over all other contributers, because everyone
> must go through Phil but Phil doesn't have to go through
> anyone.
Look, if Phil really only wants what I think he is saying, then I see him
actually having to bear a burden that others will not have to bear in that he
will have to host all of the works at his expense. But he will get to learn
all of the changes that are made to the docs and try and deduce why they were
made.
If he actually wants to be in a privileged position with respect to everyone
else, then I don't think his project is going to gain any widespread support
and I certainly will not be giving it the time of day.
> There's also the question of what happens
> when Phil decides he doesn't like someone's modification
> and won't allow it to remain on the wiki. It becomes
> awfully hard for Alice to create a forked version of
> the work, if Phil keeps reverting it.
To protect everyone, he would have to commit to hosting it or setting it free
under a pure copyleft license or on a wiki with similar terms hosted by
someone else and with not further upstream reporting obligations.
>
> All these hypotheticals are pointless, in my opinion.
They may indeed be. As I said, it became somewhat of a thought experiment for
me.
> The point is a much more practical matter:
>
> Phil can do whatever he wants to do to the extent
> allowed by copyright law. He can license his stuff
> however he wants to license it. He can require
> contributers sign whatever contract he wants them
> to sign.
>
> AND his approach isn't Free, nor is he Sharing.
>
> There is no way to mandate that all modifications must
> flow back to Phil without mandating that Phil is kept
> at an advantage over all other contributers.
I don't see how you can say this.
>
> To create a scenario that is (1) Free and that (2) requires
> Phil be notified of all mods is to satisfy two mutually
> exclusive requirements. One necessarily excludes
> the other.
I don't think so. Unless Free always precludes private mods. That is why I
keep asking for that link to the discussion. It has been a while since I read
it and I need to refresh my memory and then think further on it. (I don't
like the idea of private mods being forbidden though.)
>
> And the practical answer is that GNU-GPL and CC-SA
> already exist, so if Freedom is what you want, then use
> them. If you don't want Freedom, then use something else.
>
> Phil's choice of license has broadcasted what he wants.
> Freedom is not his highest priority.
Refer back to the beginning.
> If it was, he would
> have chosen a different license. Phil's priority is to maintain
> himself at an advantage over the community because he
> believes he knows what's best for the community.
> He can do that since copyright allows it, but I'm not going
> to spend time discussing hypothetical scenarios trying
> to solve an impossible problem.
>
>
> Greg
all the best,
drew
(da idea man)
--
http://www.ourmedia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedia.org/user/17145
-
[cc-licenses] Restricting Derivative Works,
Greg London, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
drew Roberts, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
Greg London, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
drew Roberts, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
Greg London, 06/26/2006
- Re: [cc-licenses] Restricting Derivative Works, drew Roberts, 06/27/2006
-
Re: [cc-licenses] Restricting Derivative Works,
Greg London, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
drew Roberts, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
Greg London, 06/26/2006
-
Re: [cc-licenses] Restricting Derivative Works,
drew Roberts, 06/26/2006
Archive powered by MHonArc 2.6.24.