Licensing issues with a research project
Tassilo Horn
in the last two and a half year, my institute was in a big EU funded
project. Now that the project is nearly over, we want to open-source
the source code.
The problems we face is that the code from different partners all use
different licenses. That's the basic architecture:
- The application is based on the Eclipse platform, which uses the EPL
- The GUI and overall eclipse integration + some logic is EPL, too
- Some other logic is GPL
- There's a huge set of JAR files that are required and that should be
included in the distribution. Some JARs are basic third-party tools
for i.e. command line parsing, but most contain code (and compiled
class files) for individual components of the overall system. Here,
we have a large number of licenses: GPL, LGPL, AGPL, BSD-style (CPL,
MPL and Apache), and even proprietary licenses (and binary-only
libs)...
The components provided by us are all free software released as GPL.
Unfortunately, the consortium seems to have decided to use LGPL for the
system, and now wants us to switch from GPL to LGPL.
Of course, we don't want to do that for our code, because it is not only
used in that but in many more projects, too. But is there a possibility
to change the license for only one specific release that is bundled with
this system?
Or what's the general approach to open-source projects using both GPL
and possibly incompatible licenses?
Thanks for any pointers,
Tassilo
Alexander Terekhov
Tassilo Horn wrote:
[...]
> Or what's the general approach to open-source projects using both GPL
> and possibly incompatible licenses?
Ignore the allegedly "GPL incompatibility" nonsense.
Hth.
--
http://gng.z505.com/index.htm
(GNG is a derecursive recursive derecursion which pwns GNU since it can
be infinitely looped as GNGNGNGNG...NGNGNG... and can be said backwards
too, whereas GNU cannot.)
Tassilo Horn
> Tassilo Horn wrote:
> [...]
>> Or what's the general approach to open-source projects using both GPL
>> and possibly incompatible licenses?
>
> Ignore the allegedly "GPL incompatibility" nonsense.
So that means that we are allowed to release the whole thing unter
Eclipse Public License and having some GPL libs bundled is "somewhat
ok"? Some kind of a gentlemen agreement aka "Well, it's not quite
compatible but since it is free in most regards, nobody will enforce
each and every detail".
Bye,
Tassilo
David Kastrup
Ignore the "Alexander Terekhov" nonsense. As long as you get every
single copyright holder to agree, you can make use of whatever gentlemen
agreement you want (but it might restrict people who are not in the
deal). If not, you need to heed the conditions of every single license
on every piece of code. Where you exceed the threshold of mere
aggregation of independent components, the licenses might place
restrictions on distribution of the resulting whole.
That is nothing peculiar to the GPL.
--
David Kastrup
Tassilo Horn
Hi David,
> Ignore the "Alexander Terekhov" nonsense.
Who's that? ;-)
> As long as you get every single copyright holder to agree, you can
> make use of whatever gentlemen agreement you want (but it might
> restrict people who are not in the deal). If not, you need to heed
> the conditions of every single license on every piece of code. Where
> you exceed the threshold of mere aggregation of independent
> components, the licenses might place restrictions on distribution of
> the resulting whole.
Well, it seems there's more than plain aggregation. For example there
are classes in the EPL-licensed core that extend classes of our GPLed
library.
This is a scenario we didn't encounter till now. Our library is
dual-licensed as GPL, but you can also get a commercial license for use
in commercial products. We never considered the current scenario that
the library is used by free software that is not GPL-compatible.
Would switching to LGPL solve the issue? I guess no, because it is no
plain linking, but an extension.
To be fully correct: Our lib is GPL and it has a code generator which
spits out java code. The generated code is also GPLed currently, and
the EPL code specializes the generated classes only. Could we change
our lib to LGPL and spit out BSD-style licensed code, so that the
library itself is only used/linked and only the generated code is
extended/modified?
Bye,
Tassilo
Rjack
> Tassilo Horn <tas...@member.fsf.org> writes:
>
>> Alexander Terekhov <tere...@web.de> writes:
>>
>>> Tassilo Horn wrote: [...]
>>>> Or what's the general approach to open-source projects using
>>>> both GPL and possibly incompatible licenses?
>>> Ignore the allegedly "GPL incompatibility" nonsense.
>> So that means that we are allowed to release the whole thing
>> unter Eclipse Public License and having some GPL libs bundled is
>> "somewhat ok"? Some kind of a gentlemen agreement aka "Well,
>> it's not quite compatible but since it is free in most regards,
>> nobody will enforce each and every detail".
>
> Ignore the "Alexander Terekhov" nonsense.
Yeah... ignore the birth certificate too. Reality is irrelevant.
Obama's undoubtedly a Kenyan.
Welcome, GNUtian DAK, to the Birther's Club...
> As long as you get every single copyright holder to agree, you can
> make use of whatever gentlemen agreement you want (but it might
> restrict people who are not in the deal). If not, you need to heed
> the conditions of every single license on every piece of code.
> Where you exceed the threshold of mere aggregation of independent
> components, the licenses might place restrictions on distribution
> of the resulting whole.
>
> That is nothing peculiar to the GPL.
>
Sincerely,
Rjack
Alexander Terekhov
Tassilo Horn wrote:
>
> Alexander Terekhov <tere...@web.de> writes:
>
> > Tassilo Horn wrote:
> > [...]
> >> Or what's the general approach to open-source projects using both GPL
> >> and possibly incompatible licenses?
> >
> > Ignore the allegedly "GPL incompatibility" nonsense.
>
> So that means that we are allowed to release the whole thing unter
> Eclipse Public License and having some GPL libs bundled is "somewhat
> ok"?
It's perfectly okay and is called "mere aggregation" in Guh-N�-speak.
http://www.btlj.org/data/articles/21_04_04.pdf
(DANGEROUS LIAISONS�SOFTWARE
COMBINATIONS AS DERIVATIVE WORKS?
DISTRIBUTION, INSTALLATION, AND EXECUTION
OF LINKED PROGRAMS UNDER COPYRIGHT LAW,
COMMERCIAL LICENSES, AND THE GPL)
http://www.law.washington.edu/LCT/Events/FOSS/OmegaBrief.pdf
(Omega Plaintiff's Brief)
http://www.law.washington.edu/LCT/Events/FOSS/AlphaBrief.pdf
(Alpha Defendant's Brief)
http://www.law.washington.edu/LCT/Events/FOSS/03.%20Beyond%20the%20Basics%20-%20Moot%20Court.mp3
(Hearing and Q&A)
-------
The Scope of �Derivative Works� as Applied to Software: David Bender
of White & Case LLP and author of Computer Law and Ieuan Mahony of
Holland & Knight LLP will argue the proper scope of �derivative work�
under U.S. copyright law when applied to software, before a panel of
distinguished federal appellate judges:
* HONORABLE WILLIAM C. BRYSON, U.S. Court of Appeals for the
Federal Circuit
* HONORABLE HALDANE ROBERT MAYER, U.S. Court of Appeals for the
Federal Circuit
* HONORABLE MARGARET MCKEOWN, U.S. Court of Appeals for the
Ninth Circuit
-------
and finally
http://markmail.org/message/pkwi5gzoxx3gdoas
Hth.
regards,
alexander.
Alexander Terekhov
Tassilo Horn wrote:
[... GNUtian dak's blathering ...]
> Well, it seems there's more than plain aggregation. For example there
> are classes in the EPL-licensed core that extend classes of our GPLed
> library.
That constitutes a derivative work only in the GNU Republic in the
nearby alternative universe.
As for our reality, see
http://digital-law-online.info/lpdi1.0/treatise22.html
(III.B. Abstraction, Filtration, Comparison)
http://digital-law-online.info/lpdi1.0/treatise27.html
(VI.D.4. Derivative Works and Compilations)
"Some have claimed that an application program that needs a library for
its operation is a derivative work of that library. They take that
position because the application program is �based on� the library
because it was written to use the subroutines and other aspects of the
library.
Such a position is misplaced.
. . .
It could be argued that the component program really does include
portions of the library that it uses � data structures that are passed
as parameters, or even the parameter lists themselves. But elements
dictated by external considerations are filtered out when trying to
determine whether there is copyright infringement.
No other conclusion makes sense. If it were not the case, then any
program using the applications program interfaces (APIs) of an operating
system could be considered a derivative work of that operating system.
And, under the exclusive right to prepare derivative works, the
copyright owner of an operating system such as Microsoft Windows could
control who was allowed to write programs for that operating system."
regards,
alexander.
John Hasler
> Our lib is GPL and it has a code generator which spits out java code.
> The generated code is also GPLed currently, and the EPL code
> specializes the generated classes only. Could we change our lib to
> LGPL and spit out BSD-style licensed code, so that the library itself
> is only used/linked and only the generated code is extended/modified?
Does the generated code contain significant fractions of protected
elements of the library itself? If not the generated code is a
mechanical transformation of the input and so only the license on the
input applies. Even if elements of the library are in the generated
code you can apply a different license to them than to the library. The
Gcc license does exactly that.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Alexander Terekhov
John Hasler wrote:
[...]
> Gcc license does exactly that.
Oh yeah, the GCC license...
http://lwn.net/Articles/343608/
(A new GCC runtime library license snag?)
LOL.
regards,
alexander.
Tassilo Horn
Hi John,
>> Our lib is GPL and it has a code generator which spits out java code.
>> The generated code is also GPLed currently, and the EPL code
>> specializes the generated classes only. Could we change our lib to
>> LGPL and spit out BSD-style licensed code, so that the library itself
>> is only used/linked and only the generated code is extended/modified?
>
> Does the generated code contain significant fractions of protected
> elements of the library itself?
Ah, yes, sadly. It's a graph library, and the library contains
interfaces Graph, Vertex and Edge (and abstract base implementations
thereof). All the generated interfaces and classes derive from one of
those base types. :-(
Bye,
Tassilo
Alexander Terekhov
Tassilo Horn wrote:
[... protected elements ...]
> Ah, yes, sadly. It's a graph library, and the library contains
> interfaces Graph, Vertex and Edge (and abstract base implementations
> thereof).
What makes you think that interfaces Graph, Vertex and Edge are
protected elements, Tassilo?
> All the generated interfaces and classes derive from one of
> those base types. :-(
Which is utterly irrelevant in the copyright context unless derived
classes' *source code* contains protected elements copied from abstract
base implementations of Graph, Vertex and Edge.
Simply put, OOP term "derive from" doesn't equate to copyright term
"derivative work".
Got it now, Tassilo?
regards,
alexander.
John Hasler
> It's a graph library, and the library contains interfaces Graph,
> Vertex and Edge (and abstract base implementations thereof). All the
> generated interfaces and classes derive from one of those base types.
Then the owners of the copyrights in the Graph, Vertex and Edge
interfaces need to agree that generated code derived from their work may
be distributed under the terms of the BSD license (or they could simply
disclaim any copyright interest in the generated code as the FSF does
for Gcc).
Alexander Terekhov
John Hasler wrote:
>
> Tassilo writes:
> > It's a graph library, and the library contains interfaces Graph,
> > Vertex and Edge (and abstract base implementations thereof). All the
> > generated interfaces and classes derive from one of those base types.
>
> Then the owners of the copyrights in the Graph, Vertex and Edge
> interfaces need to agree that generated code derived from their work may
> be distributed under the terms of the BSD license (or they could simply
Hey Tassilo, to repeat, please bear in mind that OOP term "derive[d]
from" doesn't equate to copyright term "derivative work".
Uncle Hasler is incurable, but you might have a better chance...
Ignore the allegedly "GPL incompatibility" nonsense.
Hth.
regards,
alexander.
Tassilo Horn
> Tassilo writes:
>> It's a graph library, and the library contains interfaces Graph,
>> Vertex and Edge (and abstract base implementations thereof). All the
>> generated interfaces and classes derive from one of those base types.
>
> Then the owners of the copyrights in the Graph, Vertex and Edge
> interfaces need to agree that generated code derived from their work
> may be distributed under the terms of the BSD license (or they could
> simply disclaim any copyright interest in the generated code as the
> FSF does for Gcc).
The copyright holder is my institute, so that's no problem. Thanks for
the pointer.
Bye,
Tassilo
Tassilo Horn
>> > It's a graph library, and the library contains interfaces Graph,
>> > Vertex and Edge (and abstract base implementations thereof). All
>> > the generated interfaces and classes derive from one of those base
>> > types.
>>
>> Then the owners of the copyrights in the Graph, Vertex and Edge
>> interfaces need to agree that generated code derived from their work
>> may be distributed under the terms of the BSD license (or they could
>> simply
>
> Hey Tassilo, to repeat, please bear in mind that OOP term "derive[d]
> from" doesn't equate to copyright term "derivative work".
Yes. So the EPL code extends GPL code by deriving from it in OOP terms
has vanished, either because it's not physically modified (your reply),
or because we could disclaim copyright interests or switch to another
license on a per-project basis for the generated code (John's reply).
> Ignore the allegedly "GPL incompatibility" nonsense.
Well, still the EPL FAQ [1] says, that you cannot combine GPL with EPL
code in one module. So the GPL license for our library itself is still
an issue. We could switch to the Lesser GPL, and as far as I see, that
would solve the issue.
Bye,
Tassilo
__________
[1] http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE
Alexander Terekhov
Tassilo Horn wrote:
[...]
> The copyright holder is my institute, . . .
If you're Tassilo Horn from Universit�t Koblenz-Landau institute (aren't
you?) your institute may hold exclusive licences for works made by its
employees on the territory of Germany (see your employment contract) but
your institute doesn't hold the copyright (Urheberrecht) in works made
on the territory of Germany.
The German copyright act doesn't recognize the concept of "work for
hire" in which the copyright (Urheberrecht) is owned by employer.
Consider:
http://bundesrecht.juris.de/bundesrecht/urhg/gesamt.pdf
"Der Urheber
� 7 Urheber
Urheber ist der Sch�pfer des Werkes.
[...]
Nutzungsrechte
� 31 Einr�umung von Nutzungsrechten
(1) Der Urheber kann einem anderen das Recht einr�umen, das Werk auf
einzelne oder alle Nutzungsarten zu nutzen (Nutzungsrecht). Das
Nutzungsrecht kann als einfaches oder ausschlie�liches Recht sowie
r�umlich, zeitlich oder inhaltlich beschr�nkt einger�umt werden.
(2) Das einfache Nutzungsrecht berechtigt den Inhaber, das Werk auf die
erlaubte Art zu nutzen, ohne dass eine Nutzung durch andere
ausgeschlossen ist.
(3) Das ausschlie�liche Nutzungsrecht berechtigt den Inhaber, das Werk
unter Ausschluss aller anderen Personen auf die ihm erlaubte Art zu
nutzen und Nutzungsrechte einzur�umen. Es kann bestimmt werden, dass die
Nutzung durch den Urheber vorbehalten bleibt. � 35 bleibt unber�hrt.
[...]
� 41 R�ckrufsrecht wegen Nichtaus�bung
(1) �bt der Inhaber eines ausschlie�lichen Nutzungsrechts das Recht
nicht oder nur unzureichend aus und werden dadurch berechtigte
Interessen des Urhebers erheblich verletzt, so kann dieser das
Nutzungsrecht zur�ckrufen. Dies gilt nicht, wenn die Nichtaus�bung oder
die unzureichende Aus�bung des Nutzungsrechts �berwiegend auf Umst�nden
beruht, deren Behebung dem Urheber zuzumuten ist.
(2) Das R�ckrufsrecht kann nicht vor Ablauf von zwei Jahren seit
Einr�umung oder �bertragung des Nutzungsrechts oder, wenn das Werk
sp�ter abgeliefert wird, seit der Ablieferung geltend gemacht werden.
Bei einem Beitrag zu einer Zeitung betr�gt die Frist drei Monate, bei
einem Beitrag zu einer Zeitschrift, die monatlich oder in k�rzeren
Abst�nden erscheint, sechs Monate und bei einem Beitrag zu anderen
Zeitschriften ein Jahr.
(3) Der R�ckruf kann erst erkl�rt werden, nachdem der Urheber dem
Inhaber des Nutzungsrechts unter Ank�ndigung des R�ckrufs eine
angemessene Nachfrist zur zureichenden Aus�bung des Nutzungsrechts
bestimmt hat. Der Bestimmung der Nachfrist bedarf es nicht, wenn die
Aus�bung des Nutzungsrechts seinem Inhaber unm�glich ist oder von ihm
verweigert wird oder wenn durch die Gew�hrung einer Nachfrist
�berwiegende
Interessen des Urhebers gef�hrdet w�rden.
(4) Auf das R�ckrufsrecht kann im voraus nicht verzichtet werden. Seine
Aus�bung kann im voraus f�r mehr als f�nf Jahre nicht ausgeschlossen
werden.
(5) Mit Wirksamwerden des R�ckrufs erlischt das Nutzungsrecht.
(6) Der Urheber hat den Betroffenen zu entsch�digen, wenn und soweit es
der Billigkeit entspricht.
(7) Rechte und Anspr�che der Beteiligten nach anderen gesetzlichen
Vorschriften bleiben unber�hrt.
� 42 R�ckrufsrecht wegen gewandelter �berzeugung
. . ."
Hth.
regards,
alexander.
Alexander Terekhov
Tassilo Horn wrote:
[...]
> Well, still the EPL FAQ [1] says, that you cannot combine GPL with EPL
> code in one module.
Ha ha. Why can't you suggest and/or implement the solution of making
*two* modules, Tassilo?
John Hasler
> Well, still the EPL FAQ [1] says, that you cannot combine GPL with EPL
> code in one module.
Unless you are the copyright owner, in which case you can make an
explicit exception. Remember, these are model licenses, not laws.
Tassilo Horn
Hi!
>> The copyright holder is my institute, . . .
>
> If you're Tassilo Horn from Universität Koblenz-Landau institute
> (aren't you?)
Yep, that's me.
> your institute may hold exclusive licences for works made by its
> employees on the territory of Germany (see your employment contract)
> but your institute doesn't hold the copyright (Urheberrecht) in works
> made on the territory of Germany.
Well, then let's rephrase my sentence: Most copyright holders are in the
institute, but of course, a lot of work has been done by past students
and employees, and we have a very easy-going "my code is your code"
policy, which makes it not easy to figure out who might have copyright
on what. But since the old versions would still be GPL and only new
versions might change to LGPL, I guess it's ok if only the current
developers agree.
Bye,
Tassilo
Tassilo Horn
Hi!
>> Well, still the EPL FAQ [1] says, that you cannot combine GPL with
>> EPL code in one module.
>
> Ha ha. Why can't you suggest and/or implement the solution of making
> *two* modules, Tassilo?
At least for some components we'll go in that direction. But in the
case of our lib, that makes no sense. The overall project cannot work
without it; it's the underlying repository and provides all of the data
structures.
Hm, citing the EPL FAQ:
,----
| Further, you may not combine EPL and GPL code in any scenario where
| source code under those licenses are both the same source code module.
`----
I have to admit, that I don't really understand that sentence. I can
read it, that only mixing (in the sense of copy&paste) EPL code and GPL
code in one file is forbidden. I can also read it, that I may not have
a JAR-file containing GPL code bundled with an EPL project.
Well, but the FSF's statement is clear:
,----
| Based upon the position of the Free Software Foundation, you may not
| combine EPL and GPL code in any scenario where linking exists between
| code made available under those licenses. The above applies to both
| GPL version 2 and GPL version 3.
`----
Bye,
Tassilo
David Kastrup
> Tassilo writes:
>> Well, still the EPL FAQ [1] says, that you cannot combine GPL with EPL
>> code in one module.
>
> Unless you are the copyright owner, in which case you can make an
> explicit exception. Remember, these are model licenses, not laws.
Make that "the sole copyright owner". And "GPL with exception" is not
compatible with "GPL", so the "GPL" in its name is misleading: you don't
get to mix this with other GPL software.
There is a thin ledge of what you can actually do: you can add some
declaration of intent, like "if you use the plugin interface, we don't
consider the resulting whole as more than a agglomeration of
components". But this is a guarantee just from one side: it mostly will
just work for letting GPL-compatibly licensed extensions (from third
parties) retain their individual more lenient licenses even after
modifications.
--
David Kastrup
Tassilo Horn
> Tassilo writes:
>> Well, still the EPL FAQ [1] says, that you cannot combine GPL with
>> EPL code in one module.
>
> Unless you are the copyright owner, in which case you can make an
> explicit exception. Remember, these are model licenses, not laws.
Sure, but in general we all are too clueless when it comes to licensing.
As I see it currently, the LGPL would fit our needs best.
Concerning the "Does OO-inheritance, plain linking, or only physical
modification create a derivated work?", I found this statement on the
LGPL wikipedia page:
,----
| The LGPL contains no special provisions for inheritance, because none
| are needed. Inheritance creates derivative works in the same way as
| traditional linking, and the LGPL permits this type of derivative work
| in the same way as it permits ordinary function calls.
`----
Bye,
Tassilo
Alexander Terekhov
Tassilo Horn wrote:
[...]
> Hm, citing the EPL FAQ:
>
> ,----
> | Further, you may not combine EPL and GPL code in any scenario where
> | source code under those licenses are both the same source code module.
> `----
>
> I have to admit, that I don't really understand that sentence. I can
> read it, that only mixing (in the sense of copy&paste) EPL code and GPL
They mean that EPL'd modules must be free from any protected expression
copied from the GPL'd code.
See
http://digital-law-online.info/lpdi1.0/treatise22.html
(III.B. Abstraction, Filtration, Comparison)
> code in one file is forbidden. I can also read it, that I may not have
> a JAR-file containing GPL code bundled with an EPL project.
A JAR-file is an aggregation of "modules" in binary form. You may have a
JAR-file containing GPL'd modules "bundled" with EPL'd modules.
>
> Well, but the FSF's statement is clear:
>
> ,----
> | Based upon the position of the Free Software Foundation, you may not
> | combine EPL and GPL code in any scenario where linking exists between
> | code made available under those licenses. The above applies to both
> | GPL version 2 and GPL version 3.
> `----
The position of the Free Software Foundation may be upheld only in a
court of the GNU Republic (i.e. not in this reality).
Ignore the allegedly "GPL incompatibility" nonsense.
See
http://markmail.org/message/pkwi5gzoxx3gdoas
Hth.
Alexander Terekhov
Tassilo Horn wrote:
[...]
> Concerning the "Does OO-inheritance, plain linking, or only physical
> modification create a derivated work?", I found this statement on the
> LGPL wikipedia page:
>
> ,----
> | The LGPL contains no special provisions for inheritance, because none
> | are needed. Inheritance creates derivative works in the same way as
> | traditional linking, and the LGPL permits this type of derivative work
> | in the same way as it permits ordinary function calls.
> `----
Note that you've quoted "clarification [which] is given on the official
GNU website".
It reflects the state of affairs regarding linking somehow creating
derivative works in the GNU Republic, not this reality.
You can safely ignore such utter nonsense outside the jurisdiction of
the GNU Republic.
Florian Weimer
> The German copyright act doesn't recognize the concept of "work for
> hire" in which the copyright (Urheberrecht) is owned by employer.
The exploitation rights for computer programs are automatically
transferred to the employer, see �69b UrhG. Keep in mind that this
does not apply to results of master theses etc. when the student was
unpaid; thesis-for-copyright contracts are void because of their
exploitative nature.
The institute/department doesn't own the copyright because it's not a
legal entity according to the laws regulating universities. The
university owns the copyright (unless it has been transferred to the
department chair or something like that).
Tassilo, your best chance will be to have everyone relicense their
stuff under a common license. This is quite painful, and may not be
possible in the end. And you should really ask your technology
licensing bureau for advice.