Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2018

Because it's all 0s and 1s, I recently took a look at porting JNN, an RSS reader from java.net, to Mac OS 9-. This meant going from Java 2 (which is Java 1.2+, currently 1.5) to Java 1 (1.0-1.1.x).

As it turns out, initially the biggest pain in the rear when porting is removing all the Swing extensions these people have added, like this silly Rounded Border. RoundedBorder gives, "Further mac prettification" like "Rounded borders on Mac".

How unJava can you get? To think this originally was a project by Mr. Java himself, James Gosling. What we have here is a number of hacks to the UI not in a separate package, much less where it should be, in a customized, pluggable Swing Look and Feel, but in the root of the app itself. There's no easy way to weed this out, which completely eliminates the advantage object oriented design provides.

This means JNN's design is failing on a number of counts. It does not properly compartmentalize GUI from backend. It does not use Swing's Look and Feel support adequately. It is targeting one platform to the detriment of the code's use on others (Mac over everywhere else). These are silly biases that are all examples of bad coding. Shame.

(Note: To Gosling's credit, when I downloaded jnn originally I don't believe it had any (no obvious, anyway) nonstandard GUI widgets.)

In other news, Blogger finally lets you publish images with your blog, up to 300 megs of 'em. Phew. I'd finally give Flickr a shot and posted one image with them a while back, but this is scads easier. Thanks, Google/Blogger/Microsoft. (Yes, the MS ref is hopefully a joke.)

The LGPL and Java:

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work.

That's why the LGPL is no good; this is an exploitable hole to allow people to modify a library and start reverse engineering your code, it would seem. I'm not real sure why that's bad, but I do know it's not something I'd particularly want butting up next to my proprietary code.

Perhaps this is why a number of pay-to-play companies run a secondary, "Free as in Mozilla Public License" codebase. Having grown out of the need to recreate Netscape, not to become part of an idealistic Hurd, the MPL watches companies' backs well. Too well.

Here's the metaphor I heard that got me interested in the LGPL (IANAL):

You're making a calculator. You've got every button down except the square root button. You decide to look at external libraries to save time.

GPL Square Root -- You can embed the function and sell your software, but now every bit of your calculator, plus, minus, 1s, 5s, the whole thing, must be released with full source code. Now anyone can take your code and sell your application. Anyone. Not necessarily a bad thing, unless you like to make money. Everyone can use your first-rate natural log function, but do remember that they, too, can't sell this [legally] without showing the code to anything they've added. Great for promoting passive collaboration.

LGPL Square Root -- Originally, before the Java issue, I thought the LGPL went like this: You can add this square root function, release and sell your app. You only have to include source to the square root function; everything else can stay proprietary. Let's say, however, that you find a bug in the square root function, say it thinks the square root of 49 is 8, but gets everything else right -- or that it only goes to 5 decimal places. If you fix the bug or extend its accuracy to 10 decimal places, you have to release the source to those improvements with your app. Personally, that's great so far. I like it. If you only have the function b/c of someone else's contribution, you owe it to him/her/them to release your improvements for all to use. It enables passive collaboration, but still allows you to protect your investment. Nobody "deserves" your fancy natural log function if you don't want to give it to them. It was entirely your work. Keep it. The "rights" to the code are protected from both sides, and fairly. You'd also owe the 'LGPL' a big thank you, of course, but you get the point.

BSD Square Root -- Take it. Sell your app. You might have to acknowledge the project whose work you took, but that's it. It's yours. Take it from 5 to 10 decimal places of accuracy, heck, take it to 2000, and you don't have to share a keystroke. Great for greedy people who don't want to be bothered, but I'd hope they'd feel a little bad about taking work to which they didn't -- nor will -- contribute.

MPL Square Root -- You can take this square root function, release, and sell your app. In fact, you could (afaict) take your own square root implementation, take a few files from the MPL version, and put those together to be released. Your own, wholly original code could stay closed, and only changes you made to MPL files would need to be released. Initially, I thought the MPL was like BSD. As is obvious here, it's not. It's sort of like the LGPL in that your code can be released in support of and as part of a closed source product, but it's "file-level" in that any file of your library could potentially be taken and used in a new context. But it's as close to the LGPL as you can get if you want to allow someone to compile your code alongside proprietary code, and it doesn't seem exceptionally evil. It's a good deal less protective than the LGPL, but just good enough that I still like it. (MPL section added 20131011.)

Okay, comparison over. But now, following the relatively dated quote about Java issues, above, (iff the Java issue is legit) the LGPL forces anyone using the square root function to allow anyone to decompile their entire app that uses the square root function to "bug check" against their code.

That's simply not a place I want people going. Short of the square root function, it's my code. Stay out. If you want my code to work, use the old library that thinks 49's square root is 8. If you can upgrade the lib to work with 49, great, but why should I have to give you any rights to my code downstream of the square root function to make that happen? You didn't make the investment in app, and I want to protect it. That should be my right. You shouldn't get to peek at my natural log function if I've used LGPL code elsewhere. If your change to the square root -- and who knows how inane that change might be; perhaps it also now doesn't do 36 correctly -- breaks compatibility with my app, that's my problem. I'll fork the square root lib if I have to.

Oh well, guess I'll eventually have to start my GNG (GNG's Not GNU) movement with an LGPL done, if not right, then fair. Might be as easy as slashing Section 6 in the LGPL; I'll have to check sometime. Now, on to UO (I'm on sabbatical from WoW)!

Labels: java, lgpl, licensing

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Sunday, July 31, 2005
SourceForge.net: Project Info - jOneOne (help porting Java 2 to Java 1) About time I added some files to this project: Partially automate porting Java 2 code to Java 1.1 (for Mac Classic or the MS JVM) with jOneOne. Makes a copy of your Java 2 codebase, changing references from Java 2 objects to the Java Collections API for Java 1.1 [and some other stuff]. posted by ruffin at 7/31/2005 03:40:00 PM
0 comments
Friday, July 22, 2005
Open source makes you innovate From eWeek for June 20th, 2005, "Driving Progress": "Open source challenges the commercial software industry to add value and innovate. It eliminates the 'easy street' of charging people a lot of money for something that doesn't have much innovation in it." -- Joe Alsop of Progress Software Corp. That's pretty much it, bang on. Open source doesn't do too many fancy tricks, or at least not many fancy tricks that are new, but it does do a good job replicating what's been out there a while. If you don't make it new, open source ensures you're not needed. posted by ruffin at 7/22/2005 02:16:00 PM
0 comments
Wednesday, July 20, 2005
Hacknot - Beware The GUI Builder Hacknot - Beware The GUI Builder: Of course, as long as there are uninformed managers with access to the company purse, GUI builders will continue to be sold on the basis of their novelty and unsubstantiated claims to productivity improvement. That or Microsoft will help the economy make millions upon millions with VB6, which is, in large part, successful precisely because of the quality of its GUI builder. Was also surprised to find this link from some of the links Gosling put into JNN; are we supposed to like Matisse or aren't we? What's with this throwback, machine language lover? GUI builders are great. They have limitations. You may very well have to recode something to get functionality past a certain point. But GUI builders are just more tools for your box. Get to know how to use them, integrate them into your workflow efficiently, understand what they're doing and how to upgrade them, and you'll do alright. Trust me. ;^) posted by ruffin at 7/20/2005 04:05:00 PM
0 comments
Sunday, July 10, 2005
JNN Jive Because it's all 0s and 1s, I recently took a look at porting JNN, an RSS reader from java.net, to Mac OS 9-. This meant going from Java 2 (which is Java 1.2+, currently 1.5) to Java 1 (1.0-1.1.x). As it turns out, initially the biggest pain in the rear when porting is removing all the Swing extensions these people have added, like this silly Rounded Border. RoundedBorder gives, "Further mac prettification" like "Rounded borders on Mac". How unJava can you get? To think this originally was a project by Mr. Java himself, James Gosling. What we have here is a number of hacks to the UI not in a separate package, much less where it should be, in a customized, pluggable Swing Look and Feel, but in the root of the app itself. There's no easy way to weed this out, which completely eliminates the advantage object oriented design provides. This means JNN's design is failing on a number of counts. It does not properly compartmentalize GUI from backend. It does not use Swing's Look and Feel support adequately. It is targeting one platform to the detriment of the code's use on others (Mac over everywhere else). These are silly biases that are all examples of bad coding. Shame. (Note: To Gosling's credit, when I downloaded jnn originally I don't believe it had any (no obvious, anyway) nonstandard GUI widgets.) In other news, Blogger finally lets you publish images with your blog, up to 300 megs of 'em. Phew. I'd finally give Flickr a shot and posted one image with them a while back, but this is scads easier. Thanks, Google/Blogger/Microsoft. (Yes, the MS ref is hopefully a joke.) posted by ruffin at 7/10/2005 05:52:00 PM
0 comments
The LGPL and Java The LGPL and Java: If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work. That's why the LGPL is no good; this is an exploitable hole to allow people to modify a library and start reverse engineering your code, it would seem. I'm not real sure why that's bad, but I do know it's not something I'd particularly want butting up next to my proprietary code. Perhaps this is why a number of pay-to-play companies run a secondary, "Free as in Mozilla Public License" codebase. Having grown out of the need to recreate Netscape, not to become part of an idealistic Hurd, the MPL watches companies' backs well. Too well. Here's the metaphor I heard that got me interested in the LGPL (IANAL): You're making a calculator. You've got every button down except the square root button. You decide to look at external libraries to save time. GPL Square Root -- You can embed the function and sell your software, but now every bit of your calculator, plus, minus, 1s, 5s, the whole thing, must be released with full source code. Now anyone can take your code and sell your application. Anyone. Not necessarily a bad thing, unless you like to make money. Everyone can use your first-rate natural log function, but do remember that they, too, can't sell this [legally] without showing the code to anything they've added. Great for promoting passive collaboration. LGPL Square Root -- Originally, before the Java issue, I thought the LGPL went like this: You can add this square root function, release and sell your app. You only have to include source to the square root function; everything else can stay proprietary. Let's say, however, that you find a bug in the square root function, say it thinks the square root of 49 is 8, but gets everything else right -- or that it only goes to 5 decimal places. If you fix the bug or extend its accuracy to 10 decimal places, you have to release the source to those improvements with your app. Personally, that's great so far. I like it. If you only have the function b/c of someone else's contribution, you owe it to him/her/them to release your improvements for all to use. It enables passive collaboration, but still allows you to protect your investment. Nobody "deserves" your fancy natural log function if you don't want to give it to them. It was entirely your work. Keep it. The "rights" to the code are protected from both sides, and fairly. You'd also owe the 'LGPL' a big thank you, of course, but you get the point. BSD Square Root -- Take it. Sell your app. You might have to acknowledge the project whose work you took, but that's it. It's yours. Take it from 5 to 10 decimal places of accuracy, heck, take it to 2000, and you don't have to share a keystroke. Great for greedy people who don't want to be bothered, but I'd hope they'd feel a little bad about taking work to which they didn't -- nor will -- contribute. MPL Square Root -- You can take this square root function, release, and sell your app. In fact, you could (afaict) take your own square root implementation, take a few files from the MPL version, and put those together to be released. Your own, wholly original code could stay closed, and only changes you made to MPL files would need to be released. Initially, I thought the MPL was like BSD. As is obvious here, it's not. It's sort of like the LGPL in that your code can be released in support of and as part of a closed source product, but it's "file-level" in that any file of your library could potentially be taken and used in a new context. But it's as close to the LGPL as you can get if you want to allow someone to compile your code alongside proprietary code, and it doesn't seem exceptionally evil. It's a good deal less protective than the LGPL, but just good enough that I still like it. (MPL section added 20131011.) Okay, comparison over. But now, following the relatively dated quote about Java issues, above, (iff the Java issue is legit) the LGPL forces anyone using the square root function to allow anyone to decompile their entire app that uses the square root function to "bug check" against their code. That's simply not a place I want people going. Short of the square root function, it's my code. Stay out. If you want my code to work, use the old library that thinks 49's square root is 8. If you can upgrade the lib to work with 49, great, but why should I have to give you any rights to my code downstream of the square root function to make that happen? You didn't make the investment in app, and I want to protect it. That should be my right. You shouldn't get to peek at my natural log function if I've used LGPL code elsewhere. If your change to the square root -- and who knows how inane that change might be; perhaps it also now doesn't do 36 correctly -- breaks compatibility with my app, that's my problem. I'll fork the square root lib if I have to. Oh well, guess I'll eventually have to start my GNG (GNG's Not GNU) movement with an LGPL done, if not right, then fair. Might be as easy as slashing Section 6 in the LGPL; I'll have to check sometime. Now, on to UO (I'm on sabbatical from WoW)! Labels: java, lgpl, licensing posted by ruffin at 7/10/2005 02:27:00 PM
0 comments
Tuesday, July 05, 2005
Nvu - The Complete Web Authoring System for Linux, Macintosh Finally! A complete Web Authoring System for Linux Desktop users as well as Microsoft Windows and Macintosh users to rival programs like FrontPage and Dreamweaver. Okay, well, that description's pretty pie in the sky, but what you do get -- for nothing and Mozilla licensed in case you're a hacker and want to make it your own -- is a standalone version of the Mozilla Composer, which, as I think I've said before, is the best html WYSIWYG editor you can use. Why is Composer, and now Nvu, so good? There's nothing fancy about it at all. No extra stylesheets, no MS-specific additions, no wacky spin put on existing html code that's opened -- the thing just edits well, stays standards compliant, and runs quickly in most anything approaching three year-old hardware. It's so light-weight, any nontechie schmoe can create not just web pages, but web pages any true htmler can cut and place into their own code in seconds without thinking twice. Great job, Moz and Nvu. (Boy, lots of back patting recently on mfn...) posted by ruffin at 7/05/2005 01:35:00 PM
0 comments