On 01/27/2017 05:42 AM, David Woolley wrote:
> On 18/01/17 15:26, John Cowan wrote:
>> Pace David Woolley, it is not only the *changes* but the *entire*
>> derivative work of which you are the copyright owner. Of course you
>> cannot prevent the making of other derivative works under license from
On 18/01/17 15:26, John Cowan wrote:
Pace David Woolley, it is not only the *changes* but the *entire*
derivative work of which you are the copyright owner. Of course you
cannot prevent the making of other derivative works under license from
the original author.
That doesn't seem to be the US
On 18/01/2017 16:26, Christopher Sean Morrison wrote:
B's license is very flexible in terms of where the attribution notice maybe
placed.
> As long as C puts it in the documentation or other materials provided
with the distribution, it will be in compliance.
Yes now I agree with this view.
On 18/01/2017 16:26, John Cowan wrote:
it is not only the *changes* but the
*entire* derivative work of which you are the copyright owner.
Ok. The original copyright owner of A gave me the rights to use A, so I
used A for producing B (also a mere "copy"), and then I'm the copyright
owner of
On Wed, Jan 18, 2017 at 10:26 AM, Christopher Sean Morrison
wrote:
I would caution that many seemingly ordinary words can take on a different
> or more specific legal meaning in court.
Indeed. From Dorothy Sayers's novel _Unnatural Death_:
'You are too easily surprised,' said
On Wed, Jan 18, 2017 at 3:50 AM, Massimo Zaniboni <
massimo.zanib...@asterisell.com> wrote:
Sincerely I don't fully understand this sentence. Are you saying that if
> license A allows me to use, modify and distribuite the code of product A
> (like BSD, and ISC are saying), then is it implicit by
On 18/01/2017 09:01, David Woolley wrote:
Not entirely true. Only significant changes are owned by B. De minis and
obvious changes don't attract an independent copyright.
Ok.
More generally on this topic, the requirement to include the copyright
and licence in the permissive licences is
On 17/01/17 16:44, Massimo Zaniboni wrote:
every change to A made by B is automatically owned by B author, thanks
to Berne Convention
Not entirely true. Only significant changes are owned by B. De minis and
obvious changes don't attract an independent copyright.
More generally on this
On 17/01/2017 17:44, Massimo Zaniboni wrote:
"relicensing" is implicitely permitted by
Berne Convention [https://en.wikipedia.org/wiki/Berne_Convention], and
so the license text had no to repeat this.
... ehm a better version of the phrase:
"The Berne Convention states that changes made to a
On 17/01/2017 16:13, Massimo Zaniboni wrote:
On 17/01/2017 15:31, Kevin Fleming wrote:
Apache/MIT/GPL specify explicitely how you can relicense derived works:
* in GPL you mus apply the same GPL license also to derived works
* in MIT/Apache you can freely relicense the derived work, until
On 17/01/2017 15:31, Kevin Fleming wrote:
In general 'permissive' vs. 'non-permissive' applies to the obligation
to publish source code, not the obligation(s) to reproduce copyright and
license notices.
Yes, but not only this. Copyleft licenses like GPL define *also* the
license on which
In general 'permissive' vs. 'non-permissive' applies to the obligation to
publish source code, not the obligation(s) to reproduce copyright and
license notices. It is generally assumed that nearly all licenses will
incur some sort of attribution obligation, including 'permissive' licenses.
On
On 13/01/2017 22:54, Massimo Zaniboni wrote:
"Permission to use, copy, modify, and/or distribute this software for
any purpose with or without fee is hereby granted, provided that the
above copyright notice and this permission notice appear in all copies."
... or more succintly, if we have
On 13/01/2017 20:29, John Cowan wrote:
When the BSD/ISC/MIT licenses say that
you must include the text of the license in derivative works, that's
exactly what is meant: the words of the license must be provided as part
of the documentation. It does not mean that they must be incorporated
into
On 13/01/2017 19:36, Chuck Swiger wrote:
On Jan 13, 2017, at 10:05 AM, Massimo Zaniboni
wrote:
I tried interpreting the terms of common permissive licenses following a "step by step"
approach, like if they were instructions in programminng code, and I found
On Fri, Jan 13, 2017 at 1:05 PM, Massimo Zaniboni <
massimo.zanib...@asterisell.com> wrote:
Probably I'm wrong, but I'm curious to understand where. So if someone has
> the patience to read the post, can report here a fault part of my
> reasoning, so I can understand better and maybe discuss?
source.org>] On Behalf Of Chuck Swiger
> Sent: Friday, January 13, 2017 10:37 AM
> To: license-discuss@opensource.org <mailto:license-discuss@opensource.org>
> Subject: Re: [License-discuss] step by step interpretation of common
> permissive licenses
>
> On Jan 13, 2017, at
rom: License-discuss [mailto:license-discuss-boun...@opensource.org] On Behalf
Of Chuck Swiger
Sent: Friday, January 13, 2017 10:37 AM
To: license-discuss@opensource.org
Subject: Re: [License-discuss] step by step interpretation of common permissive
licenses
On Jan 13, 2017, at 10:05 AM, Massimo Za
On Jan 13, 2017, at 10:05 AM, Massimo Zaniboni
wrote:
> I tried interpreting the terms of common permissive licenses following a
> "step by step" approach, like if they were instructions in programminng code,
> and I found with my big surprises that doing so
Hi,
I tried interpreting the terms of common permissive licenses following a
"step by step" approach, like if they were instructions in programminng
code, and I found with my big surprises that doing so they became non
permissive licenses, or permissive licenses only using some
"border-line"
20 matches
Mail list logo