Discussions

News: FileRA 1.0 Released

  1. FileRA 1.0 Released (71 messages)

    The J2EE 1.4 specification restricts access to local files to resource adapters only. This means, EJBs, Servlets and JSPs are not meant to access local files directly, to prevent security and transactional problems, and to prevent the need to replicate filesystems across clusters.

    If such a component needs to access a local file, it needs the help of a resource adapter. The FileRA project is providing such an adapter.

    It not only grants read and write access, but also implements high performance copy and move operations by delegating this work completely to the host operating system instead of doing this work inside of the VM, which saves memory and computational power.

    The Java NIO API is used, which means the adapter is 100% pure Java and does not use any proprietary technology. The binaries and source code are released unter GPL on http://www.sourceforge.net/projects/filera.

    The FileRA.rar uses the JCA 1.5 spec and passes most of the verification tests for RARs.

    Are you aware of the JCA specification at all? Have you seen a need for such an adapter? Would you use one, even if it lacks transaction support, as this one does?

    Is the "access to filesystem" limit something that worries you, if you're a J2EE developer? After all, in a cluster, file "1" might not be on server "2," which is where a cluster ends up having to rely on shared filesystems or possibly synchronized filesystems (as is often the case when Lucene is used with a filesystem directory.)

    What are your thoughts?

    Threaded Messages (71)

  2. FileRA 1.0 Released[ Go to top ]

    This is very cool and useful. It's a good start, but adding transactionality would make it super, even if it's only local transactions.

    Steve
  3. More and more people ask for transaction support. The problem is: FileRA shall be 100% pure Java (not using native APIs), and it shall be as fast as possible. If someone has an idea how to implement XA or Local TX, in 100% pure Java, without a major performance penalty, please let me know. I'm very interested in adding it to the FileRA, indeed. :-)

    Some asked for support of remote files. There is the same problem. The FileRA is not a SmbRA or NfsRA. It is a Local File RA. So FileRA relies on correct local mounted sharings. If this is a problem for you, please tell us. Maybe we will start work on SmbRA or NfsRA then. :-)

    Thanks for your comments!
    Markus, Author of FileRA
  4. remote fs access[ Go to top ]

    Remote access shouldn't be necessary anyway, if you're able to connect to another machine's JNDI tree - server A can connect to server B's filera instance, and server B's filesystem will be used.

    As for TX.. what about a compensatory transaction mechanism? Normally, performance there isn't the big deal as long as you have, well, transactions, which are understandably slow. If you need TX, there's usually a cost in speed.
  5. remote fs access[ Go to top ]

    Unfortunately this is not true. The instance you get from the FileRA on a remote client will NOT connect to the FileRA deployed on the server. JNDI creates a local instance of RA, so that local instance acts on the local FS. There is no inter-FileRA-connection inside of FileRA, as FileRA connects to backend filesystems, which is always the LOCAL filesystem. If you need to access remote servers, you need to mount the share into the local filesystem of the client.

    Markus KARG, Author of FileRA
  6. remote fs access[ Go to top ]

    You missed my point: JNDI is a tree. You can establish a connection to a remote JNDI tree, and thus acquire an instance of the FileRA on a remote machine, which will use the remote system's "local filesystem" for files.
  7. Remote JNDI[ Go to top ]

    JNDI is not a tree, it is an interface. It's up of the implementor whether to support or not support the idea of linking together remote instances into one large tree. Not every JNDI implementor supports this. Since the question was "does FileRA support remote usage", I (as its author) have to admit: NO, since it doesn't make up an internal connection. If your JNDI implementor supports spanning remote trees, it surely will work, but this is outside of the scope of a discussion on FileRA.
  8. Transactional file access[ Go to top ]

    Guys, did you see
    http://jakarta.apache.org/commons/transaction/file/index.html ?
  9. Transactional file access[ Go to top ]

    Hmmm. Yeah, we can't use it if it's GPL. That's a bummer. :(
  10. You CAN us it.[ Go to top ]

    Please read the GPL and tell me the chapter where is written that YOU cannot use it.
  11. Two points[ Go to top ]

    First, while it has been a while since I read the spec, I believe it only says that containers are allowed to restrict file usage, not that components cannot use files. There is, obviously, a huge difference between the two, one which has caused confusion from day one as almost everyone has (incorrectly, IMO) interpreted it as "access to filesystem is limited".

    Second, the value of such a library is greatly diminished by the choice of license. I would suggest changing it to either APL or BSD, but even LGPL would suffice.
  12. Two points[ Go to top ]

    First, while it has been a while since I read the spec, I believe it only says that containers are allowed to restrict file usage, not that components cannot use files. There is, obviously, a huge difference between the two, one which has caused confusion from day one as almost everyone has (incorrectly, IMO) interpreted it as "access to filesystem is limited".

    Well, it SHOULD be limited - not necessarily by container but by logic. Access to a file only works if that file is on the local filesystem somehow. If a clustered component makes a reference to a file, then the burden on the architecture is that the file has to be available to every element on the cluster, and it has to be synchronized across the entire cluster, too, which is a little more troublesome.

    A file-access JCA component means that JNDI can be used to locate a filesystem (not quite the same as mapping JNDI *to* a filesystem) and thus, enterprise components can SAFELY refer to files... sort of.
  13. Two points[ Go to top ]

    Well, it SHOULD be limited - not necessarily by container but by logic. Access to a file only works if that file is on the local filesystem somehow. If a clustered component makes a reference to a file, then the burden on the architecture is that the file has to be available to every element on the cluster, and it has to be synchronized across the entire cluster, too, which is a little more troublesome.

    Not only that. Clustered application server should be able to migrate component or even in-progress transaction to the different node (e.g. in case of failover).
  14. Two points[ Go to top ]

    Well, it SHOULD be limited - not necessarily by container but by logic. Access to a file only works if that file is on the local filesystem somehow.
    Absolutely. My point was simply that the spec doesn't say what most people says it says. That's all. But I've been pointing that out for some 5 years now, and it's still hard to understand it seems. Once the initial meme got started about it has been impossible to break.
    If a clustered component makes a reference to a file, then the burden on the architecture is that the file has to be available to every element on the cluster, and it has to be synchronized across the entire cluster, too, which is a little more troublesome.A file-access JCA component means that JNDI can be used to locate a filesystem (not quite the same as mapping JNDI *to* a filesystem) and thus, enterprise components can SAFELY refer to files... sort of.
    Well, having a JCA component does not automatically mean that it will work in a cluster, just as using a JDBC driver does not automatically mean that the system will work in a cluster. It's still a "it depends" kind of thing. Sort of.
  15. Two points[ Go to top ]

    I believe it only says that containers are allowed to restrict file usage, not that components cannot use files.

    EJB spec 2.1, paragraph 25.1.2
    • An enterprise bean must not use the java.io package to attempt to access files and directories
    in the file system.


    'must not' sounds clear enough there...
  16. Two points[ Go to top ]

    There are no apparent restrictions for Servlets and JSPs though. All they say there (SRV.7.7.2, Servlets 2.4) is
    Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states using an enterprise bean or a database.
  17. One down[ Go to top ]

    EJB spec 2.1, paragraph 25.1.2• An enterprise bean must not use the java.io package to attempt to access files and directoriesin the file system.'must not' sounds clear enough there...
    If it has been changed to that (my bad for not checking first) then it is indeed pretty clear :-) Finally.

    That leaves only one point then: the license :-)
  18. I don't understand[ Go to top ]

    Isn't this mumbo jumbo? What good is a non-transactional, non-distributed RA in comparison to direct file access EXCEPT that the J2EE spec endorses dirty work only behind JCA curtains?
  19. To make you understand[ Go to top ]

    No, it ain't just mumbo jumbo:

    First, FileRA comes with some utility functionality, like high speed move and copy, which means, if you need this, you don't need to code it on your won.

    Second, using FileRA results in a J2EE compliant application while not using FileRA results in a non-J2EE compliant application.

    Third, a very restrictive EJB container might throw RuntimeExceptions to intercept a call to java.ui.* API. This means, such a container would really prevent the code from executing. That's no bug, that's a security feature. The same very restrictive container might to allow the FileRA access to a special directory tree, only. This is explicitely told in the JCA 1.5 spec (the security system should prevent access to other directories than the ones explicitely allows).

    Forth, the next release of FileRA will support this security feature buy limiting the access to a special local tree only. This means, that path will be set by the admin at deploy time, and later gets appended to any path provided to the FileRA. The result will be that the FileRA hides the physical location of the file, while the calling EJB just uses relative paths inside of the root. As a result, the admin can restrict access of any instance of FileRA very close, while this would never be possible if using File API inside of an EJB: The root path (= JCA 1.5 standard property "ConnectionURL") is a default deployment parameter while there wouldn't be such for simple File API inside of an EJB.

    Markus KARG, Author of FileRA
  20. To make you understand[ Go to top ]

    Markus,

    thanks for your explanations.
    No, it ain't just mumbo jumbo: First, FileRA comes with some utility functionality, like high speed move and copy, which means, if you need this, you don't need to code it on your won.

    I didn't mean to diminish the value of a good file utility package. Why does it need to be a RA?
    Second, using FileRA results in a J2EE compliant application while not using FileRA results in a non-J2EE compliant application.

    What good is that standard? File access is file access, be it in a RA or not. The requirements for a successful deployment (shared filesystems, ...) are the same.
    Third, a very restrictive EJB container might throw RuntimeExceptions to intercept a call to java.ui.* API.

    True, question: could you do this with simple J2SE permissions?

    I'm actually interested - how many of you run real life J2EE applications with security on? How many of you host untrusted J2EE applications and rely on the container's security features? Would your favourite hosting environment be a J2EE container (cluster) or a bunch of virtual servers/Solaris 10 zones?
  21. Actually I don't understand what your problem is.
    The specification forbids the usage of java.io in EJBs.
    The specification says you have to use a FileRA.
    I made you the gift of that FileRA.
    As an ISV we need to assure 100% (not 99.9%) interoperability with any, maybe hypothetical, J2EE server.
    This is why we wrote the FileRA.
    What actually is your problem?
    Don't you like a gift?
    Don't you like specifications?
    Or what?
  22. Markus,

    I do not have a problem with your offering. Actually, I'm thankful for people offering free quality software. I profit from it and I'm trying my share to give back.

    I do have a problem with the specification when in pretends to solve a problem but doesn't in fact. Judge yourself what that makes me :-) http://diveintomark.org/archives/2004/08/16/specs
  23. To make you understand, once more.[ Go to top ]

    Don't you like a gift?Don't you like specifications?Or what?

    Heh. License "disagreements" are always a sure catalyst for an argument. Anyways, I think it's great that you've developed this and made it available for use. And of course, as your product, you have the right to release it under whichever license you favour - that's your perogative. The GPL is a great achievement in itself, but I personally prefer licenses that are a little less onerous from a commercial point of view. That's just my opinion.
  24. To make you understand[ Go to top ]

    Markus, to make YOU understand:

    1) Using a resource adapter may allow you to get around the letter of the law (by not using java.io directly from J2EE application code), but not the spirit of it. The point of not allowing access to local files is that you can't rely on those files always being there - and they certainly won't be kept in sync etc. So using FileRA may make your application technically compliant with the J2EE specs but it's still likely to break in a real distributed environment.

    2) I think you misunderstand the implications of using the GPL. If I link to FileRA either in source or in binary form, I MUST make my application GPL also and release the source code. I can't get around it by including FileRA only as a binary. In fact I'm not allowed to supply FileRA in binary form only, I would have to make the source available.

    In other words, GPL libraries really can ONLY be used in GPL apps.
  25. To make us understand[ Go to top ]

    1) Yes and no. Yes for "we just work around the law". No for "the idea is that the file cannot be there". The actual problem is that java.io is blocking while an EJB shall not block. Using the FileRA definitively can result in blocking. But hey, we never said we are solving that problem. We only said that FileRA was built to be able to not violate the specification. We never said that we will omit blocking. For the actual breaking: This can happen with non-files also. Think of relying on a table. If the admin drops the table, your apps is broken, too.

    2) Actually you misunderstand what linking is. The FileRA doesn't get linked to your app. It gets loaded by the application server. Your app is only using an instance that got provided by JNDI. This is not linking. And again: As I am the author and I allow you to use the FileRA in non-GPL projects, where actually is YOUR problem?
  26. To make us understand[ Go to top ]

    But hey, we never said we are solving that problem. We only said that FileRA was built to be able to not violate the specification.

    Which only indicates that the EJB specification is somewhat broken, in that it imposes a meaningless limitation. Don't we have better things to do than working around the word of the EJB specification, without any solution to the underlying technical problem?

    This is the negative side of J2EE, I guess: people wasting their time with dissecting the specifications and literally following every word in them, inventing workarounds that do not add any value in practice (other than more complicated setup, another classic J2EE problem).

    Juergen
  27. To make us understand[ Go to top ]

    Which only indicates that the EJB specification is somewhat broken, in that it imposes a meaningless limitation. Don't we have better things to do than working around the word of the EJB specification, without any solution to the underlying technical problem?This is the negative side of J2EE, I guess: people wasting their time with dissecting the specifications and literally following every word in them, inventing workarounds that do not add any value in practice (other than more complicated setup, another classic J2EE problem).Juergen

    J2ee spec and specifically EJB spec is not broken. The thing
    is that it makes sense to use it in no more then 5% of the situations.

    Such limitation are not a meaningless but they were created in early days of ejb technology when hope that ejb will create a component market and you will be able to buy a components written in say Australia and Rusiia and use it in your application in Germany. So it was really necessery to define how ejb component should behave and be a good citzens in any j2ee applications (including those deployed in clusterd env.) Obvisouly this never happens.

    (there are some other resons why this limitation make sense)

    Michal
  28. To make us understand[ Go to top ]

    Which only indicates that the EJB specification is somewhat broken, in that it imposes a meaningless limitation. Don't we have better things to do than working around the word of the EJB specification, without any solution to the underlying technical problem?This is the negative side of J2EE, I guess: people wasting their time with dissecting the specifications and literally following every word in them, inventing workarounds that do not add any value in practice (other than more complicated setup, another classic J2EE problem).Juergen

    I'm curious if this is a meaningless limitation. Would it not be preferable/more reliable with respects to threading issues to have File accesses done in a separate thread from an EJB remote thread? I would guess in a local EJB it'd be much safer. Maybe there really is no point. I'm really not sure.

    Steve
  29. clustering[ Go to top ]

    How does this behave in an application server cluster?
  30. clustering[ Go to top ]

    Each instance of FileRA works on its local file system. This means each node in the cluster needs a link to a shared FS (e. g. NFS, SMB) mounted into its local FS.
  31. licensing?[ Go to top ]

    I too feel this could be a handy RA, however also fear the license choice may hamper its adoption.

    Can you explain why GPL was chosen?
  32. GPL[ Go to top ]

    LGPL would allow commercial vendors to add closed source to the FileRA and package as a commercially sold component. We don't like the idea that others make money with our work.

    GPL allows commercial use of the binary FileRA. So unless you try to include the source into your commercial application, there is no problem form anybody. Any commercial vendor may deliver the FileRA in binary form without modifications to his enduers. They may run the commercial application together with FileRA. GPL doesn't restrict this. GPL only restricts including our source code into the source code of the commercial application.

    There is a good article on "why not LGPL" on GNU.org:

    http://www.gnu.org/licenses/why-not-lgpl.html

    Markus KARG, Author of FileRA
  33. GPL[ Go to top ]

    LGPL would allow commercial vendors to add closed source to the FileRA and package as a commercially sold component. We don't like the idea that others make money with our work.

    So why do you publish it as open source?
    Isn't it better to hide it then?

    And this is not what LGPL states. There are libraries like Hibernate which are using LGPL in the way you want. But LGPL
    is ambiguous and for example hibernate team has published their own interpretation of that license.

    GPL allows commercial use of the binary FileRA. So unless you try to include the source into your commercial application, there is no problem form anybody. Any commercial vendor may deliver the FileRA in binary form without modifications to his enduers. They may run the commercial application together with FileRA. GPL doesn't restrict this. GPL only restricts including our source code into the source code of the commercial application.There is a good article on "why not LGPL" on GNU.org:http://www.gnu.org/licenses/why-not-lgpl.htmlMarkus KARG, Author of FileRA

    This is not how GPL works. GPL is viral once you include
    any artifact which has GPL license entire application (or at least parts which are written by you) must be on GPL license.

    Even LGPL is not really business friendly and nobody really knows what does it mean in java world as it uses terms like linking which are not existing in java. As somebody observed LGPL is not even ... OSI compatible as it contains technology related references.

    Michal
  34. GPL[ Go to top ]

    1) I definitively want GPL BECAUSE of its viral intention.
    2) The virality of GPL only applies to code that gets linked together with the source of the RA. Since you don't compile RA on your own but only use it in binary form, the virality doesn't apply to your application at all. Neither to open nor to closed source ones. GPL doesn't force GPL for binaries, only for sources.
    3) Please quote from the GPL where it prohibits usage of binaries (not sources) within non-GPLed or commercial applications to proof that I am not right.
    4) I published as open source because I want other GPL'ed open source projects to be able to take a look at my code, or to build ontop of it.
    5) Since I am the author of FileRA, and I have told anybody inside this forum that you may use the binary distribution within non-GPLed projects, where is your problem at all?

    Markus KARG, Author of FileRA
  35. GPL[ Go to top ]

    1)5) Since I am the author of FileRA, and I have told anybody inside this forum that you may use the binary distribution within non-GPLed projects, where is your problem at all?

    The problem is that it doesn't matter what the author says on some forum, at least not for legal departments that need to approve the use of a specific piece of open source software.

    And exactly those legal departments will reject any GPL project without even looking at it any further. This doesn't come as a surprise, when even the FSF itself says that importing a GPL'ed API (even when linked in as binary) forces the application code to become GPL too.

    Guess why the LGPL is called the "library" GNU public license. Almost all libraries and frameworks out there choose either the LGPL or an Apache/BSD-style license. Commercial vendors with double licensing (e.g. MySQL) still choose GPL as basis - because this enforces their commercial (non-GPL) sister license for commercial use.

    Juergen
  36. GPL, MySQL etc.[ Go to top ]

    It is obvious that the wording of the license itself
    matters.

    But you bring up the example of MySQL.

    Is any code that contains Class.forName("com.mysql.jdbc.Driver")
    automtically GPL'ed ?

    My impression is no. So at least MySQL seems
    to have a sligtly more flexible approach to
    linking.

    How MySQL interprets the GPL is that you may
    not bundle without being GPL.

    If that holds water in court (and I assume that
    MySQL actually have investigated such things), then
    it should at least be valid to distribute a J2EE app
    and tell end users to get FileRA themselves.
  37. Re: GPL, MySQL etc.[ Go to top ]

    It is obvious that the wording of the license itself matters.But you bring up the example of MySQL.Is any code that contains Class.forName("com.mysql.jdbc.Driver")automtically GPL'ed ? My impression is no. So at least MySQL seems to have a sligtly more flexible approach to linking.

    Actually, no, it's a common complaint about MySQL, and something that they like to propagate, as they basically want commercial users to pay for a license.

    See, the MySQL JDBC driver is a classic example of something that perhaps SHOULD be LGPL, but it isn't, and it isn't for a reason.

    Since the JDBC driver has, essentially, no dependency on actual MySQL code, but rather just implements the wire protocol, you can see how you could have LGPL JDBC driver for a GPL DB, and the LGPL JDBC driver would act as a sort of licensing "Firewall" to MySQL.

    But it's not, it's GPL, and it's consciously GPL because MySQL's intent is basically "Free for free (GPL) software, everyone else needs to pony up". Note also that their native drivers (which are also GPL) fall flat into the middle of this whole conundrum. If you use their native drivers, you're linking code, and linking to GPL code -- ergo, GPL your application. So, it's consistent with MySQL's position on the whole thing.
  38. Re: GPL, MySQL etc.[ Go to top ]

    It is obvious that the wording of the license itself matters.But you bring up the example of MySQL.Is any code that contains Class.forName("com.mysql.jdbc.Driver")automtically GPL'ed ? My impression is no. So at least MySQL seems to have a sligtly more flexible approach to linking.
    Actually, no, it's a common complaint about MySQL, and something that they like to propagate, as they basically want commercial users to pay for a license.See, the MySQL JDBC driver is a classic example of something that perhaps SHOULD be LGPL, but it isn't

    I have deeply ambivalent feelings about the GPL, it is a nasty infectious beast, mostly by intension and design, and for good reason.

    I'm not a laywer, but I suspect that this can be sidestepped provided that all linking is though a non-GPL API.

    Using any GPL classes directly would certainly be infectious; I can see this would include types of variables, explicit reflection specific to the GPL library, and implementing/extending GPL classes.

    Class.forName("com.mysql.jdbc.Driver") is ambiguous as the link to the driver is in the program, abeit only as a string constant.
    I feel that what type you use for the varible holding the instance is more significant but even if we accept the above as GPL propagation, surely Class.forName(config.get("JDBCDriver"), where config is derived from outside the program should be safe.
    If communication is only though a non-GPL api (and obviously, non-GPL data classes), this looks a lot like the output clause of the GPL. The GPL software is not needed to compile or run the program (it can be substituted; I doubt that a non-GPL subsitute need exist, just be possible).
    In this case even co-distribution would only be 'mere aggregation', after all the author can't be responcible if the user just happens to use the GPL library; writing a GPL JDBC driver doesn't make all configurable JDBC apps GPL just like that.

    I guess what I'm saying is that this way while the user may (probably does) create a GPL derivative when they run the code in certain configurations, they don't actually distribute it - ie the code as distrubuted is not a derivative work and thus not subject to GPL; even if the GPL types don't like it I'm sure they couldn't sucessfully challenge it.

    I have a suspicion that in the case of the fileRA there is a necessity to link to GPL'ed classes; the moral of this story is if you want anyone outside the GPL to use your library use/make a non-GPL API, eg by separating out a LGPL interface, as I think someone suggested earlier.
  39. Re: GPL, MySQL etc.[ Go to top ]

    the moral of this story is if you want anyone outside the GPL to use your library use/make a non-GPL API, eg by separating out a LGPL interface, as I think someone suggested earlier.

    I am actually not so sure if this would help. Still a GPL liblary will be included in program and hence thanks to viral nature of GPL entire application will be GPL. LPGL license could help in the cases like MySQL when GPL part is conntacted over the network.


    michal
  40. JCA[ Go to top ]

    I have a suspicion that in the case of the fileRA there is a necessity to link to GPL'ed classes; the moral of this story is if you want anyone outside the GPL to use your library use/make a non-GPL API, eg by separating out a LGPL interface, as I think someone suggested earlier.

    Actually the JCA interface is intended to be used so that
    the end user only uses SUN supplied javax.ressource.*
    interface, but I have not checked whether that is also
    the case for FileRA.
  41. GPL, MySQL etc.[ Go to top ]

    It is my impression that MySQL focus's on whether you
    distribute MySQL code or not.

    And the relavant section in the GPL FAQ talsk about whether
    two things on the same CD is actually one thing.

    Probably for good reasons.

    If I am not distributing anything from MySQL. And to take
    this to the extreme: let us pretend that I have not and
    have never had any MySQL software on my PC [I have - but
    let us pretend].

    How can I by putting a line of code in the application
    I have copyrigth to give MySQL any saying about the license
    for my code.

    The GPL license says itself that if you do not comply, then
    your license to use whatever is terminated. But if you are
    not using the license, then ...

    But OK - I can understand that companies are carefull not
    to expose themselves to risk for getting sued - that seems
    to be a popular sport nowadays.

    I do not think that would make it in court.
  42. GPL[ Go to top ]

    1) I definitively want GPL BECAUSE of its viral intention.2) The virality of GPL only applies to code that gets linked together with the source of the RA. Since you don't compile RA on your own but only use it in binary form, the virality doesn't apply to your application at all. Neither to open nor to closed source ones. GPL doesn't force GPL for binaries, only for sources.
    </blackquote>

    Can you explain to us what linking means in Java World?

    If at runtime I would applay aspects to modify behavior of your liblary would it violate GPL or not?

    If I would reverser engineer you liblary and recompile recieved code again - would it not violate GPL in your opinion as I haven't touched your orginal sources?

    INAL but GPL does protectes agaist those two situtations.
    So really not only what happens with sources mattres.

    <blackquote>
    3) Please quote from the GPL where it prohibits usage of binaries (not sources) within non-GPLed or commercial applications to proof that I am not right.


    http://www.gnu.org/licenses/gpl-faq.html#TOCMereAggregation

    "Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them."

    Note that nothing mentioned about sources is mentioned there.

    4) I published as open source because I want other GPL'ed open source projects to be able to take a look at my code, or to build ontop of it.5) Since I am the author of FileRA, and I have told anybody inside this forum that you may use the binary distribution within non-GPLed projects, where is your problem at all?Markus KARG, Author of FileRA

    This is all fine. You are abolutly right - it is your liblary and you have full right to decide what you want to to with it, But note that Java Community by large is refusing to use anything which has GPL license attached to it.

    Michal
  43. GPL[ Go to top ]

    LGPL would allow commercial vendors to add closed source to the FileRA and package as a commercially sold component. We don't like the idea that others make money with our work.

    My suggestion then is to release it under a license that says that no one else is allowed to make money with your work.
    GPL allows commercial use of the binary FileRA.

    Yes, it does .. but with one minor caveat: That they release their entire application under the GPL license, source included.
    So unless you try to include the source into your commercial application, there is no problem form anybody. Any commercial vendor may deliver the FileRA in binary form without modifications to his enduers. They may run the commercial application together with FileRA. GPL doesn't restrict this. GPL only restricts including our source code into the source code of the commercial application.

    I don't believe that this is correct at all.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  44. GPL[ Go to top ]

    GPL allows commercial use of the binary FileRA.
    Yes, it does .. but with one minor caveat: That they release their entire application under the GPL license, source included.

    Don't think so. You can include GPL stuff in a non-GPL application legally as long as the GPL'ed thing remains unmodified and there is no embedding of the GPL code into the application proper (known as static linking in the license terms). In this case the non-GPL is not derivative of the GPL'ed work as per the license.
  45. GPL[ Go to top ]

    Don't think so. You can include GPL stuff in a non-GPL application legally as long as the GPL'ed thing remains unmodified and there is no embedding of the GPL code into the application proper (known as static linking in the license terms). In this case the non-GPL is not derivative of the GPL'ed work as per the license.
    Yeah, but the definition of "linking" is a little hazy. It's been said (and confirmed by FSF legal counsel, IIRC) that "import com.gpl.*" is sufficient to constitute linking.
    This, among other reasons, is why I believe that the BSD/Apache style licenses are by far the best choice if there is going to be business involvement in any way. They're the least ambiguous.
  46. GPL[ Go to top ]

    Don't think so. You can include GPL stuff in a non-GPL application legally as long as the GPL'ed thing remains unmodified and there is no embedding of the GPL code into the application proper (known as static linking in the license terms). In this case the non-GPL is not derivative of the GPL'ed work as per the license.Yeah, but the definition of "linking" is a little hazy. It's been said (and confirmed by FSF legal counsel, IIRC) that "import com.gpl.*" is sufficient to constitute linking.This, among other reasons, is why I believe that the BSD/Apache style licenses are by far the best choice if there is going to be business involvement in any way. They're the least ambiguous.
    One possible solution is to split up the library/utility (FileRA) into two parts, the interfaces and the implementation. The interfaces are the ones that will be imported (linked) and can have BSD like license.The implementation can use GPL. This way nobody can make money out of the library but can still use it commercially.
  47. GPL[ Go to top ]

    It is true that import x.y.z is definitively linking and would lead to virality of GPL.

    But you do not use import x.y.z for FileRA since it is not a library but a Resource Adapter. The resource adapter is not even loaded by your application -- it gets loaded by the application server.

    So the virality does NOT apply to the USE of FileRA, only to its further development OR to including its sourcecode.
  48. GPL[ Go to top ]

    GPL allows commercial use of the binary FileRA.

    Yes, it does .. but with one minor caveat: That they release their entire application under the GPL license, source included.

    Don't think so. You can include GPL stuff in a non-GPL application legally as long as the GPL'ed thing remains unmodified and there is no embedding of the GPL code into the application proper (known as static linking in the license terms). In this case the non-GPL is not derivative of the GPL'ed work as per the license.

    The GPL states:
    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.

    That is the basis for the "viral" aspect of the GPL. It is not accidental, and it means that if you use GPL software as part of your application, you must GPL your application, and failure to do so means that you are stealing GPL code.

    Further, they are entirely within their rights (as the licensors of the software and the copyright holders) to demand that you GPL your applications if you do this, because you have willingly and knowingly linked to their work that they have let you use on the condition that you will GPL your software.

    It is unfortunate, but I do believe that a large number of commercial interests do abuse the GPL licensing. Even though I don't agree with the cult of GNU, their rights as IP holders are no less valid than any commercial concern.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  49. For the non-believers[ Go to top ]

    We're not in church, so it's not a question if you believe or not. Read the GPL. If YOU want to use FileRA but you cannot because of the GPL, tell me the chapter of the GPL and I will check that.
  50. GPL[ Go to top ]

    .GPL allows commercial use of the binary FileRA. So unless you try to include the source into your commercial application, there is no problem form anybody. Any commercial vendor may deliver the FileRA in binary form without modifications to his enduers. They may run the commercial application together with FileRA. GPL doesn't restrict this.

    This is not correct - you need the LGPL for this. Only GPL'd code can use FileRA. I quote from the GNU FAQ:

    Q. You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?

    A. Yes.

    http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
  51. Using is not linking[ Go to top ]

    You are not linking your source code with the FileRA, neither in source nor in precompiled form. The application server is loading the FileRA and your application is only calling that already loaded code. There is no linking done.
  52. GPL[ Go to top ]

    LGPL would allow commercial vendors to add closed source to the FileRA and package as a commercially sold component. We don't like the idea that others make money with our work.
    Does anyone know of a good list of OpenSource (APL,BSD,etc.) projects which have been packaged as-is and sold commercially? I've always wondered just how common this is. Since the argument comes up so often that this is a good reason to use GPL it must happen quite often to APL/BSD projects. Anyone?
  53. GPL[ Go to top ]

    LGPL would allow commercial vendors to add closed source to the FileRA and package as a commercially sold component. We don't like the idea that others make money with our work.
    Does anyone know of a good list of OpenSource (APL,BSD,etc.) projects which have been packaged as-is and sold commercially? I've always wondered just how common this is. Since the argument comes up so often that this is a good reason to use GPL it must happen quite often to APL/BSD projects. Anyone?
    People also forget that this is a 2 way street: in a less restrictive situation, other people would make money out of author's work, but they usually give something back (patches, improvements, etc.). And then the original author makes more money out of other's addition to the original project, and so on. Everybody wins. Unless someone in the chain doesn't like to make money at all, which is very unlikely. ;)

    Regards,
    Henrique Steckelberg
  54. Commercial use of open source[ Go to top ]

    Actually at least three firewall vendors just had been convicted by German courts for putting GPLed Linux Firewall software into a micro hardware sold as a black box firewall appliance (without paying once cent of licence fees to the developer community).
  55. Commercial use of open source[ Go to top ]

    Actually at least three firewall vendors just had been convicted by German courts for putting GPLed Linux Firewall software into a micro hardware sold as a black box firewall appliance (without paying once cent of licence fees to the developer community).
    Great, but that's not what I asked for. If people are breaking the license, fine, that is one thing. Then the license doesn't matter anyway.

    I want to know if there is a list, or simply any anecdotal evidence at all, of instances where APL/BSD'ed code has been packaged as-is and sold commercially (addendum: and where the commercial aspect is more than just "we charge for the CD").
  56. Commercial use of open source[ Go to top ]

    Maybe you have not understood. They have taken GPLed software, did not change it, put it into a box, and sold it. This is what you wanted to know. They did not develop any "greater work", they did not develop the hardware. They didn't do any work besides putting the software on the EPROM. Since an EPROM is more or less the same than a CD-ROM (from the view of what you use it for) they just did what you said no one is doing.
  57. Commercial use of open source[ Go to top ]

    Maybe you have not understood. They have taken GPLed software, did not change it, put it into a box, and sold it. This is what you wanted to know.
    Nope. Read again what I said.

    Then again, don't bother. I know everything I need to know for now.
  58. Blanket Rules against GPL[ Go to top ]

    I am contracting with a company that has a lot of code in their EJB's calling files out on the file system. There are things that need to be updated in the database and on disk. ***It was that way when I got there don't ask.*** The app server throws strange errors sometimes when accessing the file system code. I would love to try this library, but that company has a hard fast rule about NOT using or allowing any GPL code. LGPL yes, but GPL no.

    Does anyone else work with/for companies that also have blanket rules against GPL??
  59. I am contracting with a company that has a lot of code in their EJB's calling files out on the file system. There are things that need to be updated in the database and on disk. ***It was that way when I got there don't ask.*** The app server throws strange errors sometimes when accessing the file system code. I would love to try this library, but that company has a hard fast rule about NOT using or allowing any GPL code. LGPL yes, but GPL no.Does anyone else work with/for companies that also have blanket rules against GPL??

    Well, I believe that any company that sells software and that has a license departement actually forbids the use of GPL. That makes perfect sense.
    Personally I know that Alcatel and Philips do that.
  60. Hi out there on the GPL battle field!

    Seems some of you have really big problems using or understanding the GPL. I understand that you really like FileRA and want to use it in companies that don't like the GPL. While it actually is a political target of mine to force those companies to support GPL, I don't want to leave you in the lurch. So if you really want FileRA to use in those "GPL-Hating-Companies", here is my offer.

    We (the authors of FileRA) actually think about offering a different licence besides GPL. Since we are only two, this should be possible.

    Actually the invariants here are:

    - If you want to use our work for free, learn to live with the GPL. There will never be another licence for people that are not willing to pay us for the work we did. Fullstop.

    - If your only problem is the GPL, just tell us what it is worth your company to get FileRA (no support, no warranties) without GPL (in EUROs per Developer / End User). We can then calculate the market price of the non-GPL out of this. I think this is most fair since this allows us financing our further work on the project.

    - If you don't like FileRA at all, or if you think that you or someone else doesn't need FileRA at all: I will do no further discussion with you since all is said in that thread. Please stop sending me emails with contents like 'you only try to make money with vaporware'. Actually this is not my intension. Fullstop.

    - Actually since its very early days the project is open to receive donations. Since no one pays us for writing FileRA, and bread doesn't fall from heaven (at least this didn't happen in the past two thousand years AFAIK), there is another offer. Tell us what it's worth to make FileRA providing XA or LocalTransactions. I think it should be able to code some algorithm inside it. Thank you for every single Euro: We can see how much you appreciate our software by each single Euro we obtain.

    Have lots of fun
    Markus KARG, Author of FileRA
  61. Focus[ Go to top ]

    I think everyone agree that:
      - you have made an excellent product
      - you are free to license it as you want

    The critique is not against you or against your product
    but against the fact that GPL license and the way
    big companies traditionally do business is not too
    compatible.

    Now you have offered a dual license (like MySQL) to
    get rid of any redistribution/linking issues.

    I hope you make a lot of money on it.

    I fear that most of the anti-GPL'ism was more of a
    "I always complain when I hear about a GPL product"
    that potential customers.
  62. I don't want to get rich.[ Go to top ]

    Thanks for your words. Actually I did not write FileRA to get rich and I did not offer the dual licence to make lots of money. I offered it to allow those companies that complain about the virality of GPL to use my work by in turn paying me for the spare time I have spent and will spend in future. Not more. Not less.
  63. Markus,

    I am curious about some things here:
    - What IDE are you using to develop FileRA?
    - What Operational System are you using to develop FileRA?
    - What libraries are you using to develop FileRA?
    - What tools (ANT, XDoclet, etc.) are you using to develop FileRA?

    The point is, unless you have paid for every single software used during FileRA development, you yourself will be making money off other's free work with your dual-licence deal. If this is the case, I can't see why you should impose this on other people when you can't obey to this "political law" yourself.

    Regards,
    Henrique Steckelberg
  64. The Non-GPL Deal[ Go to top ]

    To be honest, after so many people are not satisfied with the way I am doing my gifts to you, I play with the idea not to write any open source any more. No Joke.

    Actually I am using Eclipse on SuSE Linux, not using any libraries besides Sun J2SE. I am using only one tool, ANT.

    All of those tool vendors can use my work for free, they don't have to pay. But they must live with GPL then. So I can't see that I make money with other's work -- they are free to use my work for free if they in turn publish the larger work for free. I don't want to get rich from their work.

    Eclipse was not paid but I helped them with a lot of other work, e. g. tracking bugs etc. It was not always to my own interest and I spent several nights on tracking them. In addition, if they decide to take a fee, I'll pay that.

    SuSE is paid and in turn pays some developers and projects. Also I have paid several developers that fixed some bugs. I am one of those few that pay for open source actually.

    ANT was not paid but if they decide to take a fee I will pay that, for sure.

    It is not my intention to get rich. I only want to get paid for my work from those that are not pleased with the fact that FileRA is GPL.
  65. While it actually is a political target of mine to force those companies to support GPL...

    It's good to have a dream... but I work for a bank. If we use FileRA, we would have to GPL our software, and release the source code to our competitors. For some reason they don't want to do that! This is why companies impose a blanket ban on internal use of GPL software: they just can't accept the terms of the license.

    I fully support your right to release your code under whatever license you choose, but you should at least make that choice from a position of knowledge rather than ignorance. You have misunderstood the GPL if you think FileRA can be used from any non-GPL application. It cannot. If that is your intention then fine, it's your code, good luck to you.
  66. What's your problem, actually?[ Go to top ]

    I do not force you to use FileRA.
    If you want to use it, just write a letter to my personal email and we can negotiate on this. No problem. If I don't get your letter, I know how to judge this whole thread.
    Markus
  67. What problem?[ Go to top ]

    Please calm down, I don't have a problem at all. You made some inaccurate statements about the GPL, I sought to correct you, nothing more.

    Like I said, it's your code, you have the right to choose the license. You seemed to think that people who work for commercial organisations would be able to use FileRA under GPL. Now that you have made your kind offer of an alternative paid license, those people can in fact use it if they need to. Seems like a beneficial result for all, no?

    [As for whether I need it personally... not at the moment, no. I will contact you if and when I do.]
  68. I work for a bank. If we use FileRA, we would have to GPL our software, and release the source code to our competitors.

    Only if you distribute your software to your competitors. I have worked for several banks too, and none have distributed their software. GPL only mandates binaries to be accompanied with sources, not to openly divulgate your software contents to the whole world. GPL may be used in military or banking business, as the software receivers are not very tempted to redistribute it.
  69. To heat up the war a bit... ;-)[ Go to top ]

    Seems some of you like to discuss just for fun. So here is something for those. The Linux Kernel itself is GPLed and since any application running ontop of it needs to load and use APIs of the Kernel, you might think that those applications have to be GPLed as well. But actually Linus Torvalds wrote that (quote from the Linux Kernel docs):

       NOTE! This copyright does *not* cover user programs that use kernel
     services by normal system calls - this is merely considered normal use
     of the kernel, and does *not* fall under the heading of "derived work".
     Also note that the GPL below is copyrighted by the Free Software
     Foundation, but the instance of code that it refers to (the linux
     kernel) is copyrighted by me and others who actually wrote it.

    Have Fun
    Markus
  70. It is clear that you don't like people dictating what license you should use, and I can undertand that. But by adopting GPL, that is exacly what you are doing with anyone interested in your work, forcing them to adopt GPL in their work, something you have nothing to do with.
  71. Linus is s smart guy[ Go to top ]

    Ofcourse he interpret GPL and linking this way.

    Else it would be impossible to create non-GPL applications
    on Linux (I can not imagine a Linux application not
    using the kernel).

    I am sure that they are very happy to see many GPL
    applications, but they do not want to mandate only GPL.
    What they want to protect via GPL is their stuff. If I
    create a closed source operating system containing some
    of their code, then I will hear from their lawyers.

    And a call to the Linux kernel shuld be very similar to
    a call to a database.

    Even the fact that the kernel call probably goes through
    some LGPL glibc code and that the JDBC calls goes through
    some SUN classes match.

    If everybody were software engineers then I doubt that
    we would have so many license problems. But we have
    some lawyers too !
  72. Thanks for 1.5 connector[ Go to top ]

    I'm sorry to see you have gotten so much flak about the license that it has been detrimental to your great contribution to the community. I've been researching make/buy on these 1.5 JCA connectors and they are not all that trivial to write and not widely available at the 1.5 spec. Obviously since so many people are pee-od about the license there is a great interest in using the ra connectors in general. The tools to help build the 1.5 connectors are "yet to come". The protocol part is the tough area to find working source examples, unless the protocol is already available, like the "mail" protocol.
    I'm a little disapointed that the forum attacked the EJB spec like a swarm of locusts. I mean the spec is there and that is not an issue. We are just looking at a way to extend the spec with application integration. Too bad a lot of these discussions can't stay in scope. I am just grateful to have a working 1.5 connector with source to look at. I don't know how my company stands on GPL and I would be subject to our buyers rules also. I'll be watching the serverside to see what the resolution may be to the licensing issues.