draft legal ideas

[Zach Welch]

Hello all,

Here's the first of many messages that need to be written covering the
foundation's plans for licensing its works.

= Bylaws Under Consideration =

After much delay, here are the bylaws of the other non-profits that we
have been looking at (in order of my current preference):

http://www.python.org/psf/bylaws.html
http://www.spi-inc.org/corporate/spi-bylaws
http://www.apache.org/foundation/bylaws.html

These all provide fine examples, but they may only serve as rough models
for our own bylaws. There are varied improvements that can be made, and
I have been consulting with the fineest minds in the community to ensure
that we try to address any problems discovered since these organizations
came into existance.

= Licensing Issues =

There has been a lot of talk about licensing issues. I can't imagine
this post will begin to end the debate, but this should give a clear
view of my aims for licensing of our documentation and source code.
After talking with many other people in the open source business world,
I believe these ideas should be accepted by the large majority of the
individuals interested in being involved with this project, and I hope
that everyone will take the time to reflect on these ideas before
responding. Also, remember that despite all this verbosity, there is so
much more that could be said to help clarify the details.

= Why Not Just Use the GPL? =

There has been repeated and (in my opinion) valid concerns that the GPL
(and similar licenses from the FSF) places too many restrictions on
businesses. You may or may not agree that this assertion is true, but
Zynot will fundamentally provide choices for our users, developers, and
customers - and this choice should extend to our documentation and
source code licensing.

This will undoubtedly be a very contraversial point; however, this will
be one of those things that sets us apart from Gentoo and most other
distributions.

= Contributor Licensing Agreements =

Given the above, I believe Zynot needs a Contributor License Agreement
that enables the Foundation's to effectively make licensing decisions
for both the documentation and source code. Apache has both the
following source contributor license, which provides a decent example:

http://incubator.apache.org/forms/ASF_Contributor_License_2_form.pdf

This form is very straightforward and should be fair and acceptable for
our members without modification. Before we embark with significant new
development, I would like to see all contributors sign such an
agreement, though there are a couple of modifications that might bear
our consideration.

== CLA FAQ ==

To be clear, the following points have been asked of me enough times to
deserve emphasis:

* These licenses will only apply for entirely new works created by our
contributors. Initially, we will continue to be beholden to the
licenses inherited from Gentoo and its progenetors; however, our new
works will be created under these terms.

* The Contributor License Agreement does not require outright assignment
of these works; from term 2, "Except for the rights granted to the
Foundation in this paragraph, You reserve all right, title, and interest
in and to your contributions."

* Commercial licenses would only be required for businesses that do not
feel the GPL is acceptable for their desired use of the components. If
the GPL is acceptable, then businesses will never be forced to pay for a
license to these works, and the foundation will encourage the use of the
GPL instead of alternative and potentially closed licenses.

== Zynot's CLA ==

We are looking to adapt the Apache license for The Zynot Foundation,
including updates that try to . I was inspired by Bruce Perens at
LinuxWorld to try to include two additional terms:

* An appropriate reference to the Volunteer Protection Act should be
included. A copy of the act's text can be found at the following URL:

http://www.races.net/voluntr.html

* a clear clause for mutual termination of rights

The immensite of these changes provides a stumbling block in getting
acceptance of any such new contractual language by the contributing
community, but I have heard rumors that future revisions of other
licenses may include similar language. This language aims to protect
both contributors and the foundation, ensuring that legal actions can be
dealt with effectively and efficiently.

== Documentation Licensing, Part I ==

For most general purposes, I would like Zynot to use the Open
Publication License as the license for content. This FSF approved
license can be found here:

http://opencontent.org/openpub/

It would be up to each author to decide whether or not to add the
non-free clauses; however, the foundation would strongly recommend
contributors use the no-clause (free) version in all possible cases.
Full freedom may be appropriate for some content, but there may be
liability or other legal claims stemming from selective re-use or
careless transformation of some works.

== Documentation Licensing, Part II ==

In other cases, I would like the foundation to be able to use the Free
Documentation License, as it is much more suitable for larger works:

http://www.fsf.org/copyleft/fdl.html

I would like to hear everyone's opinions about the foundation being able
to relicense contributions under either of these licenses, as it sees
fit.

The idea here is that contributions on the wiki or mailing lists would
fall immediately under Open Publication License, the foundation could
later relicense that material under the FDL when producing (for example)
a book or other composite work. A verbose policy will be developed to
clearly delineate the appropriate documentation license for a work.

== Source Licensing - The Obvious ==

The Zynot Foundation will always provide the software developed by and
for its contributors under the GNU GPL license:

http://www.fsf.org/licenses/gpl.html

Downloads of all software will always be freely available under these
terms, and the foundation will proactively attempt to find ways to
contribute back to the projects that enable its existance.

Initially, such return to the community will come in the form of
supporting development, but overtime the foundation should be able to
raise enough capital to spread it directly to other projects.

== Source Licensing - The Crux ==

I just came across the following site and FAQ, and this excerpt
reflects my desires for Zynot:

"""
We also believe that our software may be of interest to commercial
entities that will want to combine Chandler code with other software,
which may be either open source or proprietary software. We want to
encourage commercial use and distribution of Chandler since these
activities may provide a wider market, additional functionality, more
choices, and broader benefit for end users. Thus our software will also
be available under a fee-based commercial license for those who wish to
combine Chandler code with proprietary code. The potential revenue
stream derived from the commercial licenses will be used to fund core
development and maintenance of the open source code base.
"""
Source: http://www.osafoundation.org/OSAF_Corporate_FAQ.htm

Now, I raise this point because 1) no one has tried this approach for
the package management and glue components that make up a Linux
distribution (so far as I am aware) and 2) we lost someone interested in
being involved on the law team becaue they view this as incompatible
with their desire for a 100% GPL distribution. I was sorry to see them
go, but this is an ultimate component of the "pro-business" aspects of
the distribution - one that I believe can not afford to be ignored.

While I hope to see the marketplace shift to a mindset that fully
accepts open source software licenses, I do not believe that time will
come soon, and the existance of such opportunities for businesses does
not mean the foundation will pursue non-GPL licensing terms in any
cases. In fact, I will personally work to see that all derived works
are available under the GPL, excluding as little as possible to meet the
specific needs of businesses that desire other terms.

== Source Licensing - The Conclusion ==

These increasingly troubled times of patent infringement claims give
rise to the direct need for trusted entities that are empowered to
manage community assets. The Contributor License Agreement allows the
foundation to act as an agent for the community in a manner that
responsibly protects the many from the actions of those few that might
attempt to someday cause us trouble.

Finally, I believe this licensing scheme gives the foundation the legal
flexibility and accountability to effictively protect not only itself
but its contributors from potential liability, and it does so without
unduly restricting or encumbering contributors in order to acheive that
protection.

I look forward to discussion on these issues and, from that, the
creation of a web page that lists the foundation's licensing terms,
provides .

Cheers,

Zach

[Gareth Buxton]

Post by Zach Welch
Now, I raise this point because 1) no one has tried this approach for
the package management and glue components that make up a Linux
distribution (so far as I am aware) and 2) we lost someone interested in
being involved on the law team becaue they view this as incompatible
with their desire for a 100% GPL distribution. I was sorry to see them
go, but this is an ultimate component of the "pro-business" aspects of
the distribution - one that I believe can not afford to be ignored.
While I hope to see the marketplace shift to a mindset that fully
accepts open source software licenses, I do not believe that time will
come soon, and the existance of such opportunities for businesses does
not mean the foundation will pursue non-GPL licensing terms in any
cases. In fact, I will personally work to see that all derived works
are available under the GPL, excluding as little as possible to meet the
specific needs of businesses that desire other terms.

Now I think this really is tricky. Most commercial licenses are binary
distribution licenses. Commercial source licenses I think have the
potential to be a difficult beast to manage. For a start what abilities
are going to be given to the purchaser? Do we allow them to distribute
only binaries that are produced from derived-source?

Do we allow them to offer their customors to *view* the derived-source?
Do we allow them to sell their derived-source?
What do we mean by derived-source in the case of the commercial license?
Will foundation members end up developing closed source extentions to
the GPL code base for customers? What issues could this raise for the
future if/when similar extentsions also appear in the GPL base? *cough*
SCO *cough*. This could also bite Zynot if we do indeed allow our
customers to sell or *show* their derived source to their customers. How
does Zynot protect itself from customers adding patented extensions to
the commercial source that covers basic functionality that we were
*planing* to implement in the GPL codebase because it was an obvious
next feature (for example).

I have to say that I do appreciate where you are coming from here and if
a license exists or can be drafted that enforces the *spirit* of what
you are trying to achieve with a for-payment proprietry version of the
code, then in principle it may be beneficial. I am however very dubious
about this scheme. Also I think if zynot is providing software that
businesses want to leverage then they *will* use our free code given a
lack of choice. If however you *offer* them a choice even by merely
stating another is available then I think many will take the proprietry
road merely because it's what they usually do. There are countless
examples of proprietry software that would *benefit greatly* the vendor
if they distributed it as open source but purly out of inertia and
ignorance they keep it closed.

My vote would be for GPL only (with possible addition of LGPL or GPL +
link exception) and no commercial nonsense. However I am prepared to
look at any propositions people might have for a proprietry license
before making a final decision.

- Galik

[Michael Martucci]

Once upon a time Gareth Buxton tapped upon the keyboard...

Post by Gareth Buxton
My vote would be for GPL only (with possible addition of LGPL or
GPL + link exception) and no commercial nonsense.

I would also favour a GPL.

If the chosen license is GPL/LGPL, it should be specified as a
specific version of the GPL, and the "..and any later version."
clauses in the (L)GPL removed, as some people have concerns that
"..and any later version" means that the FSF could release a new
version of the (L)GPL that remove some of the rights given by the
current versions.

Michael.

[Gareth Buxton]

Appologies for another long post. Jens it seems we largly agree so not
all of this mail is a direct response to your post. I started with a
response and then ended up on my soap box and kept waffling :)

it makes no difference whether they distribute binaries or source; the
source is readily available from zynot, and all they distribute would be
their modifications and enhancements - that should be their choice

To clarify my concerns regarding derived code distributed as source and
to point out how I see this a being a big and critical difference:

The source that they distribute will *not* be redily available from
zynot. It will be zynot-source combined with their proprietry extensions
which they will undoubtably view as having monetary value in intelectual
property rights - they had to pay zynot for the ability to do this.

As with the SCO vs Linux fiasco you can never garuntee that IP code will
not end up in GPL codebase. This will always be true. However by giving
zynot customers the ability to 'close up' portions of zynot-source in
their own proprietry 'branch' of parts of the software we are almost
'inviting' this problem to bite us down the line. Imagine a time when
half a dozen or so companies all have and distribute 'closed' versions
of zynot-source in a highly competitive area. Imagine some of them allow
their developers to 'also' spend some of their time working on
zynot-gpl-source. Imagine some of them 'employ' zynot members to add
closed features on their behalf. Now wheras you can argue that a license
would manage all these scenarios my point is that such a license will be
difficult(impossible?) to draft and my concern is that in inviting so
much potential for disaster then some degree of disaster becomes almost
inevitable.
On the other hand in sticking with the GPL you immediately avoid a big
legal quagmire by setting a simple and level playing field for *ALL*
competing business interests.
With regard to the argument that some customers may end up being foul of
the GPL. Well I personally have no simpathy here. They have a
professional responsibility to understang the license terms by which
they use *ANY* piece of software (not just GPL) and so do the developers
they employ.
Moreover I think business understanding of GPL is improving and frankly
it should be part of zynot's mission to 'educate' business users in this
area. Particularly that keeping a 'free' pool of source code 'prevents'
potential legal quagmires and wasted 'competitive' resources allowing
them to focus on their market space.

In fact being that I see zynot as mostly an 'infrastructure' technology
then my view is that businesses will leverage zynot in a similar way
they leverage Linux. By building things on top of it (which may be
proprietary) rather than by selling proprietary versions of it. And this
for me is the crux. Why encourage the sale of proprietary versions? Who
would want or need to do that? And if they did then do we really trust
them?

- Galik

PS.
I did try to be brief but I seem to have a big problem getting off the
soap box once I'm on it :)

[Calum Selkirk]

sorry .. ended up sending this to Zach and not the list ..

* Zach Welch [***@zynot.org] [2003-08-11 13:15 -0700]:

I also wish to state my desire to have zynot be distributed under the
GPL-v2 only and concur with Galik re derivative code.

[snip]

Post by Zach Welch
== Source Licensing - The Crux ==
I just came across the following site and FAQ, and this excerpt
"""
We also believe that our software may be of interest to commercial
entities that will want to combine Chandler code with other software,
which may be either open source or proprietary software. We want to
encourage commercial use and distribution of Chandler since these
activities may provide a wider market, additional functionality, more
choices, and broader benefit for end users. Thus our software will also
be available under a fee-based commercial license for those who wish to
combine Chandler code with proprietary code. The potential revenue
stream derived from the commercial licenses will be used to fund core
development and maintenance of the open source code base.
"""
Source: http://www.osafoundation.org/OSAF_Corporate_FAQ.htm

While I have no objection to business per se, I do have issues with the
shrinking boundaries of the public domain/commons and the socio, economic
and political repercussions of same.

It is clear that intellectual property laws have the ability to
privatize a number of our culture's basic semiotic and symbolic
resources and take them out of the public domain. This exclusion of
rights (or perhaps "access" would be a less legalistic term) to publicly
developed resources engenders (or, a major contributing factor of) the
material conditions (inequity) that the majority of this planets
inhabitants exist under.

The hubris of private ownership has given us "Vodaphone Red" and "KLM
Blue" (both legally enforceable copyrights) the question is what possible
"choice[s], and broader benefit" to the public sphere do these give?
IBM has calculated that there are only 2.28 million discernible colors,
how many Rajistani carpet weavers would even know of this research or
what "Vodaphone" is? Regardless, the semiotic gold rush continues.

Given what we see in terms of American "pro-business" and how it shapes
foreign policy, it is not that far fetched to see the development of
the legal framework for dividing the spoils as more akin to class war
than free market.

[snip]

Post by Zach Welch
and 2) we lost someone interested in being involved on the law team
because they view this as incompatible with their desire for a 100% GPL
distribution. I was sorry to see them go, but this is an ultimate
component of the "pro-business" aspects of the distribution - one that
I believe can not afford to be ignored.

This suggests it's a done deal? Why would this person be leaving otherwise?

Post by Zach Welch
While I hope to see the marketplace shift to a mindset that fully
accepts open source software licenses, I do not believe that time will
come soon, and the existance of such opportunities for businesses does
not mean the foundation will pursue non-GPL licensing terms in any
cases. In fact, I will personally work to see that all derived works
are available under the GPL, excluding as little as possible to meet the
specific needs of businesses that desire other terms.

I would see the public domain as a priority and business as secondary,
particularly given the Zynot Foundations non-for-profit basis.

Perhaps there is more room for discussion but I for one would want to
see Zynot (both as a social organization and as a code repository)
emphasize a broader social commitment and lessen the emphasis on
business. That is not to diminish those who see their involvement
as concurrent with thier own bussiness interests, but to counter what I
believe is a systemic and unworkable social and political reality.

best

cal

-