| Author |
Message |
|
| Guest |
 Posted: Thu Apr 10, 2008 8:09 am |
 |
|
|
Guest
|
Il giorno mer, 09/04/2008 alle 11.02 -0600, Brian Granger ha scritto:
> The biggest problem is that GPL code can't be used in open source BSD
> style projects (the GPL would require releasing the resulting work
> under the GPL license). Perfect example: Erlang is not GPL. Thus
> Erlang cannot be distributed with code that links to or uses GPL code:
> readline and FFTW begin examples.
>
> If you were to release your project under the GPL, anyone who wants to
> use it may have to release their code under the GPL (even if it is
> open source (BSD, MIT, etc.)) (unless you include a special runtime
> exception, but that gets pretty subtle).
This is wrong.
In general, when you create a software product that depends on existing
libraries, then you must comply with *all* the licenses of these
libraries --- MIT, GNU GPL, BSD, proprietary, whatever. Otherwise, you
are not allowed to use them at all.
The GNU GPL does *not* require that the linked software is released (or
re-licensed) under the terms of the GNU GPL itself.
But the copyright law *does* require that the final product (new code +
libraries) complies with all the involved software licenses. And since
the GNU GPL (either v2 or v3) prohibits that additional restrictions are
placed on resulting software, then the final product cannot be
distributed under a proprietary, restrictive license.
If there are no such additional restrictions, then there are no problems
at all; and if the final product is composed by GNU GPL-compatible
licenses, then there are no such additional restrictions.
Practical example:
* "libfoo" is GNU GPL'ed;
* program "bar" depends on libfoo;
* therefore, "bar" must be released under *any* GNU GPL-compatible
license --- otherwise the "libfoo+bar" bundle is not legally
usable/distributable at all.
"bar" could thus be released under the terms of the MIT or BSD license.
If someone modifies it and removes the "libfoo" dependency, or replaces
"libfoo" with a non-GPL'ed version, then the GNU GPL conditions do not
apply anymore, and future users of "bar" will be able to make it
proprietary, add restrictive licensing terms, etc.
In other words, the GNU GPL is not "viral" (as someone else wrote on
this thread), or at least is not any more viral than any other software
license.
> Bottom line: if you want your code to play well with other open
> source project that don't use the GPL, pick something like the
> BSD/MIT/MPL.
...or, in general, choose any GNU GPL-compatible license 
Regards,
alceste
--
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: Thu Apr 10, 2008 8:46 am |
|
|
|
Guest
|
Alceste Scalas wrote:
> The GNU GPL does *not* require that the linked software is released (or
> re-licensed) under the terms of the GNU GPL itself.
Really? Here's what the GPL (v2) says:
"You may modify your copy or copies of the Program or any portion of it,
thus forming a work based on the Program, and copy and distribute such
modifications or work under the terms of Section 1 above, provided that you
also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating
that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties under
the terms of this License.
c) [...]"
As far as I can see, this is rather clear: *if* you distribute the derived
work, then all of it *has* to be provided under the GPL ("this License"),
There are some exceptions, such as if you distribute only the parts you have
written:
"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."
The LGPL differs in that it does not consider code that merely links to your
program to be a derived work. Is that what you meant?
/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: Thu Apr 10, 2008 9:06 am |
|
|
|
Guest
|
> The GNU GPL does *not* require that the linked software is released (or
> re-licensed) under the terms of the GNU GPL itself.
In fact, there there is a paragraph in GNU GPL that seems to define when
it is not necessary to use GPL in your work using a GPL software:
A compilation of a covered work with other separate and
independent works, which are not by their nature extensions of
the covered work, and which are not combined with it such as to
form a larger program, in or on a volume of a storage or
distribution medium, is called an “aggregate” if the compilation
and its resulting copyright are not used to limit the access or
legal rights of the compilation's users beyond what the
individual works permit. Inclusion of a covered work in an
aggregate does not cause this License to apply to the other
parts of the aggregate.
Assume that Erlang is linked against a GPL lib. Is that an aggregation?
(Then no GPL is necessary) Or it "is combined with it such as to form a
larger program" (Then Erlang seems to be requested to use GPL)? It is
far too fuzzy for me.
> But the copyright law *does* require that the final product (new code +
> libraries) complies with all the involved software licenses. And since
> the GNU GPL (either v2 or v3) prohibits that additional restrictions are
> placed on resulting software, then the final product cannot be
> distributed under a proprietary, restrictive license.
>
> If there are no such additional restrictions, then there are no problems
> at all; and if the final product is composed by GNU GPL-compatible
> licenses, then there are no such additional restrictions.
>
> Practical example:
>
> * "libfoo" is GNU GPL'ed;
> * program "bar" depends on libfoo;
> * therefore, "bar" must be released under *any* GNU GPL-compatible
> license --- otherwise the "libfoo+bar" bundle is not legally
> usable/distributable at all.
>
> "bar" could thus be released under the terms of the MIT or BSD license.
> If someone modifies it and removes the "libfoo" dependency, or replaces
> "libfoo" with a non-GPL'ed version, then the GNU GPL conditions do not
> apply anymore, and future users of "bar" will be able to make it
> proprietary, add restrictive licensing terms, etc.
>
> In other words, the GNU GPL is not "viral" (as someone else wrote on
> this thread), or at least is not any more viral than any other software
> license.
>
>
> > Bottom line: if you want your code to play well with other open
> > source project that don't use the GPL, pick something like the
> > BSD/MIT/MPL.
>
> ...or, in general, choose any GNU GPL-compatible license
>
> Regards,
>
> alceste
_______________________________________________
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: Thu Apr 10, 2008 9:18 am |
|
|
|
Guest
|
Il giorno gio, 10/04/2008 alle 10.45 +0200, Richard Carlsson ha scritto:
> Alceste Scalas wrote:
> > The GNU GPL does *not* require that the linked software is released (or
> > re-licensed) under the terms of the GNU GPL itself.
>
> Really? Here's what the GPL (v2) says:
>
> b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any part
> thereof, to be licensed as a whole at no charge to all third parties
> under the terms of this License.
>
> As far as I can see, this is rather clear: *if* you distribute the derived
> work, then all of it *has* to be provided under the GPL ("this License"),
"As a whole" refers to the final product (as I called it in my previous
email) taken in its entirety. But it may be composed by parts (e.g.
code portions) that, taken alone, have different (albeit GNU
GPL-compatible) licenses.
In fact, as you report, the GNU GPL v2 also says that:
> "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."
The GNU GPL v3 has the same conditions with different wording.
> The LGPL differs in that it does not consider code that merely links to
> your program to be a derived work.
Well, not exactly. Under the copyright law, a program that
depends/links to a library *is* a derived work, and thus it must observe
the licensing requirements of the library itself. Unlike the GNU GPL,
the GNU LGPL does *not* require that the derived product is released "as
a whole" under compatible licensing terms --- even if it *does* require
that modifications to the library itself are released under compatible
licensing terms.
Regards,
alceste
--
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: Thu Apr 10, 2008 9:20 am |
|
|
|
Guest
|
> > The GNU GPL does *not* require that the linked software is released (or
> > re-licensed) under the terms of the GNU GPL itself.
>
> In fact, there there is a paragraph in GNU GPL that seems to define when
> it is not necessary to use GPL in your work using a GPL software:
To be clear, this is a quotation from GNU GPL (v3).
>
> A compilation of a covered work with other separate and
> independent works, which are not by their nature extensions of
> the covered work, and which are not combined with it such as to
> form a larger program, in or on a volume of a storage or
> distribution medium, is called an “aggregate” if the compilation
> and its resulting copyright are not used to limit the access or
> legal rights of the compilation's users beyond what the
> individual works permit. Inclusion of a covered work in an
> aggregate does not cause this License to apply to the other
> parts of the aggregate.
>
> Assume that Erlang is linked against a GPL lib. Is that an aggregation?
> (Then no GPL is necessary) Or it "is combined with it such as to form a
> larger program" (Then Erlang seems to be requested to use GPL)? It is
> far too fuzzy for me.
>
> > But the copyright law *does* require that the final product (new code +
> > libraries) complies with all the involved software licenses. And since
> > the GNU GPL (either v2 or v3) prohibits that additional restrictions are
> > placed on resulting software, then the final product cannot be
> > distributed under a proprietary, restrictive license.
> >
> > If there are no such additional restrictions, then there are no problems
> > at all; and if the final product is composed by GNU GPL-compatible
> > licenses, then there are no such additional restrictions.
> >
> > Practical example:
> >
> > * "libfoo" is GNU GPL'ed;
> > * program "bar" depends on libfoo;
> > * therefore, "bar" must be released under *any* GNU GPL-compatible
> > license --- otherwise the "libfoo+bar" bundle is not legally
> > usable/distributable at all.
> >
> > "bar" could thus be released under the terms of the MIT or BSD license.
> > If someone modifies it and removes the "libfoo" dependency, or replaces
> > "libfoo" with a non-GPL'ed version, then the GNU GPL conditions do not
> > apply anymore, and future users of "bar" will be able to make it
> > proprietary, add restrictive licensing terms, etc.
> >
> > In other words, the GNU GPL is not "viral" (as someone else wrote on
> > this thread), or at least is not any more viral than any other software
> > license.
> >
> >
> > > Bottom line: if you want your code to play well with other open
> > > source project that don't use the GPL, pick something like the
> > > BSD/MIT/MPL.
> >
> > ...or, in general, choose any GNU GPL-compatible license
> >
> > Regards,
> >
> > alceste
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
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: Thu Apr 10, 2008 9:42 am |
|
|
|
Guest
|
Il giorno gio, 10/04/2008 alle 10.05 +0100, Alpár Jüttner ha scritto:
> > The GNU GPL does *not* require that the linked software is released (or
> > re-licensed) under the terms of the GNU GPL itself.
>
> In fact, there there is a paragraph in GNU GPL that seems to define when
> it is not necessary to use GPL in your work using a GPL software:
> A compilation of a covered work with other separate and
> independent works, which are not by their nature extensions of
> the covered work, and which are not combined with it such as to
> form a larger program, in or on a volume of a storage or
> distribution medium, is called an “aggregate” if the compilation
> and its resulting copyright are not used to limit the access or
> legal rights of the compilation's users beyond what the
> individual works permit. Inclusion of a covered work in an
> aggregate does not cause this License to apply to the other
> parts of the aggregate.
It's a different matter: it refers to programs that do *not* depend/link
with GNU GPL'ed software. I.e. if you want to distribute a GNU GPL'ed
program in a compilation of programs with incompatible licenses, then
you are allowed to (as long as you respect the GNU GPL, of course).
> Assume that Erlang is linked against a GPL lib. Is that an aggregation?
> (Then no GPL is necessary) Or it "is combined with it such as to form a
> larger program" (Then Erlang seems to be requested to use GPL)? It is
> far too fuzzy for me.
If it was not fuzzy, we would not have lawyers around :-)
If the Erlang functionality depends on some GNU GPL'ed library (example:
GNU Readline), then the resulting program is a derived work that must
respect the terms of all the licenses involved --- including the GNU
GPL. Thus, *all* of its parts must be covered by GNU GPL-compatible
licenses.
I know (but I've not verified) that the Erlang Public License is *not*
GNU GPL-compatible, because it includes some restriction that the GNU
GPL does not impose. If this is true, then you are not legally allowed
to create a "whole" by linking EPL'ed code and GNU Readline, because you
would not be able to distribute that "whole" under the terms of the GNU
GPL.
(NOTE: "distributing under the terms of the GNU GPL" does *not* mean
"relicense all the components under the GNU GPL").
Regards,
alceste
--
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: Thu Apr 10, 2008 10:45 am |
|
|
|
Guest
|
Alpár Jüttner wrote:
> In fact, there there is a paragraph in GNU GPL that seems to define when
> it is not necessary to use GPL in your work using a GPL software:
>
> A compilation of a covered work with other separate and
> independent works, which are not by their nature extensions of
> the covered work, and which are not combined with it such as to
> form a larger program, in or on a volume of a storage or
> distribution medium, is called an “aggregate” if the compilation
> and its resulting copyright are not used to limit the access or
> legal rights of the compilation's users beyond what the
> individual works permit. Inclusion of a covered work in an
> aggregate does not cause this License to apply to the other
> parts of the aggregate.
>
> Assume that Erlang is linked against a GPL lib. Is that an aggregation?
> (Then no GPL is necessary) Or it "is combined with it such as to form a
> larger program" (Then Erlang seems to be requested to use GPL)? It is
> far too fuzzy for me.
I haven't looked at the GLP v3 until now, but interestingly, they've
removed the use of the term "derived work", and are now referring only
to "a modified version of the earlier work" or "a work based on the
earlier work", and it's harder to see exactly what this means, but the
main clues are 1) your quote above, in particular the part "separate and
independent works, which are not by their nature extensions of the covered
work, and which are not combined with it such as to form a larger program",
and 2) the last paragraph of the license: "The GNU General Public License
does not permit incorporating your program into proprietary programs. If
your program is a subroutine library, you may consider it more useful to
permit linking proprietary applications with the library. If this is what
you want to do, use the GNU Lesser General Public License instead of this
License."
From that, I'd say it's not very fuzzy: you can't link with a GPL library
(neither statically nor dynamically) without creating a "work based on"
the library, and hence, the rest of the work needs to be made available
under the GPL. An aggregation, on the other hand, would be e.g. to include
a standalone GNU program (with sources), such as gcc, along with the OTP
distribution.
/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: Thu Apr 10, 2008 11:40 am |
|
|
|
Guest
|
Alceste Scalas wrote:
>> Really? Here's what the GPL (v2) says:
>>
>> b) You must cause any work that you distribute or publish, that in
>> whole or in part contains or is derived from the Program or any part
>> thereof, to be licensed as a whole at no charge to all third parties
>> under the terms of this License.
>>
>> As far as I can see, this is rather clear: *if* you distribute the derived
>> work, then all of it *has* to be provided under the GPL ("this License"),
>
> "As a whole" refers to the final product (as I called it in my previous
> email) taken in its entirety. But it may be composed by parts (e.g.
> code portions) that, taken alone, have different (albeit GNU
> GPL-compatible) licenses.
>
> In fact, as you report, the GNU GPL v2 also says that:
>
>> "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."
>
> The GNU GPL v3 has the same conditions with different wording.
Yes, and they mean that *if* you distribute the work, *including* the GPL
parts, then *all* parts, including those that come under non-GPL (but
compatible) licenses, must be made available *under the GPL*. (Assuming
all involved licenses allow the combination to be made.)
Hence, the only way a license can be GPL-compatible is if it allows
redistribution under GPL. Quoted from www.gnu.org GPL-faq:
"What does it mean to say a license is “compatible with the GPL?”
- It means that the other license and the GNU GPL are compatible; you
can combine code released under the other license with code released
under the GNU GPL in one larger program.
All GNU GPL versions permit such combinations privately; they also
permit distribution of such combinations provided the combination is
released under the same GNU GPL version. The other license is compatible
with the GPL if it permits this too."
Note: "provided the combination is released under the same GNU GPL version".
*Not* just any "GNU GPL-compatible licenses" as you wrote.
The EPL is not GPL-compatible, and Erlang modules are dynamically linked,
so it is not possible to use GPL:ed Erlang modules if you want to distribute
the result. LGPL should be ok for Erlang code, however.
>> The LGPL differs in that it does not consider code that merely links to
>> your program to be a derived work.
>
> Well, not exactly. Under the copyright law, a program that
> depends/links to a library *is* a derived work,
Which "the copyright law"? Quote, please.
> Unlike the GNU GPL, the GNU LGPL does *not* require that the derived product
> is released "as a whole" under compatible licensing terms
No, in fact the LGPL quite explicitly says what a derived work is:
'Pay close attention to the difference between a "work based on the
library" and a "work that uses the library". The former contains code
derived from the library, whereas the latter must be combined with the
library in order to run.'
and
'A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked with
it, is called a "work that uses the Library". Such a work, in isolation,
is not a derivative work of the Library, and therefore falls outside the
scope of this License.
However, linking a "work that uses the Library" with the Library creates
an executable that is a derivative of the Library (because it contains
portions of the Library), rather than a "work that uses the library". The
executable is therefore covered by this License.'
So, if something qualifies as a "derived work" under the LGPL, then it
*must* be licensed under LGPL. Examples are: 1) modifications/extensions
to the library itself, and 2) a statically linked/combined program.
Otherwise, the code is "a work that uses the Library", and in that case the
LGPL does not affect it: "...is not a derivative work of the Library, and
therefore falls outside the scope of this License". Example: code that
links dynamically to a separately compiled LGPL library. (E.g., tricks
like compile-time module merging are technically not allowed.)
The bottom line is that the GPL most definitely is "viral" (but in a good
way). It divides code into two distinct worlds: The GPL code is free
forever, and you can only build on it if you agree to keeping the results
free. Otherwise, you must go find some other code to build on if you want
a free ride. GPL is not what everyone wants, but there are other licenses.
/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: Thu Apr 10, 2008 12:39 pm |
|
|
|
Guest
|
Il giorno gio, 10/04/2008 alle 13.39 +0200, Richard Carlsson ha scritto:
> Yes, and they mean that *if* you distribute the work, *including* the GPL
> parts, then *all* parts, including those that come under non-GPL (but
> compatible) licenses, must be made available *under the GPL*. (Assuming
> all involved licenses allow the combination to be made.)
>
> Hence, the only way a license can be GPL-compatible is if it allows
> redistribution under GPL.
Yes. Maybe we were trying to say the same thing.
There is one point that I wanted to clarify, though (based on the wrong
GNU GPL assumptions that started this sub-thread): the GNU GPL does
*not* require you to license (or re-license) your code under the GNU GPL
itself. If your code is under a MIT-like license, it won't be
"infected".
> "What does it mean to say a license is “compatible with the GPL?”
> - It means that the other license and the GNU GPL are compatible; you
> can combine code released under the other license with code released
> under the GNU GPL in one larger program.
>
> All GNU GPL versions permit such combinations privately; they also
> permit distribution of such combinations provided the combination is
> released under the same GNU GPL version. The other license is compatible
> with the GPL if it permits this too."
>
> Note: "provided the combination is released under the same GNU GPL version".
> *Not* just any "GNU GPL-compatible licenses" as you wrote.
Yes, it refers to the combination "as a whole". But, as I wrote, its
parts taken alone may be covered by different, GNU GPL-compatible
licenses. If program "bar" is under MIT and depends on the GNU GPL'ed
"libfoo", then "bar + libfoo" must be distributed complying with the
terms of the GNU GPL. This fact, however, does not require to
change/infect the license of "bar" taken alone.
> The EPL is not GPL-compatible, and Erlang modules are dynamically linked,
> so it is not possible to use GPL:ed Erlang modules if you want to distribute
> the result. LGPL should be ok for Erlang code, however.
But Erlang does *not* derive/depend on GNU GPL'ed modules: it just has
the capability to load them and make them available to Erlang programs.
The GNU GPL FAQ suggests a different conclusion about GNU GPL'ed Erlang
modules:
If a programming language interpreter is released under the GPL,
does that mean programs written to be interpreted by it must be
under GPL-compatible licenses?
[...]
[W]hen the interpreter is extended to provide “bindings”
to other facilities (often, but not necessarily,
libraries), the interpreted program is effectively
linked to the facilities it uses through these bindings.
So if these facilities are released under the GPL, the
interpreted program that uses them must be released in a
GPL-compatible way. The JNI or Java Native Interface is
an example of such a binding mechanism; libraries that
are accessed in this way are linked dynamically with the
Java programs that call them. These libraries are also
linked with the interpreter. If the interpreter is
linked statically with these libraries, or if it is
designed to link dynamically with these specific
libraries, then it too needs to be released in a
GPL-compatible way.
Thus, you *can* develop GNU GPL'ed Erlang modules, or modules that link
to GNU GPL libraries, and load them on the Erlang VM. But the Erlang
programs that actually link/depend on them must be released under a GNU
GPL-compatible license.
> > Under the copyright law, a program that depends/links to a library
> > *is* a derived work,
>
> Which "the copyright law"? Quote, please.
>
> > Unlike the GNU GPL, the GNU LGPL does *not* require that the derived
> > product is released "as a whole" under compatible licensing terms
>
> No, in fact the LGPL quite explicitly says what a derived work is: [...]
D'oh, you're right. I did not check the license, and remembered it
wrong...
Regards,
alceste
--
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: Thu Apr 10, 2008 2:46 pm |
|
|
|
Guest
|
Just for reference:
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
But, mind you, I don't think that everyone agrees with this
interpretation and it this (as far as I know) has not been tested in
court.
This is one of the problems I have with the GPL though - it is
complicated enough that I am not sure what it says exactly.
Cheers,
Brian
On Thu, Apr 10, 2008 at 6:37 AM, Alceste Scalas <alceste@crs4.it> wrote:
> Il giorno gio, 10/04/2008 alle 13.39 +0200, Richard Carlsson ha scritto:
>
> > Yes, and they mean that *if* you distribute the work, *including* the GPL
> > parts, then *all* parts, including those that come under non-GPL (but
> > compatible) licenses, must be made available *under the GPL*. (Assuming
> > all involved licenses allow the combination to be made.)
> >
> > Hence, the only way a license can be GPL-compatible is if it allows
> > redistribution under GPL.
>
> Yes. Maybe we were trying to say the same thing.
>
> There is one point that I wanted to clarify, though (based on the wrong
> GNU GPL assumptions that started this sub-thread): the GNU GPL does
> *not* require you to license (or re-license) your code under the GNU GPL
> itself. If your code is under a MIT-like license, it won't be
> "infected".
>
>
>
> > "What does it mean to say a license is "compatible with the GPL?"
> > - It means that the other license and the GNU GPL are compatible; you
> > can combine code released under the other license with code released
> > under the GNU GPL in one larger program.
> >
> > All GNU GPL versions permit such combinations privately; they also
> > permit distribution of such combinations provided the combination is
> > released under the same GNU GPL version. The other license is compatible
> > with the GPL if it permits this too."
> >
> > Note: "provided the combination is released under the same GNU GPL version".
> > *Not* just any "GNU GPL-compatible licenses" as you wrote.
>
> Yes, it refers to the combination "as a whole". But, as I wrote, its
> parts taken alone may be covered by different, GNU GPL-compatible
> licenses. If program "bar" is under MIT and depends on the GNU GPL'ed
> "libfoo", then "bar + libfoo" must be distributed complying with the
> terms of the GNU GPL. This fact, however, does not require to
> change/infect the license of "bar" taken alone.
>
>
>
> > The EPL is not GPL-compatible, and Erlang modules are dynamically linked,
> > so it is not possible to use GPL:ed Erlang modules if you want to distribute
> > the result. LGPL should be ok for Erlang code, however.
>
> But Erlang does *not* derive/depend on GNU GPL'ed modules: it just has
> the capability to load them and make them available to Erlang programs.
>
> The GNU GPL FAQ suggests a different conclusion about GNU GPL'ed Erlang
> modules:
>
> If a programming language interpreter is released under the GPL,
> does that mean programs written to be interpreted by it must be
> under GPL-compatible licenses?
>
> [...]
> [W]hen the interpreter is extended to provide "bindings"
> to other facilities (often, but not necessarily,
> libraries), the interpreted program is effectively
> linked to the facilities it uses through these bindings.
> So if these facilities are released under the GPL, the
> interpreted program that uses them must be released in a
> GPL-compatible way. The JNI or Java Native Interface is
> an example of such a binding mechanism; libraries that
> are accessed in this way are linked dynamically with the
> Java programs that call them. These libraries are also
> linked with the interpreter. If the interpreter is
> linked statically with these libraries, or if it is
> designed to link dynamically with these specific
> libraries, then it too needs to be released in a
> GPL-compatible way.
>
> Thus, you *can* develop GNU GPL'ed Erlang modules, or modules that link
> to GNU GPL libraries, and load them on the Erlang VM. But the Erlang
> programs that actually link/depend on them must be released under a GNU
> GPL-compatible license.
>
>
>
> > > Under the copyright law, a program that depends/links to a library
> > > *is* a derived work,
> >
> > Which "the copyright law"? Quote, please.
> >
> > > Unlike the GNU GPL, the GNU LGPL does *not* require that the derived
> > > product is released "as a whole" under compatible licensing terms
> >
> > No, in fact the LGPL quite explicitly says what a derived work is: [...]
>
> D'oh, you're right. I did not check the license, and remembered it
> wrong...
>
>
> Regards,
>
> alceste
> --
> 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
_______________________________________________
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: Thu Apr 10, 2008 5:26 pm |
|
|
|
Guest
|
Alceste Scalas wrote:
> But Erlang does *not* derive/depend on GNU GPL'ed modules: it just has
> the capability to load them and make them available to Erlang programs.
>
> The GNU GPL FAQ suggests a different conclusion about GNU GPL'ed Erlang
> modules:
>
> If a programming language interpreter is released under the GPL,,
> does that mean programs written to be interpreted by it must be
> under GPL-compatible licenses?
Erlang/OTP isn't released under the GPL, so this FAQ answer does not apply.
(Note that for the Java Native Interface example, Sun's main implementations
of the JVM are currently released under GPLv2.)
To answer Brian Granger's point that started this subthread:
> The biggest problem is that GPL code can't be used in open source BSD
> style projects (the GPL would require releasing the resulting work
> under the GPL license). Perfect example: Erlang is not GPL. Thus
> Erlang cannot be distributed with code that links to or uses GPL code:
> readline and FFTW begin examples.
a more relevant FAQ answer is the following one:
> I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic)
> and I will be releasing it under the GPL. Is dynamically linking my program
> with the Visual C++ (or Visual Basic) run-time library permitted under the GPL?
>
> The GPL permits this because that run-time library normally accompanies
> the compiler or interpreter you are using. The run-time libraries here
> are “System Libraries” as GPLv3 defines them, and as such they are not
> considered part of the Corresponding Source. GPLv2 has a similar exception
> in section 3.
The GPLv3 definition of "System Libraries"
<http://www.gnu.org/licenses/gpl-3.0.html> is:
The “System Libraries” of an executable work include anything, other than
the work as a whole, that (a) is included in the normal form of packaging
a Major Component, but which is not part of that Major Component, and (b)
serves only to enable use of the work with that Major Component, or to
implement a Standard Interface for which an implementation is available to
the public in source code form. A “Major Component”, in this context,
means a major essential component (kernel, window system, and so on) of
the specific operating system (if any) on which the executable work runs,
or a compiler used to produce the work, or an object code interpreter used
to run it.
An Erlang/OTP runtime is clearly "an object code interpreter used to run"
the program, therefore it is a Major Component of the program. So there is
no problem with linking parts of GPLv3-licensed Erlang programs, such as
drivers, with the relevant components of Erlang/OTP that they need to be
linked with, even when Erlang/OTP is not acting as a pure interpreter for
those programs.
Also, GPL code can be distributed with a copy of the Erlang/OTP runtime
if the result is only an "aggregate" of the code and the runtime (although
this is a slightly grey area because it could be argued in some cases that
they have been "combined [...] such as to form a larger program").
However, if a GPL-licensed program required a patch to Erlang/OTP in order
to work correctly, for example, it would not be legal to distribute the
patched Erlang/OTP source with the program.
IANAL, HTH.
--
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 9:52 am |
|
|
|
Guest
|
Il giorno gio, 10/04/2008 alle 22.17 +0200, Richard Carlsson ha scritto:
> Alceste Scalas wrote:
> > There is one point that I wanted to clarify, though (based on the wrong
> > GNU GPL assumptions that started this sub-thread): the GNU GPL does
> > *not* require you to license (or re-license) your code under the GNU GPL
> > itself. If your code is under a MIT-like license, it won't be
> > "infected".
>
> This is only true in the completely uninteresting (for this discussion)
> case when you *do not distribute* the combined work.
It *is* interesting for this discussion, because (I repeat) I started
this sub-thread in order to correct a very specific misconception:
http://erlang.org/pipermail/erlang-questions/2008-April/034274.html
If you were to release your project under the GPL,
anyone who wants to use it may have to release their
code under the GPL (even if it is open source (BSD, MIT,
etc.)) (unless you include a special runtime exception,
but that gets pretty subtle).
This is actually wrong. People are free to provide their code under any
GNU GPL-compatible license (BSD, MIT, etc.). The program "as a whole"
will need to follow the terms of the GNU GPL, *but* its parts taken
alone will retain their (GNU GPL-compatible) license. Anyone will be
free to take them, remove dependencies from GNU GPL'ed code and, thus,
ignore GNU GPL terms. In other words, the code is not "tainted" or
"infected" by the GNU GPL.
It seems to me that we agreed on this point since the beginning, so the
discussion on it should be over.
I also agree (of course) with the rest of your email about proprietary
software that conflicts with the GNU GPL, but it's not related with the
subject of this sub-thread.
> The status of the Erlang/OTP distribution in relation to the code that
> runs on it was never much questioned here.
Ok, then maybe I misunderstood the following sentence:
http://erlang.org/pipermail/erlang-questions/2008-April/034307.html
The EPL is not GPL-compatible, and Erlang modules are
dynamically linked, so it is not possible to use GPL:ed
Erlang modules if you want to distribute the result.
LGPL should be ok for Erlang code, however.
I interpreted it as: "you cannot develop GNU GPL'ed Erlang modules, or
modules that depend on them, because they would be incompatible with the
EPL'ed Erlang runtime". I was explaining why it was not the case (and
the end of the GNU GPL FAQ passage I quoted referred to this specific
problem).
But maybe you just meant that EPL'ed modules cannot depend on GNU GPL'ed
libraries/drivers/modules... If this is the case, then (of course) I do
agree with you.
Regards,
alceste
--
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 9:53 am |
|
|
|
Guest
|
David-Sarah Hopwood wrote:
> An Erlang/OTP runtime is clearly "an object code interpreter used to run"
> the program, therefore it is a Major Component of the program. So there is
> no problem with linking parts of GPLv3-licensed Erlang programs, such as
> drivers, with the relevant components of Erlang/OTP that they need to be
> linked with, even when Erlang/OTP is not acting as a pure interpreter for
> those programs.
Yes, I think there can be very little doubt that the Erlang/OTP runtime
system and the included standard library modules are not affected by
compiling and running GPL:ed modules, or packaging the OTP distribution
with GPL:ed code, any more than a JVM+libraries would be affected by
being shipped along with a GPL Java application.
Hence, the compatibility of GPL with the EPL as used in the runtime
system and libraries is simply not an issue. But if some people are
using the EPL for their own Erlang projects, and want to call GPL:ed
modules, any (in)compatibility would have to be considered.
> Also, GPL code can be distributed with a copy of the Erlang/OTP runtime
> if the result is only an "aggregate" of the code and the runtime (although
> this is a slightly grey area because it could be argued in some cases that
> they have been "combined [...] such as to form a larger program").
As long as the Erlang/OTP runtime is just a general infrastructure that
the GPL code happens to run on, I think it is fairly clear that they are
not considered to be combined (but I'm no lawyer either).
> However, if a GPL-licensed program required a patch to Erlang/OTP in order
> to work correctly, for example, it would not be legal to distribute the
> patched Erlang/OTP source with the program.
Quite. And a linked-in port driver, providing e.g. a Qt-binding or
somesuch, which is published (the driver code) under GPL, would force
Erlang modules that depend on the port driver to also be GPL:ed.
/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 9:53 am |
|
|
|
Guest
|
Alceste Scalas wrote:
> Il giorno gio, 10/04/2008 alle 13.39 +0200, Richard Carlsson ha scritto:
>> Yes, and they mean that *if* you distribute the work, *including* the GPL
>> parts, then *all* parts, including those that come under non-GPL (but
>> compatible) licenses, must be made available *under the GPL*. (Assuming
>> all involved licenses allow the combination to be made.)
>>
>> Hence, the only way a license can be GPL-compatible is if it allows
>> redistribution under GPL.
>
> Yes. Maybe we were trying to say the same thing.
>
> There is one point that I wanted to clarify, though (based on the wrong
> GNU GPL assumptions that started this sub-thread): the GNU GPL does
> *not* require you to license (or re-license) your code under the GNU GPL
> itself. If your code is under a MIT-like license, it won't be
> "infected".
This is only true in the completely uninteresting (for this discussion)
case when you *do not distribute* the combined work. As soon as you do,
however, you *must* make the whole work available under the GPL. If some
parts are (only) distributed under an incompatible license (that does
not allow re-licensing or adds restrictions), they *cannot* be combined
and distributed. (I suppose that it is allowed to combine them for
personal or company-internal purposes, but I can't be bothered to
research that point right now.)
If you are a software company, and one of your employees by sheer
ignorance uses GPL software in your product, and you ship that product,
then the only way you can avoid violating the GPL is to publish all
your source code for that product. It is most definitely "viral" in
that sense. If you don't want people to see your code, you need to
be fairly careful about using free software.
(I'm not condoning any particular behaviour here, just describing
some realities of software companies. There are many reasons, good
and bad, for not wanting to show your code to the world.)
> Yes, it refers to the combination "as a whole". But, as I wrote, its
> parts taken alone may be covered by different, GNU GPL-compatible
> licenses. If program "bar" is under MIT and depends on the GNU GPL'ed
> "libfoo", then "bar + libfoo" must be distributed complying with the
> terms of the GNU GPL. This fact, however, does not require to
> change/infect the license of "bar" taken alone.
That is entirely uninteresting, because it *does* force you to
distribute "bar" under the GPL (when you ship it with libfoo).
Once you've done that, it is officially free software, and anyone
can keep using and modifying that source code (under the GPL).
But it does not force the copyright owner of "bar" to publish that work
only under the GPL from now on, that much is true; and if he modifies
"bar" to "bar2" which does not use libfoo, then bar2 does not have to be
GPL:ed if it is distributed. But this is really of minor interest.
The main thing is that if you don't *want* your code to be licensed
under GPL at all, then you *cannot* link it with GPL software.
> But Erlang does *not* derive/depend on GNU GPL'ed modules: it just has
> the capability to load them and make them available to Erlang programs.
> [...]
Anyhow, the text you quoted does not apply here (the Erlang interpreter
is not published under GPL), but the paragraphs that followed is just as
valid for Erlang as for Perl or Java:
"Another similar and very common case is to provide libraries with the
interpreter which are themselves interpreted. For instance, Perl comes
with many Perl modules, and a Java implementation comes with many Java
classes. These libraries and the programs that call them are always
dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java
classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on."
A language interpreter and its runtime system and libraries are not
affected by the code running under it, just like an operating system
(Windows does not violate the GPL just because you run Gimp on it),
but the modules being interpreted are considered as programs being
linked to each other.
> Thus, you *can* develop GNU GPL'ed Erlang modules, or modules that
> link to GNU GPL libraries, and load them on the Erlang VM. But the
> Erlang programs that actually link/depend on them must be released
> under a GNU GPL-compatible license.
Just so. But the status of the Erlang/OTP distribution in relation
to the code that runs on it was never much questioned here.
/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 1:02 pm |
|
|
|
Guest
|
Alceste Scalas wrote:
> It *is* interesting for this discussion, because (I repeat) I started
> this sub-thread in order to correct a very specific misconception:
>
> http://erlang.org/pipermail/erlang-questions/2008-April/034274.html
> If you were to release your project under the GPL,
> anyone who wants to use it may have to release their
> code under the GPL (even if it is open source (BSD, MIT,
> etc.)) (unless you include a special runtime exception,
> but that gets pretty subtle).
>
> This is actually wrong. People are free to provide their code under any
> GNU GPL-compatible license (BSD, MIT, etc.). The program "as a whole"
> will need to follow the terms of the GNU GPL, *but* its parts taken
> alone will retain their (GNU GPL-compatible) license. Anyone will be
> free to take them, remove dependencies from GNU GPL'ed code and, thus,
> ignore GNU GPL terms. In other words, the code is not "tainted" or
> "infected" by the GNU GPL.
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*. 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.
> Ok, then maybe I misunderstood the following sentence:
>
> http://erlang.org/pipermail/erlang-questions/2008-April/034307.html
> The EPL is not GPL-compatible, and Erlang modules are
> dynamically linked, so it is not possible to use GPL:ed
> Erlang modules if you want to distribute the result.
> LGPL should be ok for Erlang code, however.
>
> I interpreted it as: "you cannot develop GNU GPL'ed Erlang modules, or
> modules that depend on them, because they would be incompatible with the
> EPL'ed Erlang runtime". I was explaining why it was not the case (and
> the end of the GNU GPL FAQ passage I quoted referred to this specific
> problem).
Well, I was not making a very clear statement. When I wrote that, I wasn't
referring to the Erlang/OTP distribution itself, but about third-party code
that uses the EPL (for some reason) and would like to use your code. Sorry
about the confusion.
/Richard
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 2
Goto page 1, 2 Next
|
|
|
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
