conserver/LICENSES.md
2020-05-25 21:45:54 -07:00

105 lines
4.7 KiB
Markdown

License Clarification
=====================
The licenses attached to this software ([LICENSES](LICENSES)) are supposed
to paint a simple concept: that this software was built for the open source
community and they result in a license compatible with [LICENSE](LICENSE).
Unfortunately, the real world steps in and troubles can arise. This note
has been moved over from the [INSTALL](INSTALL) file:
The Debian folks have conserver distributed with the package
names of conserver-client and conserver-server. They are in
the distribution "sid" and the "non-free" part (because the
Ohio State license doesn't explicitly allow for modification to
the code, even though it's totally implied and the intention of
the author - I've even got proof in email! Oh well, can't
blame the Debian folks for being cautious - they've been burned
before, apparently).
Here's a copy of the message I exchanged with Thomas A. Fine (original
author at OSU) in 2001 that is referenced above:
Date: Wed, 27 Jun 2001 19:47:18 -0400 (EDT)
To: bryan@conserver.com
From: "Thomas A. Fine" <fine@head-cfa.harvard.edu>
Subject: Re: A conserver license question...
> Hi Tom,
>
> I had a little "problem" crop up that I was hoping you could help me
> with. A guy out in net-land is trying to put a debian package together
> of the code I've been releasing (based on your original work) and they
> don't like part of the Ohio State license. I've attached the message
> below.
>
> I'm not sure what can be done. One thought was a message from you that
> I could put with the code stating that modifications are ok would
> work. Or maybe just modifying the original license statement. Heck, I
> don't even know if either are 100% legal. Maybe I need to talk to
> someone at Ohio State.
>
> Well, if you have any ideas or suggestions, please let me know. Don't
> know if I ever got a chance to thank you for the great stuff you
> started! Thank you! ;-)
Well, if I knew then what I know now, I would have copyrighted it
under my own name, and not under OSU, and then I could change it.
Since I don't work there anymore, strictly speaking, I can't change
it.
However, IMHO, this license allows modifications, without explicitly
stating it. I can state without a doubt that this was my intention
at the time (and hence, OSU's intention, since I put in the copyright
while working for OSU).
But also, since it allows use of the source, and since the statement
required for inclusion says "includes software ..." it seems pretty
clear that modification was both allowed and expected. You can't
really use sources if you aren't changing them, and you certainly
can't include this software in some other product without making
modifications.
As I recall, I more or less used the copyright that Berkeley was using
back then for there BSD-related software, so I'm surprised there's a
problem with it.
I have to point out that version 1.2, available at
http://hea-www.harvard.edu/~fine/Tech/cs1.2/
is distributed entirely without copyright notices. Interesting, no?
So I guess I could add a copyright notice to that. But would I then
be violating the OSU copyright that I wrote for 1.1? Since it is
a different version, I could probably write a new copyright notice
and license and be free and clear.
There's also Purdue's versions of the software. It's mentioned on my
console server web page at
http://hea-www.harvard.edu/~fine/Tech/console-server.html
So, pass this on to the people you're working with and let me know how
you want to proceed.
tom
In addition, a post to the Conserver Users mailing list in May 2020 contained:
From: Paul Wise via users <users@conserver.com>
To: users@conserver.com
Subject: Re: license change?
Date: Mon, 25 May 2020 12:42:28 +0800
On Thu, 2019-07-04 at 10:20 +0200, Bryan Stansell via users wrote:
> So, it's more the lack of explicitly stating the code can be
> modified.
Since then I talked to one of RedHat's lawyers and they mentioned that
they have dealt with this problem too and also concluded that these
licenses were intended to cover modification. The current wording of
the initial part of the BSD license reflects an attempt to correct an
earlier mistake (i.e. someone pointed out the error and Berkeley added
"with or without modification"). Also the anti-endorsement clause
implies a right to modify.
Hopefully corporations (or, I suppose, their lawyers) will be happy with the
explanation above and become comfortable with the stated license.