[License-discuss] [License-review] CC withdrawl of CC0 from OSI process
Chad Perrin
perrin at apotheon.com
Mon Feb 27 08:08:27 UTC 2012
On Sun, Feb 26, 2012 at 09:41:01PM -0800, Bruce Perens wrote:
> On 02/26/2012 09:00 PM, Chad Perrin wrote:
> >I suspect a better approach to understandable, legally well-formed
> >license production might be to get someone who wants a very simple
> >license to write it, and only *then* get the lawyers involved.
> >While you're at it, be prepared to make the lawyers explain
> >everything they want to change, and to tell them "no" a lot.
> The problem with your software, Chad, is that it's much too
> complicated for /no reason./ There's no reason for half of that
> "crapton" to be in there. We could cut it down to 10% of its present
> complexity if we had a /user /who wanted a really simple program
> write it first, and then we could have a programmer make it work
> correctly. While the programmer did that, we would make him explain
> /everything /that he was doing, and we would tell him "no" a lot to
> curb his natural tendency to add unnecessary complexity.
This may surprise you, but I don't think that actually proves what you
probably think it does.
Y'know what? A user willing and able to dive into writing code for his
or her own purposes should be encouraged to do so, and experienced
software developers who are willing to offer some peer review or
mentoring can provide an invaluable service in helping a novice
programmer learn how to serve his or her own needs better than any
outsider trying to second guess his or her desires ever could. So, yeah,
that's pretty much *exactly* what I have in mind.
Thanks for the excellent analogy supporting my point so beautifully.
>
> The pieces you don't like aren't there because anyone likes to put
> them there or because the people who wrote the license are idiots.
Tell that to the guy who doesn't want the "crashes every couple hours"
feature of an overcomplicated word processor or operating system, or the
guy who doesn't want the "What the hell is *that* doing in this
license?!" feature of a legal unwittingly misrepresented as having much
simpler legal effects than were explicitly described in the license text
itself (let alone those license terms that have *unintended* effects).
You yourself have questioned some terms that are not fully disclosed in
recent discussion, but now you act like this stuff doesn't matter. Sure,
they're there for a specific reason, and the people who wrote the license
are probably not idiots (in fact, I think they're probably quite smart
about this stuff), but the fact remains that the legal density of the
license text and necessary inadequacy of a "plain English" simplification
leaves potential license users or accepters with a potentially disastrous
misunderstanding of terms.
>
> There have been a lot of court cases in history. From those cases,
> we know a number of things that go wrong in courts. We want you not
> to get trapped by the same stuff.
Instead, people should get trapped by the simple fact they do not
understand the licenses in question, I suppose -- or perhaps open source
software development and open culture art are only for people with
lawyers on retainer.
Once more, I'm not talking about things like "This turn of phrase is
necessary to cover specific case-law eventualities." I'm talking about
"This license explicitly disclaims any patent license, setting me up for
a patent suit trap. That license limits what technologies I can use to
redistribute this work, which means I'm violating its terms when I
distribute it on iTunes. The other license specifies "software" in a
definitions section in a way that makes my use of the covered work, which
is a combination of example code and English explanation, only partially
protected from copyright infringment suits if I redistribute it."
The fact a lawyer wrote a license does not in any way whatsoever
guarantee that people will not misunderstand the licenses, especially
when all they're reading is a terribly under-explained summary (because
full explanation would require a hefty chapter of a book, if for no other
reason). It really does not matter, for the purposes of my point, how
well the lawyer did achieving legal text that will for decades to come
stand up to court test as satisfying the literal request (in every
detail) of the guy who commissioned the lawyer's work.
>
> I had to help Bob Jacobsen, an Open Source developer who chose one
> of those over-simple licenses, the Artistic License 1.0, written by
> Larry Wall the Programmer. Bob had someone who both used his program
> in a product without even attributing it to him, and /also /asked
> Bob for lots of money for infringing his patent and tried to get Bob
> fired from his job by filing an FOIA with his employer. This was all
> over /model train software./
There is a difference between an overly-simple license that tries to do
too much and a *properly* simple license that tries to do the minimum
acceptable amount of stuff so that mere mortals are still capable of
reading it when crafted by a qualified professional. Feature creep is as
much a problem for licenses as for software -- more so, if you consider
things like very real legal trouble for a license user worse than buggy
interface behavior for a software user.
>
> When Bob turned to Larry's Artistic License to help him get the guy
> off of his back, the Artistic License failed in court. We put a good
> team together and turned that around on appeal, but it was a close
> thing. By the time we were done, Bob had spent 5 years on the case,
> was out a good deal of money, and his relationship with his employer
> was damaged.
Congratulations on salvaging a horrible situation that is wholly
irrelevant to my point.
>
> We might not be able to help the next Bob who comes along and uses
> one of those licenses written in crayon. You can protect your
> friends by not encouraging them to do that.
Where did I say licenses should be written in crayon? I said we should
strive for simplicity of requirements so that the legal terminology can
be kept to a dull roar, and not that legalisms should be discarded
entirely. Please do not recast my argument in terms completely contrary
to my actual point so you can have fun stabbing the straw man without the
brains Oz gave a scarecrow. Addressing the point I actually made would
be much more productive.
I really don't think your desire is to advocate for making licenses as
unreadable as humanly possible while still being legally rigorous, after
all.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
More information about the License-discuss
mailing list