Mailing List Archive

Code contributions
Holger Schurig <holger@d.om.org> writes:

> However, I tried to get some answer from FSF.ORG, from "info
> standards" and also from Werner WHAT to actually sign, but never really
> with any usable response. "info standards" for example just says:

I apoligize, if didn't send you more information; usually I do this
with the answer but sometimes I simply forget to attach the file.

I don't know why these papers are not online available - maybe
because there wording is occasionally changed - I don't know.

Anyway, here is the file conditions.text and if you like to see the
mentioned files, I can mail them too.

====8<=================================================================
Legal Issues about Contributing Code to GNU last updated 3 Mar 98

Project GNU has to be careful to obey intellectual property laws, even
though these laws are wrong and people generally should share useful
information without hesitation, because we are in the public eye.

This means that if you want to contribute software, you have to do
something to give us legal permission to use it. There are four ways
this can be done:

* Assign the copyright to the Free Software Foundation.
This is what we prefer because it allows us to use the copyright law
to prevent others from hoarding modified versions of the program.

* Keep the copyright yourself and give us a suitable nonexclusive
license. It will then be up to you to prevent any unauthorized
hoarding of modified versions; we will be unable to act. (This
alternative is impractical for us if the use for your work is to be
merged into a preexisting GNU program.)

* Keep the copyright and release the program yourself under the GNU
GPL. (This alternative too is impractical for contributions to a
preexisting GNU program.)

* Put the code in the public domain. Then there is nothing to stop hoarding
of modified versions, but we can still use the program in GNU.

Most of these alternatives require a signed piece of paper to make it
happen.

* Assigning copyright.

Assigning the copyright means signing a contract that makes the Free
Software Foundation the "owner" of the program according to the law.
As the copyright holder, the Foundation can sue anyone who tries to
distribute the program as a proprietary product. We are willing to
keep your name on the program as the author for as long as the program
remains recognizably distinct. ("Owner" is in quotes to show that we
don't really believe in this kind of ownership. We are against the
copyright law, because it is intended to assist information hoarding,
but since we cannot get it repealed just yet, we use it to stop
hoarding when we can.)

The assignment contract commits the foundation to setting distribution
terms that permit free redistribution.

Often we don't want to do the work of starting to distribute a program
right away. There are many things which we will need in order to have
a complete system but which aren't really useful until the rest of the
system is done. But signing the assignment does not stop you from
distributing the program yourself--as long as you do so under the GNU
terms. You don't have to wait for us to start distributing. You can
start distributing as soon as you attach our standard copyleft to the
files. (Ask for our advice on how to do this.)

The assignment contract we normally use has a clause that permits you
to use your code in proprietary programs, on 30 days' notice. (The 30
days' notice is there because, through a legal technicality, it would
improve our position in a suit against a hoarder.) Although we
believe that proprietary software is wrong, we include this clause
because it would serve no purpose to ask you to promise not to do it.
You're giving us a gift in the first place.

You don't need to invoke this clause in order to distribute copies as
free software under the GNU GPL, since everyone is allowed to do that.

* Keeping the copyright.

Keeping the copyright and giving the Free Software Foundation a
nonexclusive license also requires signing a contract. The license we
need permits us to add our usual distribution terms; it recognizes
possession of a copy with our distribution terms accurately stated as
licensing anyone to redistribute on those terms. However, if someone
violates these terms--for example, if he gets a copy from us, and uses
it as a basis for a proprietary product in violation of our terms--we
cannot sue him. You have to sue, or he gets away with it.

The law doesn't recognize the idea that he, by doing this, is stealing
rights from the public; it thinks that information exists to be
hoarded and is concerned only with how the spoils are to be divided.

* Releasing it yourself.

You can release a program yourself under copyleft distribution terms
such as the GNU GPL. (In order to accept the program as GNU software,
we would have to be happy with your choice of terms.) This does not
require a contract between you and the FSF, but we would appreciate
having a signed piece of paper to confirm your decision.

If someone violates your terms--for example, if someone gets a copy
from us, and uses it as a basis for a proprietary product in violation
of the terms--we cannot sue him. You would have to sue, or he gets
away with it.

* Public domain.

If you put the program in the public domain, we prefer to have a signed
piece of paper--a disclaimer of rights--from you confirming this. If the
program is not very important, we can do without one; the worst that could
happen is that we might some day be forced to stop using it.

The law says that anyone can copyright a modified version of the public
domain work. (This doesn't restrict the original, which remains in the
public domain; only the changes are copyrighted.) If we make extensive
changes, we will probably do this and add our usual copyleft. If we make
small changes, we will leave the version we distribute in the public
domain.

* What about your employer?

If you are employed to do programming, or have made an agreement with your
employer that says it owns programs you write, we need a signed piece of
paper from your employer disclaiming rights to the program. It should be
signed by a vice president or general manager of the company. If you
can't get at them, it is almost as good to find someone who signs licenses
for software that is purchased. Here is a sample wording:

Digital Stimulation Corporation hereby disclaims all copyright interest
in the program "seduce.el" (a program to direct assemblers to make passes
at compilers under GNU Emacs) written by Hugh Heffner.

<signature of Ty Coon>, 1 April 1987
Ty Coon, President of Vice, Digital Stimulation Corp.

The description of what the program does is just to make it clearer
what the disclaimer covers.

If what you did was change an existing program, it should say this:

...in the changes and enhancements made by Hugh Heffner to the
program "seduce.el".

* Did anyone else contribute?

If someone else contributed more than a few lines here or there to the
program, then that person too is an author, and that person too needs to
sign papers just as you do. So may that person's employer. However, if
his contribution is just a fraction of the whole work, it is satisfactory
if he disclaims his own rights, even if you are assigning yours. (If just
the minor contributors' work goes in the public domain, that doesn't leave
much of a loophole for hoarders.)

If you incorporated packages which you found floating around as "public
domain", we might still want to track down their authors, to get
disclaimers to reassure us that they really are in the public domain. So
keep track of what these packages are and who wrote them.

* A reminder:

In working on a project for GNU, DO NOT study and follow any Unix
sources or other non-free software that might have any bearing on the
project. Don't refer to them at all, unless you are forced to for
non-GNU reasons.

Especially, if you are working on an imitation of a Unix utility, DO
NOT refer to the source for that utility.

It is not considered a serious problem if you have read Unix sources
in the past for other purposes, provided you don't copy anything in
particular from them. But referring to them while you do the work
could cause us legal problems later.
Re: Code contributions [ In reply to ]
I find it a bit disheartening that hackers have to go through so many
legal loopholes to contribute to open source software. I was not aware so
much was involved. It seems to be turning away people from contributing.
This undermines the basis on which the free software community was
founded.

Would it be more efficient to say something like, "Unless you
agree with us on other terms, all code that is contributed to the project
is copyrighted by the FSF, although you will be given credit"?

Most hackers don't want to worry about legal matters, they just want to
hack. Would it be legally binding to have such a default agreement, with
the act of contributing being acceptance of the terms? And if someone
wanted the software handled under different terms, they could sign a
contract with the FSF for a special situation.

If this is not feasable, will the FSF accept GPG DSA signed electronic
documents once gpg has stablised and become 'released`? This should be
more secure than signing a paper document, if there is some verification
so a web a trust can be built arround the DSA key.


Kirk Fort
Re: Code contributions [ In reply to ]
On Tue, Nov 10, 1998 at 10:35:53PM -0500, Kirk Fort wrote:
> I find it a bit disheartening that hackers have to go through so many
> legal loopholes to contribute to open source software. I was not aware so
> much was involved. It seems to be turning away people from contributing.
> This undermines the basis on which the free software community was
> founded.

I think the biggest problem is for those of us in the US, though.
Signing such a thing could be incriminatory.

> If this is not feasable, will the FSF accept GPG DSA signed electronic
> documents once gpg has stablised and become 'released`? This should be
> more secure than signing a paper document, if there is some verification
> so a web a trust can be built arround the DSA key.

The digital signatures should be more and more accepted with PGP
offering a real alternative to NAI's license terms. Once RSA keys die
for good or in two years when the patent won't matter, it should be even
more useful.

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Code contributions [ In reply to ]
On Tue, 10 Nov 1998, brian moore wrote:

> On Tue, Nov 10, 1998 at 10:35:53PM -0500, Kirk Fort wrote:
> > I find it a bit disheartening that hackers have to go through so many
> > legal loopholes to contribute to open source software. I was not aware so
> > much was involved. It seems to be turning away people from contributing.
> > This undermines the basis on which the free software community was
> > founded.
>
> I think the biggest problem is for those of us in the US, though.
> Signing such a thing could be incriminatory.

IANAL: The FSF takes their role of defending free software very seriously.
Unfortunately, in order to have their right to sue someone who tries to
distrubute GnuWare w/o source recognized by the (US) courts they must be
the legal copyright holder. The (US) legal system will not recognize an
assignment of copyright that isn't backed up by a contract. Therfore w/o
the paper, any lawsuit brought by the FSF would be immediately thrown out.

Warner has chosen to let the FSF use it's (much larger) resources to
protect the GnuPG source. This means he must not 'poison' the source code
by including work done by other people. The FSF's concern in this case
is that someone who contributes a large amount of code could actually sue
the FSF for distributing 'their' code. The implicit transfer of copyright
isn't strong enough by just sending a copy of the code.

It's important to note that the FSF's description is filled veiled with
anti-copyright law jabs.

C=)

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.
Re: Code contributions [ In reply to ]
On Tue, Nov 10, 1998 at 08:54:23PM -0800, Caskey L. Dickson wrote:
> On Tue, 10 Nov 1998, brian moore wrote:
>
> > I think the biggest problem is for those of us in the US, though.
> > Signing such a thing could be incriminatory.
>
> IANAL: The FSF takes their role of defending free software very seriously.
> Unfortunately, in order to have their right to sue someone who tries to
> distrubute GnuWare w/o source recognized by the (US) courts they must be
> the legal copyright holder. The (US) legal system will not recognize an
> assignment of copyright that isn't backed up by a contract. Therfore w/o
> the paper, any lawsuit brought by the FSF would be immediately thrown out.

I agree that in this lunacy run by lawyers, the signed release is
important. The problem I was pointing out, though, that in this case it
is a questionable thing for someone in the US to sign a "I agree that
the munitions I'm exporting..." sort of document.

Sort of a catch-22: if you do major work it can't be included or the
code would be compromised, but if you sign the form so it can be
included, you've admitted to a crime.

It makes it rather difficult to do much in the US except compile.

> It's important to note that the FSF's description is filled veiled with
> anti-copyright law jabs.

Good: copyrights make no sense for software. (The older I get and the
more I actually have to deal with proprietary junk, the more convinced I
am that RMS is too nice.)

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Code contributions, ITAR/EAR, incrimination vs. contribution [ In reply to ]
On Wed, 11 Nov 1998, brian moore wrote:

> On Tue, Nov 10, 1998 at 08:54:23PM -0800, Caskey L. Dickson wrote:
> > On Tue, 10 Nov 1998, brian moore wrote:
> >
> > > I think the biggest problem is for those of us in the US, though.
> > > Signing such a thing could be incriminatory.
> >
> > IANAL: The FSF takes their role of defending free software very seriously.
>
> Sort of a catch-22: if you do major work it can't be included or the
> code would be compromised, but if you sign the form so it can be
> included, you've admitted to a crime.
>
> It makes it rather difficult to do much in the US except compile.

Perhaps. The admitting to working on a project that has the potential to
be in violation of the ITAR/EAR when you upload your contributions is a
sticky problem. Otoh, provided you aren't contributing code to the core
crypto engine then you aren't really doing anything. Key management, for
instance, isn't crypto, but it is a large part of any security product.

For example, I would feel perfectly justified distributing a key server
from inside the US without concern. It is no more a crypto product than
an egg timer is a bomb, despite the fact that they go well together.

I would liken this to the various regulations regarding gun sales in the
US. Most any parts are available through mail order or OTC, but the frame
itself (stamped with a serial number) can only be bought through a
licensed gun dealer.

For GnuPG the 'frame' of the weapon is the encryption/decryption modules
(cipher.c, decrypt.c, encr-data.c, etc...) while the rest is just
supporting stuff that, in and of itself, is not in any way subject to
restriction.

Again, IANAL, and I applaud Werner's attention to detail as regards
protecting the source of GnuPG from potential 'corruption' that would
subvert the goals of GnuWare.

C=)

P.S. (unrelated) For those looking, I haven't yet updated my RPM spec page
with the latest work sent by Ross Golder, I hope to have time today.

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.
Re: Code contributions, ITAR/EAR, incrimination vs. contribution [ In reply to ]
On Wed, Nov 11, 1998 at 05:14:38PM -0800, Caskey L. Dickson wrote:
> On Wed, 11 Nov 1998, brian moore wrote:
>
> > On Tue, Nov 10, 1998 at 08:54:23PM -0800, Caskey L. Dickson wrote:
> > > On Tue, 10 Nov 1998, brian moore wrote:
> > >
> > > > I think the biggest problem is for those of us in the US, though.
> > > > Signing such a thing could be incriminatory.
> > >
> > > IANAL: The FSF takes their role of defending free software very seriously.
> >
> > Sort of a catch-22: if you do major work it can't be included or the
> > code would be compromised, but if you sign the form so it can be
> > included, you've admitted to a crime.
> >
> > It makes it rather difficult to do much in the US except compile.
>
> Perhaps. The admitting to working on a project that has the potential to
> be in violation of the ITAR/EAR when you upload your contributions is a
> sticky problem. Otoh, provided you aren't contributing code to the core
> crypto engine then you aren't really doing anything. Key management, for
> instance, isn't crypto, but it is a large part of any security product.

AFAIK even exporting software that has only hooks to support crypto
software violates the ITAR/EAR rules.

Frank
Re: Code contributions, ITAR/EAR, incrimination vs. contribution [ In reply to ]
On Sat, Nov 14, 1998 at 01:44:27AM +0100, Frank J. Beckmann wrote:
> AFAIK even exporting software that has only hooks to support crypto
> software violates the ITAR/EAR rules.

Yep, which is why Apache doesn't have a simple-to-install module for
SSL, for example. (You have to patch a bunch of other stuff to be able
to use it.) Or why the 'i' mutt has been handled off-site.

Truly truly stupid.

Especially when those in the US can send crypto to Canada legally and
people in Canada don't have such silly rules. Wonder if relaying it
off a Canadian mail server would mean I sent it to Canada....

Some year we'll get a government with a clue that has the guts to tell
the truth: "We're ALLOWING crypto exports because the old policy was a
pathetic joke and only hurt the US software business and electronic
commerce."

I expect that during a very cold winter, shortly after Hell freezes
over. :(

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster