Attached is a screenshot of OS X with JEmplode running. I used the genericUNIX installer. The install was without problem. I managed to fumble thru the internet control panel. (That took a little trial and error) I haven't figured out how to launch JEmplode from the finder. Currently I have to open a shell and key in the program name. --Glenn

I haven't figured out how to launch JEmplode from the finder. Currently I have to open a shell and key in the program name.If you have the developer tools installed, there's a tool called "MRJAppBuilder" which lets you make a double-clickable app out of any Java program; it's slightly nontrivial to use, though - if there's enough demand (read: if one or two people want it :), I'll do one for the current release of JEmplode (ok, a very slightly patched version of the current release that fixes an ID3 bug) and make it available. The next version of JEmplode, whenever that happens, will certainly have a Mac OS X-specific "installer" (probably a disk image :) - sadly, I've had little time to work on it lately (I don't know how much time Mike has had either), and what time I do get to put in on it in the near future will likely be spent working on 1.1 compatibility...

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Hey Dan, three quick questions for you...
Have you had a chance to work on replacing the ID3 parser (as you may recall I have a bunch of files that the ID3lib based parser pukes on)?
Any chance of that making it into the next release?
I seem to remember you or Mike talking about an OS X version a while back, where you thinking of doing a Cocoa port (that would be cool) or just a MRJAppBuilder wrapped AWT version?

-Mike

Edited by mcomb on 07/04/01 08:45 PM.

I would _love_ to do a Cocoa port of the UI - and I will probably do so, eventually, but at the moment I just don't have the time. So the OS X version will just be an MRJAppBuilder-wrapped one, for the time being.As far as the ID3 library is concerned, I haven't dropped the new one in yet, but I will sometime soon; it's just a matter of figuring out how the licensing of JEmplode will affect it, because I have no intention of releasing the new ID3 library (which was developed a long while ago, before JEmplode even existed) under the GNU General Public License.

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

I'm not totally familiar with all parties concerned, but... are you the copyright holder on both items (the library and JEmplode)? If so, you could release the code with whatever licensing restrictions you want (code X is under GPL, code Y is licensed under BSD, or whatever)

Well, Mike Schrag is the original copyright holder of JEmplode (though I believe the copyright on the latest version is listed as us jointly holding it); I didn't jump into the project until fairly recently, and most of what I've done so far has been optimizations and interface touchup. I (with a colleague) am the copyright holder on the new ID3 library code I'd like to drop in, which has not seen any kind of public release yet. However, the copyright ownership on these things doesn't matter - because while we could very easily release JEmplode under, say, a BSD license if it was just our code, the emptool code from Empeg which is ported as part of JEmplode's underlying libraries is licensed under the GPL. Ports of GPL software must be licensed under the GPL; thus JEmplode's underlying libraries must be licensed under the GPL; thus - unless we do bizarre Java reflection trickery such that JEmplode isn't really "linked against" the GPL'd libraries, which is costly both in programmer sanity and in application performance - JEmplode itself must be licensed under the GPL. :(

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

Ports of GPL software must be licensed under the GPL

Is this right? I thought rewriting a (say) C++ program in Java counted as reverse-engineering, not porting, and so the author of the C++ possessed no copyright over the Java.

Or does JEmplode use our libraries directly, via JNI? (which can't be right -- how does it run on MacOS?)

Peter

From the GNU General Public License:

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)

and

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

and

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

These pretty much combine to tell me that since Empeg's libraries were directly ported to Java, they, and thus all of JEmplode including any other libraries I choose to link into it later, must be released under the GPL (or released in multiple "pieces", which isn't really practical for users). Of course, if you take "language" in the first paragraph to mean "spoken language" (ie: translating a program's interface) rather than "programming language) (ie: translating a program's code), then we could release it under a different license; but I'm not at all clear on which one is the correct interpretation.

Perhaps Empeg can release a BSD-licensed version of the emptool libraries? (I think I already asked once, but it never hurts to ask again... :)

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

DMZ,

Thanks for the pointer to MRJAppBuilder. I've been able to get my mac setup to execuite fron an icon.

I took the downloads, jempeg-1.0b1.jar jempeg-0.9.14.jar jempeg-0.9.13.jar, and subjected each to the MRJAppBuilder. For each I was able to achieve an execuitable ".app".

What was interesting, and I'd like your viewpoint on, is that the0.9 revs yielded an execuitable that had complete Aqua look and feel. While the latest 1.0 looked like what I have seen under linux.

The only difference in building the .app was to callout a different jar and specify the main class that seemed correct for
that jar.

--Glenn

PS I cross posted this on the forum on sourceforge too.

Edited by gbeer on 11/04/01 09:11 PM.

What was interesting, and I'd like your viewpoint on, is that the 0.9 revs yielded an execuitable that had complete Aqua look and feel. While the latest 1.0 looked like what I have seen under linux.

This is expected behavior. In the 1.0b1 release, we force the Java Metal look and feel, because - in my judgement - the Aqua look and feel doesn't work right with JEmplode. You may notice missing controls, text boxes of incorrect sizes, button spacing which is just plain wrong, and other problems which make it not conform to the Aqua HI guidelines; and until it conforms, it probably shouldn't be used that way. Making it conform from within Java is very difficult (because you need to special-case lots of stuff, like "if I'm on Aqua, buttons need to be X pixels apart, but if I'm on Metal, they need to be Y pixels apart, and on Windows they need to be Z pixels apart"); so just using Metal really made the most sense.

When/if I get a chance to make a pure Cocoa version of the JEmplode UI, it will of course be fully Aqua-compliant. :)

-Dan


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

These pretty much combine to tell me that since Empeg's libraries were directly ported to Java, they, and thus all of JEmplode including any other libraries I choose to link into it later, must be released under the GPL (or released in multiple "pieces", which isn't really practical for users).

Ah yes, looks like you're right. That's not how I'd thought the GPL works (I didn't realise that a translation would retain the original copyright -- I assumed the JEmplode authors would be considered the copyright holders). So JEmplode must be released under the GPL.

Peter

Unless we offer an alternative licence for our code to the authors of JEmplode, which I believe we could do because as copyright holders we can do what we want. I can see that being a legal headache though, so we would need a quite compelling reason.

Rob

Making it conform from within Java is very difficult (because you need to special-case lots of stuff, like "if I'm on Aqua, buttons need to be X pixels apart

Haven't any of the UI builders gotten sofisticated enough that the layout of the UI can be made parametric? By parametric I mean that the placement of UI objects are defined with respect to each other instead of some absolute position in the window. Where the minimum size of a window is limited by the stackup of objects within it.

Ack.. Or is it just that those builders are still too expensive for widespread use?

--Glenn

the original post ate the paragraph spacing. I hope this edit fixes it.
It did. All I did was add these lines.

Edited by gbeer on 12/04/01 04:24 PM.

Haven't any of the UI builders gotten sofisticated enough that the layout of the UI can be made parametric? By parametric I mean that the placement of UI objects are defined with respect to each other instead of some absolute position in the window. Where the minimum size of a window is limited by the stackup of objects within it.

Java's built-in layout managers do this (mostly, anyway); the problem is not that everything has to be laid out absolutely, but rather that the restrictions which must be placed on things (button spacing, control height, button _ordering_ for things like OK and Cancel, etc) are completely different between Aqua, Windows, Metal and Motif; and so there are 2 choices:

1. Write 4 separate versions of the GUI classes, and distribute 4 versions of JEmplode.

2. Write one version which decides at runtime which layouts to use.

Neither is terribly convenient. Hence, we just have a single version right now, which does Metal. :(


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

I'm not sure I understand how one could run into legal problems here; it's perfectly legitimate to license something both under the GPL and another license. Unless you're worried about people taking the emptool source, making a product out of it, and selling it - in which case, the "another license" can be something like: You can use this software for whatever you want, including basing other software products on it, but you need to leave the copyright notice intact and you can't make a profit from any derived work without the express written permission of SonicBlue. With appropriate legal language, of course; I'm pretty sure one of the various public source licenses out there would serve as a good model for this.

I can't really think of a compelling reason for you guys to do it other than "I'd be far more comfortable with emptool not being licensed under the GPL, so that I can be free to use non-GPL'd components for future enhancements to JEmplode," though. :)


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

I didn't mean legal legal problems, I meant a) explaining the issues to our legal department and b) getting them to sanction a new licence, which would probably take the form of a signed agreement between you and us.

When possible I like to avoid tasks that involve legal departments

Rob

Ah. Yes, that's quite understandable. :)

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

I didn't mean legal legal problems, I meant a) explaining the issues to our legal department and b) getting them to sanction a new licence, which would probably take the form of a signed agreement between you and us.

When possible I like to avoid tasks that involve legal departments


Quite understandable sentiment

However, you can simply state in the file containing the license that the code is licensed either under GPL or BSD license, whichever the user prefers (and include text of both). For example, Larry Wall licenses (or at least used to) his Perl under either GPL or his own 'Artistic' license, whichever the user chooses. (If I understand correctly, DMZ would be happier with BSD than GPL, because it is even more liberal, being less paranoic about somebody linking BDS-licensed code with 'enslaved' (as opposed to free in RMS sense) software ).

Finally, you can put the code into public domain, relinquishing copyright rights entirely. Of course, good people like those writing Jemplode and such would still continue aknowledging the code origin.

Cheers!


Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Alas, I've been really busy with work for the past several weeks and haven't been able to touch the code. I will definitely get back into it, though. However, like Daniel mentioned, the majority of our time will probably be spent on 1.1 when we both get to program again :)

Mike

At long last ... I was always concerned about this issue, but stricken by laziness to look it up. I assumed that this was the case so I released JEmplode under GPL. But I was wondering if it was officially covered in the license.

Was the Java linking + GPL issue resolved? I was never certain if it is technically required that your library be placed in GPL. For instance, I wonder if we could create an interface and some system properties that would let the user optionally install your ID3 package (that would conveniently implement an identifical interface in an identically named package).

I apologize to people who are having problems with ID3 parsing... That was a very last-minute addition to JEmpeg, and it was kind of a frantic weekend port of id3lib to Java. It appears to also be the hokiest of the code in there as well.

Mike

We could create an interface with some system properties and let people download the ID3 library separately, but I really don't think that'd be convenient - either for people to install or for us to maintain. I also think that, technically, it might still be a violation of the GPL; most of the FAQs out there on the 'net seem to indicate that dynamic linking of non-GPL software with GPL code is verboten.

:(


-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

That sucks.

Interestingly, I found a message from Linus on a mailing list that says that he interprets kernel modules as not necessarily _having_ to be GPL'd... I can't imagine that an ID3 module would be any different (though I agree with your issue of complexity of user experience). The biggest problem on this one, is that it appears to be a bit of a matter of interpretation, which is tough since I'm already second in the chain (i.e. I certainly can't grant anything _more_ than what Empeg grants me).

Oh well... We'll leave it for the lawyers ... In the meantime, we hokey ID3 parsing :)

Mike

Interestingly, I found a message from Linus on a mailing list that says that he interprets kernel modules as not necessarily _having_ to be GPL'd...

Not quite. Linus grants an exception from the GPL for kernel modules that follow the standard module interface. In other words, the kernel is licensed under a modified version of the GPL. That's a little bit iffy, since it doesn't say so anywhere in the kernel sources (I think), and there's a lot of code in there that's not copyrighted by Linus and simply says "licensed under the GPL".

Borislav