| Author |
Message |
|
| Guest |
 Posted: Fri Apr 11, 2008 1:12 pm |
 |
|
|
Guest
|
Il giorno ven, 11/04/2008 alle 13.07 +0200, Richard Carlsson ha scritto:
> "These requirements apply to the modified work as a whole. If identifiable
> sections of that work are not derived from the Program, and can be
> reasonably considered independent and separate works in themselves, then
> this License, and its terms, do not apply to those sections when you
> distribute them as separate works. But when you distribute the same
> sections as part of a whole which is a work based on the Program, the
> distribution of the whole must be on the terms of this License, whose
> permissions for other licensees extend to the entire whole, and thus to
> each and every part regardless of who wrote it."
>
> Note in particular: "the entire whole, and thus to each and every part".
> This means that if such a part was previously only published under e.g.
> an MIT license, it (the particular version used by the combined software)
> must now also be published *also* under the GPL, and can from that point on
> be used by anyone under the GPL even as an isolated component, *even if this
> is not what you as the author of the MIT-licensed part would like*. As
> far as I can tell, this is precisely what the original post means with
> "anyone who wants to use it may have to release their code under the GPL",
> and you claim that that is wrong.
Yes, I am pretty sure that this is wrong. Maybe it is necessary to
specify what "on the terms of the GNU GPL" means in the passage above.
Let's say that I have a file bar.c, released by some third party under
the (GPL-compatible) BSD license. I modify it and make it depend on
libfoo, which is GNU GPL'ed, in order to create the application gplbar.
What does it happen? Let's make two hypothesis:
A. the bar.c license is overwritten/substituted by the GNU GPL for
further redistributions, even when separated from "the whole"
gplbar;
B. the (GPL-compatible) bar.c license remains the same, except
(maybe) for the changes I made for linking libfoo. Anyway, the
resulting application must now also respect the license of the
new component (i.e. libfoo). And thus, "the whole" gplbar
application must now be distributed on the terms of the GNU GPL.
If someone later removes my changes, however, the bar.c code
will not be bound to the GNU GPL anymore.
If I understood correctly, you think that "A" is correct, while I think
that "B" is correct.
The GNU GPL passage you quoted is totally compatible with "B": it just
says that, when I distribute "the whole" gplbar, then "each and every
part" of it must give to the recipient/licensee all the permissions
given by the GNU GPL. And since every GNU GPL-compatible license *does*
offer, by definition, these permissions, then a change of license "of
each and every part" is not required [1].
The same GNU GPL passage is also compatible with "A". But, as explained
above, it does *not* *require* that the original license "of each and
every part" is substituted/overwritten by the GNU GPL, "even if this is
not what the author of the part would like".
And the lack of this requirement is good, because the
substitution/overwriting of the original license may be *illegal*: under
the copyright law of every country I know about, only the author has the
right to decide the usage conditions of the code he/she wrote --- and,
for example, the BSD license does *not* allow such relicensing [2].
The MIT license, OTOH, does allow "sublicensing", so the scenario you've
described *may* be possible for code under that license. However, it is
*not* mandatory because of some GNU GPL requirement.
Therefore, saying that GNU GPL'ed software requires to change the
license of every other code it touches/links to is *not* correct.
It is a "viral" property that the license simply does not have, and
would make it incompatible with most of the "GNU GPL-compatible"
licenses (!).
Regards,
alceste
Notes:
[1] The main pourpose of that GNU GPL paragraph is to clarify that, for
example, I can't decide to distribute "the whole" gplbar with some
binary-only parts just because their original source files, taken
alone, are under a BSD-like license: if I do this, then I'm not
guaranteeing the GNU GPL permissions "for each and every part" to
the recipient/licensee.
[2] BSD-licensed software, however, can be "proprietarized" because
the license does allow redistribution in binary form, without
sources --- provided that the proper credit is given to the
original author(s).
--
Alceste Scalas <alceste@crs4.it>
CRS4 - http://www.crs4.it/
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 11, 2008 1:44 pm |
|
|
|
Guest
|
Richard Carlsson wrote:
[...]
> I see now more exactly what it is you are saying: that the GPL would apply
> only to the combined software as a whole. But here is what the license (v2)
> actually says:
> "These requirements apply to the modified work as a whole. If identifiable
> sections of that work are not derived from the Program, and can be
> reasonably considered independent and separate works in themselves, then
> this License, and its terms, do not apply to those sections when you
> distribute them as separate works. But when you distribute the same
> sections as part of a whole which is a work based on the Program, the
> distribution of the whole must be on the terms of this License, whose
> permissions for other licensees extend to the entire whole, and thus to
> each and every part regardless of who wrote it."
>
> Note in particular: "the entire whole, and thus to each and every part".
> This means that if such a part was previously only published under e.g.
> an MIT license, it (the particular version used by the combined software)
> must now also be published *also* under the GPL, and can from that point on
> be used by anyone under the GPL even as an isolated component, *even if this
> is not what you as the author of the MIT-licensed part would like*.
Actually this is only true because the MIT license allows such publication
(and similarly for other GPL-compatible licenses). That is, the MIT license
does not limit republication under a more restrictive license, whether that
is the GPL or something else. This is not a problem.
--
David-Sarah Hopwood
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 11, 2008 1:54 pm |
|
|
|
Guest
|
Alceste Scalas wrote:
> Il giorno ven, 11/04/2008 alle 13.07 +0200, Richard Carlsson ha scritto:
>> "These requirements apply to the modified work as a whole. If identifiable
>> sections of that work are not derived from the Program, and can be
>> reasonably considered independent and separate works in themselves, then
>> this License, and its terms, do not apply to those sections when you
>> distribute them as separate works. But when you distribute the same
>> sections as part of a whole which is a work based on the Program, the
>> distribution of the whole must be on the terms of this License, whose
>> permissions for other licensees extend to the entire whole, and thus to
>> each and every part regardless of who wrote it."
>>
>> Note in particular: "the entire whole, and thus to each and every part".
>> This means that if such a part was previously only published under e.g.
>> an MIT license, it (the particular version used by the combined software)
>> must now also be published *also* under the GPL, and can from that point on
>> be used by anyone under the GPL even as an isolated component, *even if this
>> is not what you as the author of the MIT-licensed part would like*. As
>> far as I can tell, this is precisely what the original post means with
>> "anyone who wants to use it may have to release their code under the GPL",
>> and you claim that that is wrong.
>
> Yes, I am pretty sure that this is wrong. Maybe it is necessary to
> specify what "on the terms of the GNU GPL" means in the passage above.
>
> Let's say that I have a file bar.c, released by some third party under
> the (GPL-compatible) BSD license. I modify it and make it depend on
> libfoo, which is GNU GPL'ed, in order to create the application gplbar.
> What does it happen? Let's make two hypothesis:
>
> A. the bar.c license is overwritten/substituted by the GNU GPL for
> further redistributions, even when separated from "the whole"
> gplbar;
> B. the (GPL-compatible) bar.c license remains the same, except
> (maybe) for the changes I made for linking libfoo. Anyway, the
> resulting application must now also respect the license of the
> new component (i.e. libfoo). And thus, "the whole" gplbar
> application must now be distributed on the terms of the GNU GPL.
> If someone later removes my changes, however, the bar.c code
> will not be bound to the GNU GPL anymore.
>
> If I understood correctly, you think that "A" is correct, while I think
> that "B" is correct.
"A" is correct. But the GPL is a red herring here. I can take any
MIT-licensed code and redistribute it with the additional license term
"to use this code, you must give me your first-born child", for example [*]
(enforcability aside). This is not a problem, primarily because someone
can still use the code distributed under the original license, and not
give me their first-born child. The fact that the original copyright
holder(s) chose an MIT or BSD-like license entails that they accepted
the possibility of redistribution under any more restrictive license.
[*] http://en.wikipedia.org/wiki/Rumpelstiltskin
--
David-Sarah Hopwood
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 11, 2008 2:34 pm |
|
|
|
Guest
|
Alceste Scalas wrote:
> Yes, I am pretty sure that this is wrong. Maybe it is necessary to
> specify what "on the terms of the GNU GPL" means in the passage above.
I think that is clear: the entire GNU GPL, every word of it, applies.
> Let's say that I have a file bar.c, released by some third party under
> the (GPL-compatible) BSD license. I modify it and make it depend on
> libfoo, which is GNU GPL'ed, in order to create the application gplbar.
> What does it happen? Let's make two hypothesis:
>
> A. the bar.c license is overwritten/substituted by the GNU GPL for
> further redistributions, even when separated from "the whole"
> gplbar;
> B. the (GPL-compatible) bar.c license remains the same, except
> (maybe) for the changes I made for linking libfoo. Anyway, the
> resulting application must now also respect the license of the
> new component (i.e. libfoo). And thus, "the whole" gplbar
> application must now be distributed on the terms of the GNU GPL.
> If someone later removes my changes, however, the bar.c code
> will not be bound to the GNU GPL anymore.
>
> If I understood correctly, you think that "A" is correct, while I think
> that "B" is correct.
Not quite, I think that C is correct:
C. The GNU GPL is *added* to the licensing of bar.c (the version
shipped in the combined work gplbar). It does not invalidate the
existing licenses. This is why license compatibility is an issue.
The previous licenses must not contain restrictions that go against
the GPL, otherwise the programs cannot be combined and distributed.
If someone breaks out bar.c from gplbar, he must have the right to
use and distribute it under the combined licenses including GPL.
If this bar.c, modified or not, is identical to the bar.c published
separately under some other license, then it is of course legal to
also keep distributing it without GPL attached, but that does not
take away the right of people to use it *with* GPL if they want.
> a change of license "of each and every part" is not required.
Not a change, but the addition, of a GPL license is required. This is
exactly what the phrase "under the terms of this License" means. It says
nothing about replacing any existing licenses. Here's a hint from the
FAQ: "If there is no way to satisfy both licenses at once, they are
incompatible."
> And the lack of this requirement is good, because the
> substitution/overwriting of the original license may be *illegal*: under
> the copyright law of every country I know about, only the author has the
> right to decide the usage conditions of the code he/she wrote --- and,
> for example, the BSD license does *not* allow such relicensing [2].
Naturally, if the person who combines the programs and distributes them
*has no right to do so*, either because the involved licenses are
incompatible, or because that person is not allowed to relicense some
of the involved parts, then the result has no legal effect; the act would
be illegal. The "viral" part happens when you *do* have the right to
relicense the non-GPL parts: in that case you *must* relicense them if
you distribute the combined work, otherwise it is a violation of the GPL.
> Therefore, saying that GNU GPL'ed software requires to change the
> license of every other code it touches/links to is *not* correct.
>
> It is a "viral" property that the license simply does not have, and
> would make it incompatible with most of the "GNU GPL-compatible"
> licenses (!).
On the contrary, the only way a license *can* be GPL-compatible is
if it allows such relicensing. The MIT and Rodified BSD licenses,
for example, both allow this (mainly because they do not *disallow*
relicensing as long as it is in a compatible way), while the original
BSD license with its "banner" clauses is incompatible due to its extra
restrictions.
/Richard
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 11, 2008 2:48 pm |
|
|
|
Guest
|
David-Sarah Hopwood wrote:
> "A" is correct. But the GPL is a red herring here. I can take any
> MIT-licensed code and redistribute it with the additional license term
> "to use this code, you must give me your first-born child", for example [*]
> (enforcability aside). This is not a problem, primarily because someone
> can still use the code distributed under the original license, and not
> give me their first-born child. The fact that the original copyright
> holder(s) chose an MIT or BSD-like license entails that they accepted
> the possibility of redistribution under any more restrictive license.
Yes, MIT was perhaps not the best example, but it seemed to be the
most uncomplicated. A better example (to our tormented readers) would be:
You are the copyright holder of product X, which you license under the MPL
(not GPL-compatible) and you don't (for some reason) want your code to slip
into GPL-land for love or money. But some way or another, you use a GPL:ed
library Y in your product, and ship it. Some third party browses your code,
sees your use of Y, and now demands that you release all of X (at least
the version that uses Y) under the GPL. If your refuse to do that (you do
have the right to do it if you want to), you would be violating the GPL.
But that would be way too much to write. 
/Richard
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| mdempsky |
| Posted: Sun Apr 13, 2008 7:26 am |
|
|
|
User
Joined: 24 Sep 2007
Posts: 118
|
On Fri, Apr 11, 2008 at 7:33 AM, Richard Carlsson <richardc@it.uu.se> wrote:
> On the contrary, the only way a license *can* be GPL-compatible is
> if it allows such relicensing. The MIT and Rodified BSD licenses,
> for example, both allow this (mainly because they do not *disallow*
> relicensing as long as it is in a compatible way), while the original
> BSD license with its "banner" clauses is incompatible due to its extra
> restrictions.
The MIT license explicitly permits sublicensing, but the Modified BSD
license does not. I don't think your argument is legally sound.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
 
|
| mdempsky |
| Posted: Sun Apr 13, 2008 7:43 am |
|
|
|
User
Joined: 24 Sep 2007
Posts: 118
|
On Fri, Apr 11, 2008 at 6:52 AM, David-Sarah Hopwood
<david.hopwood@industrial-designers.co.uk> wrote:
> "A" is correct. But the GPL is a red herring here. I can take any
> MIT-licensed code and redistribute it with the additional license term
> "to use this code, you must give me your first-born child", for example [*]
> (enforcability aside). This is not a problem, primarily because someone
> can still use the code distributed under the original license, and not
> give me their first-born child. The fact that the original copyright
> holder(s) chose an MIT or BSD-like license entails that they accepted
> the possibility of redistribution under any more restrictive license.
The BSD license only grants use, redistribution, and modification.
The recipient of BSD licensed code is granted those rights by the
copyright owner, not by the distributor.
The MIT license also grants sublicensing (among some other rights),
but otherwise the same idea applies.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Apr 13, 2008 10:52 am |
|
|
|
Guest
|
Matthew Dempsky wrote:
> On Fri, Apr 11, 2008 at 7:33 AM, Richard Carlsson <richardc@it.uu.se> wrote:
>> On the contrary, the only way a license *can* be GPL-compatible is
>> if it allows such relicensing. The MIT and Rodified BSD licenses,
>> for example, both allow this (mainly because they do not *disallow*
>> relicensing as long as it is in a compatible way), while the original
>> BSD license with its "banner" clauses is incompatible due to its extra
>> restrictions.
>
> The MIT license explicitly permits sublicensing, but the Modified BSD
> license does not. I don't think your argument is legally sound.
Yeah, probably not in the case of BSD: it actually only allows
"redistribution and use in source and binary forms, with or without
modification", while the MIT license allows you "to deal in the
Software without restriction, [...]". Thanks for the correction.
/Richard
PS. "Rodified" was a fun word; I must use it more often.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Apr 13, 2008 1:56 pm |
|
|
|
Guest
|
Matthew Dempsky wrote:
> On Fri, Apr 11, 2008 at 6:52 AM, David-Sarah Hopwood
> <david.hopwood@industrial-designers.co.uk> wrote:
>> "A" is correct. But the GPL is a red herring here. I can take any
>> MIT-licensed code and redistribute it with the additional license term
>> "to use this code, you must give me your first-born child", for example [*]
>> (enforcability aside). This is not a problem, primarily because someone
>> can still use the code distributed under the original license, and not
>> give me their first-born child. The fact that the original copyright
>> holder(s) chose an MIT or BSD-like license entails that they accepted
>> the possibility of redistribution under any more restrictive license.
>
> The BSD license only grants use, redistribution, and modification.
> The recipient of BSD licensed code is granted those rights by the
> copyright owner, not by the distributor.
>
> The MIT license also grants sublicensing (among some other rights),
> but otherwise the same idea applies.
The above paragraph was written in the context of distributing a
derived work; "I" in that case refers to a (non-exclusive) copyright
holder. But this is not on-topic for the Erlang list, I think.
--
David Hopwood
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Apr 14, 2008 7:49 am |
|
|
|
Guest
|
Il giorno ven, 11/04/2008 alle 16.33 +0200, Richard Carlsson ha scritto:
> Alceste Scalas wrote:
> > Yes, I am pretty sure that this is wrong. Maybe it is necessary to
> > specify what "on the terms of the GNU GPL" means in the passage above.
>
> I think that is clear: the entire GNU GPL, every word of it, applies.
But *all* software released under a GNU GPL-compatible license can, by
definition, be distributed "on the terms of the GNU GPL": you just need
to apply the GNU GPL terms and abstain from further permissions.
In the case of BSD-licensed software, you should just avoid the
binary-only distribution. If you choose to do so, you're still
complying with the terms of *both* licenses, and you *don't* need
relicensing at all.
However, you and the recipients of that software will still be free to
use all the permissions given by the BSD license, and redistribute in
binary-only format. But if you choose the latter, then you won't be
allowed to distribute that software as part of a GNU GPL'ed "whole"
product.
That's why I emphasized that "distributing under the terms of the GNU
GPL" is *not* equivalent to a license change/addition/whatever, as long
as you deal with GNU GPL-compatible software.
> I think that C is correct:
>
> C. The GNU GPL is *added* to the licensing of bar.c (the
> version shipped in the combined work gplbar). It does
> not invalidate the existing licenses. This is why
> license compatibility is an issue. The previous
> licenses must not contain restrictions that go against
> the GPL, otherwise the programs cannot be combined and
> distributed.
"Adding" the GNU GPL terms to software developed by others is equivalent
to relicensing it. You need an explicit permission to do it.
> The MIT and Rodified BSD licenses, for example, both allow this
> [relicensing under the GNU GPL] (mainly because they do not
> *disallow* relicensing as long as it is in a compatible way)
But under the copyright law of every country I know about, everything
that is not explicitly permitted by the author (or the copyright holder
in general) is forbidden [1]. And the BSD license does *not* permit
such relicensing.
On the contrary, the BSD license explicitly *forbids* it, because it
says that the distribution in source form must "retain the above
copyright notice, this list of conditions and the following disclaimer".
When you "add" the GNU GPL terms to BSD-licensed software, you're
basically nullifying the 2nd condition (i.e. the one that allows
binary-only distribution).
I repeat: under your interpretation of the GNU GPL, most of the GNU
GPL-compatible licenses suddenly become incompatible. Only MIT-licensed
and public domain software could be considered compatible (maybe).
The explanations I've given so far just solve all these problems: when
you combine code and libraries for developing an application, *all* the
licenses are preserved, and the final product "as a whole" must be
distributed complying with the terms of *all* of them. And since the
GNU GPL is the stricter license in the lot, then the final product, in
all its parts, must be distributed under its terms.
But nothing is relicensed at all: when single parts of the product are
taken alone and don't depend on GNU GPL'ed software, then the GNU GPL
simply does not apply.
Regards,
alceste
Notes:
[1] Except for "fair use" clauses, when/where they apply.
--
Alceste Scalas <alceste@crs4.it>
CRS4 - http://www.crs4.it/
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| wuji |
| Posted: Sat Aug 11, 2012 1:25 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
for your appeal. There are really only three basic basic cheap replica *beep* basic arguments you can make to appeal your tax assessment.
keeps it nice and simple. See if one applies:1. The The replica designer *beep* The assessor made a mistake in describing your house. This
covers situations where the assessor made simple math mistakes. Maybe Maybe cheap Ralph Lauren Polo Maybe he got the square footage wrong (only heated, livable
should be counted), or stated that you have five bedrooms bedrooms cheap designer *beep* bedrooms when you have three. If you uncover these errors,
you – you've just upped your chances of a slam slam replica designer bags for sale slam dunk win. All you have to do is gather
and describe the errors in writing or in person.2. You You cheap replica *beep* You just bought the house for less. If you recently |
|
|
| Back to top |
|
| wuji |
| Posted: Wed Aug 29, 2012 8:00 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
the matter is I don't know the source of the the cheap polo shirts the leaks," Feinstein said. "I'm on record as being
by these leaks, and I regret my remarks are being being cheap designer *beep* being used to impugn President Obama or his commitment to
national security secrets."In a gaggle with reporters on Air Force Force cheap authentic jordans Force One, White House Press Secretary Jay Carney said the
has made clear he has no tolerance for leaks and and cheap polo ralph lauren and that two experienced prosecutors have been tasked with investigating
a situation the president takes very seriously.Romney pounced on Obama Obama buy real jordans Obama for taking a backseat on impending defense cuts that
|
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
