Rick Moen wrote:
Weren't you saying that a derived work remains a derived work, even
after all the original content has been replaced? If so, then why
should it matter if the original modules were eventually replaced by
wholly new modules that interact in wholly new ways?
Because if
John, I appreciate the trouble you've been taking on this, especially
the relevant quotations from 17 USC 103. I've been meaning to
straighten out my understanding of this matter, and really should have
read the relevant statutes. Far too much of what's said on this matter
ignores the statutes
Rick Moen wrote:
Seems almost like homeopathy, doesn't it? None of Alice's code may
remain in A1, but (as you say) its being a derived work remains, and
thus the obligation to conform to Alice's licence terms persists.
And of course the reason homeopathic pills don't work is that the
begin John Cowan quotation:
And of course the reason homeopathic pills don't work is that the efficacy of
pills depends on the current state, not the historical origin.
Don't tempt me towards an off-topic disquisition, but you'll want to
look up the "Law of Similars" and the "Law of
On Wed, 29 Nov 2000, Nelson Rush wrote:
The GPL shouldn't be used for documentation, it is intended for use with
software. I think RMS one time agreed with me on this when it came up in one
of my other projects. Which is why he created the FDL, which is specifically
designed for
begin John Cowan quotation:
Well, that's not the whole truth either. I could take a bunch of
BSD modules, create a derivative work, and license the result under
the GPL. Or under a proprietary license, for that matter.
No, not exactly (unless you _own copyright_ on those modules). I don't
John Cowan wrote:
On Wed, 29 Nov 2000, Nelson Rush wrote:
The GPL shouldn't be used for documentation, it is intended for use with
software. I think RMS one time agreed with me on this when it came up in one
of my other projects. Which is why he created the FDL, which is specifically
Rick Moen wrote:
Well, that's not the whole truth either. I could take a bunch of
BSD modules, create a derivative work, and license the result under
the GPL. Or under a proprietary license, for that matter.
No, not exactly (unless you _own copyright_ on those modules). I don't
Tom Hull wrote:
Scott Maxwell's "Linux Core Kernel Commentary" seems to argue otherwise.
This book (published by Coriolis) contains a very large extract of the
Linux source code (license GPL), followed by a short commentary (copyright,
all rights reserved). I don't know what Coriolis's
begin John Cowan quotation:
Rick Moen wrote:
Well, that's not the whole truth either. I could take a bunch of
BSD modules, create a derivative work, and license the result under
the GPL. Or under a proprietary license, for that matter.
No, not exactly (unless you _own
I wrote:
In 3b, Bob takes from X your new version of Alice's BSD codebase, and
^
maybe sends you a thank-you note.
Should be "3c".
John Cowan wrote:
Tom Hull wrote:
Scott Maxwell's "Linux Core Kernel Commentary" seems to argue otherwise.
This book (published by Coriolis) contains a very large extract of the
Linux source code (license GPL), followed by a short commentary (copyright,
all rights reserved). I don't
begin David Johnson quotation:
I think what John meant was similar to to following analogy: You are a book
publisher and wish to release an anthology. All of the short stories you wish
to include are licensed under the BSD license. You can release the anthology
under the GPL license. A
[EMAIL PROTECTED] wrote:
In the general case, if the documentation is to be freely
redistributable to a large license, a license which allows distribution
under terms at least as liberal as the software license should be
sufficient.
Indeed, but that is a general point not specific to
on Tue, Nov 28, 2000 at 01:43:59PM -0500, John Cowan ([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] wrote:
In the general case, if the documentation is to be freely
redistributable to a large license, a license which allows distribution
under terms at least as liberal as the software
[EMAIL PROTECTED] wrote:
No, it is specific to documentation, so long as the documentation
doesn't incorporate code from the project.
My point was that it is convenient for documentation and software to
be under the same license, so that the same set of persons can make
revisions to both in
We're also trying to figure out a documentation license for the Mozilla
Project. One reason we've talked about using the same license for
documentation and code is that it can be difficult to separate the two.
For example, the Help documentation is included in electronic format as
part of
On Tuesday 28 November 2000 02:26 pm, John Cowan wrote:
If the software were GPL and the doco BSD, then if anyone rewrote the
doco for greater clarity or some such, then he would be able to make
the improved version proprietary and prevent it from being distributed
with current or future
begin John Cowan quotation:
The term "relicense" should be avoided, as it leads to wifty thinking.
No one but the copyright holder can "relicense" anything, in the
sense of changing the license.
You can create a *derivative* work containing BSD parts and GPL parts,
and license the whole
on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan ([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] wrote:
Software and its accompanying documentation are generally considered two
seperate works. There is no licensing compatibility requirement between
the docs and the code. Even where
Karsten Self wrote:
on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan
([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] wrote:
[...]
The way I read 3(c), the GNU GPL refers to the program, but doesn't
preclude
its inclusion into a larger, ***nonprogram*** work:
[...]
I think section 2 has a
On Tue, 28 Nov 2000, Rick Moen wrote:
At work, I've tried to explain the matter by saying it's best to think
of a composite work as not _having_ a licence, per se: The individual
modules bear licences. The resulting composite, then, either is or is not
legally distributable, depending on
on Tue, Nov 28, 2000 at 02:43:13PM -0800, Mitchell Baker ([EMAIL PROTECTED]) wrote:
John Cowan wrote:
[EMAIL PROTECTED] wrote:
...
Software and its accompanying documentation are generally considered two
seperate works. There is no licensing compatibility requirement between
the
On Tue, 28 Nov 2000, Ben Tilly wrote:
I think section 2 has a lot to say about this. Its wording
makes no - and allows no - distinction between programs and
non-programs. However you may aggregate works together.
So even though documentation and your program are distributed
together,
Monday, November 27, 2000 7:26 AM
Subject: Free documentation licenses
I am in the process of writing a user manual and did some checking
around for
appropriate free licenses. Unfortunately, I didn't find anything
suitable.
The GFDL is just too much and contains undesired restrictions. Ot
On Sun, 26 Nov 2000, David Johnson wrote:
I am in the process of writing a user manual and did some checking around for
appropriate free licenses. Unfortunately, I didn't find anything suitable.
IMHO it makes sense to release a manual under the same license
as the software, so that it can
- Original Message -
From: "John Cowan" [EMAIL PROTECTED]
IMHO it makes sense to release a manual under the same license
as the software, so that it can be changed in synchrony with the
software.
What you have here looks like a close variant of new-BSD.
If you are releasing the
On Mon, 27 Nov 2000, SamBC wrote:
- Original Message -
From: "John Cowan" [EMAIL PROTECTED]
IMHO it makes sense to release a manual under the same license
as the software, so that it can be changed in synchrony with the
software.
What you have here looks like a close variant
- Original Message -
From: "John Cowan" [EMAIL PROTECTED]
What if, however, as in my case, you are writing standalone
documentation to software you did not produce,
The same applies. If the software can be changed under given
conditions,
it should be possible to change the
David Johnson wrote:
The Nupedia license is also unacceptable for various
reasons.
I'd be curious to hear what problems the Nupedia license has for your
project.
As a side note, we are (at the suggestion of RMS) re-considering the
GFDL for Nupedia. One major advatage that using a
on Mon, Nov 27, 2000 at 08:13:58AM -0500, John Cowan ([EMAIL PROTECTED]) wrote:
On Sun, 26 Nov 2000, David Johnson wrote:
I am in the process of writing a user manual and did some checking around for
appropriate free licenses. Unfortunately, I didn't find anything suitable.
IMHO it
On Monday 27 November 2000 05:13 am, John Cowan wrote:
IMHO it makes sense to release a manual under the same license
as the software, so that it can be changed in synchrony with the software.
What you have here looks like a close variant of new-BSD.
If you are releasing the software under
On Monday 27 November 2000 11:30 am, [EMAIL PROTECTED] wrote:
David's license is largely similar to a BSD/MIT license, and looks on
first glance to be relatively reasonable. I gather that the strong
persistance features of the GPL are not of interest to him.
For API documentation, reference
I am in the process of writing a user manual and did some checking around for
appropriate free licenses. Unfortunately, I didn't find anything suitable.
The GFDL is just too much and contains undesired restrictions. Other licenses
listed on the GNU page were not applicable either, for pretty
34 matches
Mail list logo
