|
|
Log in / Subscribe / Register

FSFE Welcomes New 'Software Interactions' Document From The European, Legal Network

[Posted July 19, 2010 by ris]

From:  "press-AT-fsfeurope.org" <press-AT-fsfeurope.org>
To:  press-release-AT-fsfeurope.org
Subject:  [FSFE PR][EN] FSFE Welcomes New 'Software Interactions' Document From The European, Legal Network
Date:  Mon, 19 Jul 2010 11:56:16 +0200
Message-ID:  <4C442140.5040304@fsfeurope.org>

= FSFE Welcomes New 'Software Interactions' Document From The European
Legal Network =

[Permanent URL: http://www.fsfe.org/news/2010/news-20100719-01.en.html]

FSFE is proud to welcome the release of a new educational document
on Free Software licensing.  Developed by delegates of the
European Legal Network, the document helps software developers and
lawyers by making it easier to decide under which licenses they
can distribute their work.

'Software Interactions' explains in detail when a program that
contains source code under the GNU General Public License or other
Free Software licenses needs to be distributed under the same
license, and when developers can select another license. It
includes examples of potential legal or community red lines in the
field.

Karsten Gerloff, FSFE's President, says: "While no document can
provide definitive answers for such a complex subject, today's
release is a unique collaborative effort shaped over more than a
year of debate by numerous experts.  It represents the first time
that linking has been discussed so broadly."

FSFE is taking the opportunity of this release to establish
a long-term home for network educational documents on the FSFE
Fellowship blog. This page will expand to include all of the
current and future documents released by the network, and is
intended to provide a simple way for people to locate and share
this material. The document is available at:
  https://wiki.fsfe.org/EuropeanLegalNetwork

'Software Interactions' is the second collaborative legal
knowledge released by the European Legal Network.  The first was
the Risk Grid, published in July 2009 in the 'International Free
and Open Source Software Law Review.'

FSFE has facilitated the European Legal Network since 2007.  From
humble beginnings the network has now grown to contain over 240
members from 27 countries and 4 continents, and is the largest
professional legal forum for Free Software in the world.  While
FSFE does not have editorial control over network discussions and
educational documents, we believe it provides great value to the
broader Free Software community by ensuring legal experts from
commercial, non-commercial and independent entities can share
experience and insight.

If you are a legal expert and would like to contribute to future
network activities, please contact FSFE at legal@fsfeurope.org.

== About the Free Software Foundation Europe ==

  The Free Software Foundation Europe (FSFE) is a non-profit
  non-governmental organisation active in many European countries and
  involved in many global activities. Access to software determines
  participation in a digital society.  To secure equal participation in
  the information age, as well as freedom of competition, the Free
  Software Foundation Europe (FSFE) pursues and is dedicated to the
  furthering of Free Software, defined by the freedoms to use, study,
  modify and copy. Founded in 2001, creating awareness for these issues,
  securing Free Software politically and legally, and giving people
  Freedom by supporting development of Free Software are central issues
  of the FSFE.

  http://fsfe.org/
_______________________________________________
Press-release mailing list
Press-release@fsfeurope.org
https://mail.fsfeurope.org/mailman/listinfo/press-release

to post comments

The "Permanent URL" is broken as printed

Posted Jul 19, 2010 22:09 UTC (Mon) by qubit (guest, #57802) [Link]

The URL shouldn't include the right square bracket.

Try this: http://www.fsfe.org/news/2010/news-20100719-01.en.html

questions regarding "interpreted languages"

Posted Jul 20, 2010 9:04 UTC (Tue) by wingo (guest, #26929) [Link] (5 responses)

I wonder about the part about "interpreted languages" in the full report. Their description is good, in that it allows the interpreter to compile the source code. However once the compilation happens, how is running the program different from dynamic linking?

For example, tcc can execute "C scripts". In what way is a program written with #!/usr/local/bin/tcc -run different than any other program?

The FSF notes, The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. But this seems weasel-worded to me -- all programs are just data, whether they have the executable bit set or not.

questions regarding "interpreted languages"

Posted Jul 20, 2010 15:42 UTC (Tue) by foom (subscriber, #14868) [Link] (4 responses)

The report actually said that using other modules from an interpreted language is similar to dynamic linking.

So, I'd say they agree with you: using tcc to execute a "C script" is generally not very different from compiling the program to an ELF file. The major difference is whether macro/template expansion is done by you before distribution, or by the user at runtime.

questions regarding "interpreted languages"

Posted Jul 20, 2010 16:22 UTC (Tue) by wingo (guest, #26929) [Link] (3 responses)

I guess my question is, why not consider the interpreted program as dynamically linking to the interpreter itself?

questions regarding "interpreted languages"

Posted Jul 20, 2010 16:44 UTC (Tue) by Trelane (guest, #56877) [Link] (2 responses)

Because it's interpreting, not linking? If it's not calling the routines, but rather being directly interpreted, it's more akin to executing on a processor than linking to a library. These are perhaps two fully separate operations.

Or perhaps you're pointing out ultimately to do something based upon a piece of data (e.g. an opcode saying add register a to register b) is ultimately calling a set of routines, whether it's add(a, b) or OPCODE_ADD, REG_A, REG_B.

I think the difference is that one operation (the opcode version) is an innate function of the processor. You don't have to #include <math.h>; rather, you tell the intepreter to perform a builtin function instead of telling the interpreter to call a routine (i.e. ADD vs CALL ADD)

questions regarding "interpreted languages"

Posted Jul 20, 2010 16:46 UTC (Tue) by wingo (guest, #26929) [Link] (1 responses)

I think you're probably right, though as foom notes there is the macro case to consider if the interpreter exports macros to the program.

The case I was really interested in though is the one in which the interpreted program calls routines from the interpreter itself, via libraries that are part of the interpreter. Most languages have a runtime, after all, and practically all programs written in a language use that runtime.

AFAIK it's for this reason that libgcc has its licensing exception.

questions regarding "interpreted languages"

Posted Jul 22, 2010 20:57 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, the FSF does hold that elisp files have to be GPLed, because Emacs is. So it looks like they agree with you. :)

(If there were non-GPLed programs that could interpret elisp as well, things might get more interesting. But there aren't: everything that can interpret elisp is an Emacs, or an Emacs fork. One wonders if the mere *possibility* of the existence of non-GPLed interpreters has any effect before one realises that one is not a lawyer.)

FSFE Welcomes New 'Software Interactions' Document From The European, Legal Network

Posted Jul 20, 2010 15:29 UTC (Tue) by foom (subscriber, #14868) [Link]

Wow, that's a pretty nice document. It actually goes through and explains the various ambiguities in whether dynamic linking creates a derived work or not, and such complex scenarios.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds