Re: [uwplone] Re legal stuff (fwd)

[Melody Winkle]

more on legal stuff ...


---------- Forwarded message ----------
Date: Fri, 30 Nov 2007 09:02:51 -0800 (PST)
From: RL 'Bob' Morgan <[hidden email]>
To: Melody Winkle <[hidden email]>
Subject: Re: [uwplone] Re legal stuff (fwd)


[Let me offer these comments in advance of the meeting, responding to the note
you sent, and let you forward them to the list.]

I'm not a lawyer, I'm a techie, but I have dealt with lawyers quite a bit
regarding IPR issues in collaborative software projects, primarily at
Internet2, and have made IPR-related decisions for a number of projects. So I
have some experience with this stuff.

Indeed the concerns raised are very important and have to be dealt with up
front in a project lest they come up later and create bad feelings or even
cause work to be discarded and partnerships to fail.  (Anecdote:  on an
Internet2 project we had a worker contributed by a big commercial vendor, and
didn't have any upfront IPR provisions in place.  Near the end of the project
we heard the vendor, via this worker, was going to file a patent, in their name
only, on some of the key elements.  We spent vast time fighting this,
eventually they didn't file, but we learned our lesson.)

Regarding who owns the work done by university contributors:  most likely it is
the university (like any other employer owns the work produced by its workers
on their work time), though I'm aware of exceptions.  So in a project, when a
contributor says "here's a bunch of code I wrote", you as the project manager
have to hear "here's a bunch of code that is the property of my employer that I
say is being offered to the project" and you have to wonder (a) whether that
person is empowered to give it, (b) what university-imposed constraints there
are on its use, (c) what the copyright should say, (d) probably other stuff.

Clarifying this up front is the job of a Contributor License Agreement. See the
"Contributor License Agreements" of http://www.apache.org/licenses/ to see how
Apache does it.  see http://www.internet2.edu/wg/wg-list.html#ICLA for how
Internet2 does it. (The Internet2 CLAs started with Apache and got spun from
there.)  A project that wants to be clean IPR-wise has to get signed CLAs from
participants before they contribute code or other material in any substantive
amount.  Note that there tend to be both individual and corporate versions; in
my project experience we almost always use the corporate ones.

There is of course judgement to be applied regarding "substantive".  If someone
sends a two-line patch you don't need a CLA, but you might still want to ask
them to send an email saying the project has rights to use the contribution.

CLAs by nature are closely tied to the license used by the project for its
output.  This is because a contributor typically has an interest in the
disposition of their contribution, so contributes it contingent on the license
of the package being a certain way (ie, open).  So you'll see language repeated
in the Apache CLA from the Apache license, for example.

Copyright is another big deal.  The main effect of copyright on an open-source
project is that if you want to change the license of a package, you have to get
the agreement of all copyright holders.  So having a single copyright holder
for a package makes it easier to change licenses later if appropriate, but of
course puts the power in the hands of the copyright holder to do so.  A project
will want to have a policy regarding who holds the copyright on contributions.
This could be "must be organization X", or "contributing organization" or
whatever.  Having multiple copyright statements on a file just muddies things
and should be avoided IMHO.  A package can and should be copyrighted
independently from its component parts; this can good to bind together a
package in the name of the main project organization.

Patents are the other big deal.  You'll note that the Apache license (and CLA)
gives patent use rights to adopters of the package.  This is really important,
because purported patent violations have been one of the main weapons used by
closed-source companies to spread FUD in open-source. There has been a great
deal of dancing around the patent issue in HE recently, some of it resulting in
the so-called "community source" license which in my view fails to meet the
patent-protection needs of adopters. Patent rights will want to be covered in
CLAs and licenses.

I always recommend use of the Apache license, and CLAs modeled on the Apache
CLAs, to projects I'm involved with.  These docs are (a) well-known and
widely-used, (b) clear, (c) cover all the bases, and (d) generally conform to
the interests of university-oriented projects, which are usually to promote
wide adoption and spend as little time as possible on all this junk.

Also a note on lawyers:  many of them don't know much about IPR, and especially
about open source.  Their job is to shield their employers from liability, and
to maintain control of IPR, so often they'll give very restrictive advice.
It's up to projects to emphasize our interests in giving stuff away and getting
people to use it.

   - RL "Bob"

>> ---------- Forwarded message ----------
>> Date: Thu, 15 Nov 2007 16:34:33 -0800 (PST)
>> From: cristopher pierson ewing <[hidden email]>
>> Reply-To: [hidden email]
>> To: [hidden email]
>> Subject: [uwplone] Re legal stuff
>>
>> Yeah, I can pipe up here.
>>
>> One of the most contentious parts of the discussion about putting together a
>> 'plone4edu' collaboration was the issue around both copyright and patent on
>> software created for the group.  The biggest issue seems to be the
>> hypothetical situation of Bob from the University of Legal Boors
>> contributing a bunch of code to the Plone4EduSuperProduct, which is then
>> used by unversities everywhere.  Suppose that some whiz-bang IP lawyers for
>> ULB decide that becase Bob was working on their paycheck when he wrote the
>> code, that means that ULB has IP rights to that code, and that they wish to
>> assert those rights agains all the other universities using the product. How
>> does the new Plone4Edu defend proactively against this possibility?
>>
>> As is usually the case in a room full of developers, and devoid of lawyers,
>> there were a lot of opinions but very little factual information available.
>>
>> I this it would be a good idea, if we wish to contribute to this growing
>> community of plone-powered educators, to hash out these legal issues as they
>> apply to work done on our campus.  My bosses are quite enlightened and take
>> the view that as long as we get to use the code, my time spent collaborating
>> is valid use of UW resources, but they aren't lawyers either. So it might be
>> the right thing to do to bring an actual lawyer into the discussion.  I
>> don't know.
>>
>> I just wanted to bring it up.
>>
>> Any opinions, thoughts, lawyers?
>>
>> C
>>
>> ********************************
>> Cris Ewing
>> Department of Radiology Web Services
>> University of Washington
>> School of Medicine
>> Work Phone: [phone]
>> Home Phone: [phone]
>> E-mail: [hidden email]
>> *******************************
>>
>>
>> _______________________________________________
>> uwplone mailing list
>> [hidden email]
>> https://mailman1.u.washington.edu/mailman/listinfo/uwplone
>>
>

_______________________________________________
Educational mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/educational