ANNOUNCE: L4Env version 0.1
The DROPS team is happy to announce the first release of the L4Env programming environment. L4Env is a programming environment for application development on top of the L4 microkernel family. It is developed as a part of the Dresden Real-Time Operating System (DROPS). Prior to L4Env, most L4 applications had their very own idea about the environment (libraries, interfaces and so on) in which they were executed. Almost every programmer had his own set of libraries he used to build his applications, which resulted in huge problems if someone tried to combine components developed by different authors. Frequent problems were conflicting implementations of common functions (like printf) or conflicts caused by the lack of a central management of resources like threads or virtual memory. The intention of L4Env is to define a set of functions which describe a minimal environment. This minimal environment is available for every L4 application. Hence, all applications and especially all libraries can use these functions. Libraries which are intended to be used by many different applications should only use these functions to avoid dependencies to other libraries. L4Env also decreases the dependencies to a certain L4 API or hardware architecture, making applications more portable. L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops@os.inf.tu-dresden.de. Source distributions, documentation, and other online resources can be found on the L4Env website: http://os.inf.tu-dresden.de/l4env/ The DROPS Team Operating Systems Group University of Technology Dresden, Germany
The DROPS team is happy to announce the first release of the L4Env programming environment. Great work!
L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops@os.inf.tu-dresden.de. Is there any reason for this? This is pretty restrictive to developers. Why didn't you consider releasing L4Env under a BSD-style license (like L4Ka::Pistachio), or at least LGPL?
Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.
On Tuesday 01 July 2003 01:32, Farid Hajji wrote:
L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops@os.inf.tu-dresden.de.
Is there any reason for this? This is pretty restrictive to developers. Why didn't you consider releasing L4Env under a BSD-style license (like L4Ka::Pistachio), or at least LGPL?
Since L4env is _not_ entirely written from scratch. We depend on some imported stuff which is GPL. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops@os.inf.tu-dresden.de.
Is there any reason for this? This is pretty restrictive to developers. Why didn't you consider releasing L4Env under a BSD-style license (like L4Ka::Pistachio), or at least LGPL?
Since L4env is _not_ entirely written from scratch. We depend on some imported stuff which is GPL.
Ah, okay. L4Env shouldn't therefore be used for NetBSD/L4 or similar porting projects due to license clashes. Many thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.
Hi, are the L4_env IDL files dependent on GPLed sources. If not, you should change the license of the IDL files to something not so infective. If the IDL files are GPL, also the generated code, i.e. the client headers become GPL which in turn attempts to use your servers. It might be fine for NETBSD / L4 if the servers provided within L4 Env are GPLed but if the interfaces to them are not. Ciao Marcus farid.hajji@ob.kamp.net wrote:
L4Env is available under the GPL version 2 licence. For different licensing schemes please contact drops@os.inf.tu-dresden.de.
Is there any reason for this? This is pretty restrictive to developers. Why didn't you consider releasing L4Env under a BSD-style license (like L4Ka::Pistachio), or at least LGPL?
Since L4env is _not_ entirely written from scratch. We depend on some imported stuff which is GPL.
Ah, okay. L4Env shouldn't therefore be used for NetBSD/L4 or similar porting projects due to license clashes.
Many thanks,
-Farid.
-- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Marcus,
Since L4env is _not_ entirely written from scratch. We depend on some imported stuff which is GPL.
Ah, okay. L4Env shouldn't therefore be used for NetBSD/L4 or similar porting projects due to license clashes.
are the L4_env IDL files dependent on GPLed sources. If not, you should change the license of the IDL files to something not so infective. If the IDL files are GPL, also the generated code, i.e. the client headers become GPL which in turn attempts to use your servers.
yes, that's exactly my concern. IDL files and header files that get included in a port would immediately infect everything else. I'm not sure wether I should even have a look at L4Env right now, should a clean room implementation be needed.
It might be fine for NETBSD / L4 if the servers provided within L4 Env are GPLed but if the interfaces to them are not.
As for NetBSD/L4: don't expect GPLed code to make it in the tree. It wouldn't (and shouldn't) happen. Is there a GPL-free documentation of the L4Env interfaces available? This would at least help a little bit... -Farid. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.
Farid Hajji <farid.hajji@ob.kamp.net> writes:
It might be fine for NETBSD / L4 if the servers provided within L4 Env are GPLed but if the interfaces to them are not.
As for NetBSD/L4: don't expect GPLed code to make it in the tree. It wouldn't (and shouldn't) happen.
Is there any special reason for using L4Env as the foundation of a NetBSD port? L4Linux was written before we even started to think about L4Env so you should be able to port NetBSD based on the interfaces provided by the L4. Jean
It might be fine for NETBSD / L4 if the servers provided within L4 Env are GPLed but if the interfaces to them are not.
As for NetBSD/L4: don't expect GPLed code to make it in the tree. It wouldn't (and shouldn't) happen.
Is there any special reason for using L4Env as the foundation of a NetBSD port? L4Linux was written before we even started to think about L4Env so you should be able to port NetBSD based on the interfaces provided by the L4.
No, there's no special reason to use L4Env directly. It is not really critical, since the X.2 (V4) API, as implemented in L4Ka::Pistachio would be enough for a new (Pseudo-)architecture in NetBSD. The port would look somewhat like L4Linux too. Anyway, L4Env would have been an interesting abstraction layer besides the clean MI/MD separation in NetBSD... Don't bother: not using L4Env in this particular context is not a show-stopper. Many thanks, -FH. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe.
participants (5)
-
DROPS-Team -
Farid Hajji -
Frank Mehnert -
Jean Wolter -
Marcus Voelp