crynwr.com · Domains · Slashdot Mirror

Google WebM Calls "Open Source" Into Question

News · Opensource · 2010-05-28 08:33 · posted by Soulskill · from the branding-is-everything dept. · 185 comments

snydeq writes "As open source becomes mainstream, vendors are under pressure to market their offerings using the 'open source' brand to the highest degree possible — a trend that may eventually degrade the meaning of 'open source' as we know it, Savio Rodrigues writes. Witness WebM, which Google has positioned as an open alternative to H.264. After examining the software license, some in the open source community have questioned whether WebM should be classified as open source software. Google did not use an OSI-approved license for WebM, meaning that, at least in theory, WebM cannot be considered open source under the OSD — the 'gold standard' by which many government and business open source policies are defined. Moreover, when prodded for OSI review, Google required that the OSI agree to 'changes to how OSI does licenses' as a precursor to submitting a license for OSI review and approval. 'When Google, one of the largest supporters of open source, goes out and purposefully circumvents the OSI, what signal does this send to other vendors? How important is using an OSI-approved license likely to be in the future if other vendors follow Google's lead?'" An anonymous reader adds: "It turns out that libvpx, Google's VP8 library, isn't compatible with the GPLv2. Google is apparently aware of the problem and working on a solution.

Working Toward a Patent-Agnostic Open Source License

Yro · Patents · 2009-04-09 09:43 · posted by timothy · from the balancing-interests dept. · 124 comments

Glyn Moody writes "Are there ever circumstances when software patents that require payment might be permitted by an open source license? That's the question posed by a new license that is being submitted to the Open Source Initiative (OSI) for review. The MPEG Working Group wants to release a reference implementation of the new MPEG eXtensible Middleware (MXM) standard as open source, but it also wants to be able to sell patent licenses. If it can't, it might not make the implementation open source; but if it does, it might undermine the fight against software patent proliferation."

OSI Approves Microsoft Ms-PL and Ms-RL

Gnu · 2007-10-16 11:48 · posted by ryuzaki0 · from the left-hand-right-hand dept. · 301 comments

Russ Nelson writes "In a board meeting held October 10th and announced today, the Open Source Initiative approved two of Microsoft's software licenses: the Microsoft Reciprocal License and the Microsoft Public License. These licenses are refreshingly short and clean, compared to, say, the GPLv3 and the Sun CDDL. They share a patent peace clause, a no-trademark-license clause, and they differ only in the essential clause of reciprocation. Of course, Microsoft is not widely trusted in the Open Source world, and their motives have been called into question during the approval discussions. How can they be attacking Open Source projects on one hand, and seeking not only to use open source methods, but even to use the OSI Approved Open Source trademark? Nobody knows for sure except Microsoft. But if you are confident that Open Source is the best way to develop software (as we at the Open Source Initiative are), then you can see why Microsoft would both attack Open Source and seek to use it. It is both their enemy and their salvation."

NASA Open Source License Still Up For Discussion

Yro · Usa · 2004-02-21 12:03 · posted by timothy · from the tax-dollars-want-to-benefit-the-commonweal dept. · 132 comments

Russ Nelson writes "There's been plenty of heated discussion about the NASA Open Source License, but although the OSI board approved five licenses and sent back seven, the NASA License is still up in the air, so to speak, hehe."

Advocacy Prompts Reconsideration of Anti-GPL Letter

Gnu · 2002-10-26 04:00 · posted by ryuzaki0 · from the pen-is-mightier dept. · 263 comments

Many people have noted that there has been a reaction (see also this AP story) to the story posted a few days ago about the GPL in government. (More links: Wired, Newsforge.) This is good, I guess: Congress should consider carefully how the government licenses the code it funds, because it's an important public policy question: it shouldn't be decided by a backroom push from business lobbyists (the lead Representative listed, Adam Smith, represents a district fairly close to but not including Microsoft headquarters). There are certain things that bother me about this whole story though, and I'm going to try to trace the trajectory of it below.

As far as I can tell, it started with this Newsforge story (Newsforge is also part of OSDN, Slashdot's corporate parent). The Newsforge story was excerpted and copied by an Australian newspaper, and from there, it was off and spreading. The headline chosen, "Washington State Congressman attempts to outlaw GPL", is not particularly accurate, but it did a great job at stirring up outrage. Outlaw the GPL! Over my dead keyboard!

From there it really started making the rounds. It was repeatedly submitted to Slashdot with all sorts of flaming, incorrect commentary - in fact, after reading a dozen different submissions, I didn't think any of them were even close to accurate. I picked one and posted it, trying to do my best to a) provide an accurate headline and b) provide an accurate summary of the issue at stake in a few sentences. To recap again: when the Federal government creates computer code (or any copyrightable work) directly, it gets no copyright whatsoever and the work is true public domain (quirk of the U.S. copyright laws - the 50 states, corporations, individuals, and other legal entities all get copyrights automatically, but the Federal government does not). If you want to copy, reproduce, or sell an .mp3 of the U.S. Congress singing "God Bless America" after September 11, go right ahead: there is no copyright on it whatsoever. (Actually, the song itself is still under copyright, but Congress' performance of it wouldn't be...)

However, when the Federal government hires a non-employee to create code or copyrighted works, there is no clear rule regarding the copyright status of the work. Sometimes the contract calls for rights to the work to be assigned to the Federal government (the Feds don't get original copyrights, but if someone else gets an original copyright, the Feds can acquire it). Sometimes the contractor keeps the copyright and gets to do whatever they want with it. Sometimes the contract doesn't specify. Note that this is NOT a BSD-vs.-GPL dispute, not by a long shot. Very little code financed by the Federal government is ever licensed under either of these two licenses - the choice is basically agency-proprietary (the Federal agency asked for the rights in the contract, and kept them) or company-proprietary (the agency didn't ask for the rights, and the contractor kept them).

And most of the time it doesn't matter. I've written code for the Federal government as both a contractor and an employee, and 99% of it was so specific and customized that it would be of use to no one else, regardless of its licensing or copyright status. Probably the majority of code written for the Federal government falls into that category - internal use software for very specific needs.

But some of it is undoubtedly useful. Some major projects funded by the government in conjunction with academia have escaped from licensing purgatory, typically through the efforts of the researchers working on them who approach the issue from an academic freedom viewpoint and want to see their work widely adopted. GRASS is one major one that I know of. A commenter pointed out ADA as an example. For code which is useful to others, either a BSD-like or GPL-like license would be truly beneficial and easily defensible as a public policy choice. In the non-code world, the government makes choices like that all the time - it might choose to purchase a particular piece of land and commit to making it available to everyone forever by declaring it a National Park and committing to maintain it, a GPL-like philosophy; alternately, it might choose to just dump a particular piece of property on the market, putting it up for auction and letting the purchaser do what he wills with it, a BSD-like philosophy.[1] Either of these two options might be optimal; but paying for code which ends up remaining proprietary is like buying a new stadium to benefit a very specific corporation which owns a very specific sports team: the type of use of public funds which is generally seen as sleazy and the opposite of good governance.

Either of the first two choices can be appropriate in certain situations. What does not seem appropriate is paying for proprietary code, although this is generally what happens when the government contracts for code. Since the government has the ability to provide a benefit to the public (open code) at essentially zero cost, it should do so. An example which has struck me several times over the past few years: every airport in the world has the same problem, coordinating planes taking off and landing and keeping them from running into each other. Yet each nation (and often each airport) solves the problem over and over, paying heavily for custom-designed, one-shot software development. Imagine if the world's airports could simply install GNU-AirTrafficControl 2.7, and have a complete, working, bug-free and cost-free air traffic control system. It would cost every nation less to do it this way, but it would also make a lot less money for the consultants retained to develop these systems.

But leave off the advocacy for moment - I was following the story itself. As noted above, the outcry has prompted many of the other Representatives who originally signed the letter to reconsider. The AP story even suggests that some of the signatories were actively misled - that the letter they thought they were signing didn't mention the GPL at all. However it actually played out, some good has been done.

That's good. What's not so good is that much of the outcry was probably generated by stories titled "Washington State Congressman attempts to outlaw GPL". The right outcome occurred, but for the wrong reasons and in the wrong manner. I am left wondering whether the community would have made the same sort of response on this issue if every story that had been posted about it was 100% accurate and non-inflammatory.

[1] If you're not familiar with the BSD-like and GPL-like classes of software licenses, this won't make a lot of sense to you, so please read up if necessary.

Macromedia Applies For OSI Certification

Gnu · 2002-06-23 08:41 · posted by ryuzaki0 · from the what-will-they-release dept. · 186 comments

mpawlo writes "As reported by Greplaw, Macromedia, the company behind Flash-technology and more, has applied for open source certification of one of its licenses. The Macromedia license is based on the IBM Public License. You can see the Application for certification as well as the The Macromedia licence."

OSI Turns Down 4 Licenses; Approves Python Foundation's

Announcements · 2001-11-30 05:59 · posted by ryuzaki0 · from the keeping-the-updates-going dept. · 154 comments

Russ Nelson writes "The Open Source Initiative turned down four licenses this week. Not to name names, but one license had a restrictive patent grant that only applied to GPL'ed operating systems. Another was more of a rant than a license. Another was derived from the GPL in violation of the GPL's copyright. And the fourth had insufficient review on the license-discuss mailing list (archives). The one license that did pass was the Python Software Foundation License."

The Unofficial Guide to Lego Mindstorms Robots

News · Technology · 1999-11-24 02:14 · posted by Hemos · from the it's-like-dueling-banjos dept. · 76 comments

Quite a number of you out there are into Lego Mindstorms, as evidenced by the number of book reviews that have been sent my way. Below are a couple of reviews, one from Kurt DeMaagd and the other from Will Ware. Click below to get their take on the O'Reilly book The Unofficial Guide to Lego Mindstorms Robots. The Unofficial Guide to Lego Mindstorms Robots author Jonathan B. Knudsen pages 247 publisher O'Reilly & Associates rating 9/10 reviewer Will Ware & Kurt DeMaagd ISBN 1-56592-692-7 summary Get the most out of your Lego Mindstorms The Unofficial Guide to Lego Mindstorms Robots Review by Will Ware

Last year, Lego released their Mindstorms Robotics Invention System. Using this, children and adults can build simple robots whose behavior can be programmed. The Mindstorms system is a major contender for Coolest Toy on the Planet.

The system contains a RCX programmable brick containing an H8/300 microcontroller, some pushbuttons, a little LCD display, and connectors for motors and sensors (light and physical contact). The user writes a program using a graphical programming language on his Windows box, and downloads it to the RCX via infrared.

Not surprisingly, substantial reverse engineering (1, 2) has been done by hobbyists, and it is possible to develop Mindstorms programs on a Linux box and to download the RCX brick from Linux.

Now O'Reilly has joined the Mindstorms fray, with a book full of fun and useful information about how to build and program Mindstorms robots. The book describes four different robots: Hank is a bumper car robot, Trusty uses light sensors to follow a line along the floor, Minerva has a movable arm, and two identical robots play a game called RoboTag. Along the way, the author discusses the physics and mechanics of robots, programming issues, and the available development environments for Mindstorms.

What's Good? There are detailed building instructions for each of the robots, showing photos at various stages of construction. The designs are simple and appear mechanically sound. There are discussion of the physics and mechanics of tank treads, steering, gears, and other things.

The book's chapters sequentially step through several different software development environments. The first chapter starts with the Windows-based RIS environment that comes on the Mindstorms CDROM. Later chapters give programming examples for NQC (Not Quite C), pbFORTH, Visual Basic, and the legOS operating system, which uses an EGCS cross-compiler to target the H8/300. There are more development platforms available, but these give a good sense of what's possible in Mindstorms programming.

The book has dozens of useful URLs, for both official Mindstorm sites and unofficial hobbyist sites. I particularly liked the fact that the author was aware of some of the recent research in robotics. For instance there is some discussion of Rodney Brooks' subsumption architecture, which is used for the RoboTag robots.

Later chapters of the book often expand on designs from earlier chapters, building more sophistocated robots in an accessible, incremental fashion. For the more adventurous hobbyist, the final chapter talks about building your own sensors and actuators, and how to connect them to the RCX.

What's Bad? Some of the photos are too dark and lack contrast. It would also have been nice if the photography had been in color, but black-and-white photos kept the book more affordable.

This book is for the casual weekend robot-building tinkerer, and it never promised to discuss real-time embedded issues in depth. Still, a few topics might have merited at least brief mention. Systems with real-time multitasking must frequently arrange for synchronization and communication between tasks, using mutexes and mailboxes and the like, which brings the possibility of deadlocked processes. Another danger is that an aggressively efficient compiler will sometimes optimize away reads and writes to hardware registers. The fix is to declare such registers with the volatile keyword.

Review by Kurt DeMaagd

While Lego Mindstorms were officially released for a teenage crowd, they have become popular with a wide variety of technically competent people in many age groups. This widespread fascination has opened up a whole new world of opportunities for using Mindstorms. At the same time, the documentation and tutorial included with the Lego kits provide very little information about how to get the most out of the sets. This book fills the void by providing several start-to-finish robot designs, software to run them, and a wealth of other tips and tricks.

After a brief introduction to robotics and how Legos fit in, the author discusses the basics of using Mindstorms to create them. Both chapters present a problem, provide step by step building instructions, provide the necessary information to program the solution, and finally go into greater detail about the Lego features used to solve the particular problem.

While the chapters did an excellent job of presenting this information in general, they fell victim to a problem that would plague the entire book: some of the building diagrams were nigh unto unreadable. Attempting to build a robot based on fuzzy black and white photographs can be quite a chore. Fortunately, none of the robots were so complex that they robots were completely unbuildable.

The first few chapters presented robots programmed with the default RIS programming environment. In chapter four and following, he shows how to program using languages such as Not Quite C, Forth, Sprit.ocx for Visual Basic--or optionally Visual C++ or another ActiveX-aware language--and legOS. Since much of these sections was documenting API's, it was certainly not the most exciting read, but it does provide concise, easily to reference documentation.

Not Quite C, as the name implies, is a C-like language that can be used to program Mindstorms robots. It overcomes many of the limitations of the default RIS programming environment, most notably the lack of variables. One of its biggest advantages is that it does not require the user to install a new version of the firmware on their RCX unit. In general, it provides an excellent balance between power and usability.

The remaining three means of programming presented in the book are fairly mediocre options. PbForth requires the user to download a new firmware version, and the language itself is very archaic in modern software development terms. Using Sprit.ocx is a viable option for people used to programming in Visual Basic or Visual C++, but the control structures are very clunky and non-intuitive. legOS, while it is probably the most powerful option, takes a significant amount of time to set up and develop applications with.

Two of the projects referenced while discussing the various programming languages were particularly interesting, both of which outlined infrared communication. The first program creates a simple remote control for controlling a robot via the IR port on the RCX. The other example, perhaps the most interesting in the book, was creating two robots who played tag with each other. These two robots also communicated with each other via their IR ports.

The last chapter, targetted toward the hard core Mindstorms users outlined how to create additional sensors for Mindstorms. It sketched out such possibilities as a passive light sensor, a Hall effect sensor (magnetic fields), and a touch multiplexor (allowing you to have more touch sensors than normally allowed on the RCS unit).

In general, the book provides a vast array building and programming tips, tricks, and methods. He gives basic information for the person who is just starting, and introduces the advanced user to the vast network of people and product that have made Mindstorms far more than a child's toy.

Purchase this book at fatbrain.

Table of Contents

Preface

1. Welcome to MINDSTORMS
What is a Robot?
Mobile Robots
What is MINDSTORMS?
What Now?
Online Resources

2. Hank, the Bumper Tank
About the Building Instructions
Building Instructions
A Simple Program
Wheels
Bumpers and Feelers
Gears
Multitasking
Online Resources

3. Trusty, a Line Follower
Building Instructions
Some Tricky Programming
The Light Sensor
Idler Wheels
Using Two Light Sensors
Online Resources

4. Not Quite C
A Quick Start
RCX Software Architecture
NQC Overview
Trusty Revisited
Online Resources

5. Minverva, a Robot with an Arms
Building Instructions
Programming
Directional Transmission
Pulleys
Mechanical Design
Two Sensors, One Input
Where am I?
Online Resources

6. PbFORTH
Replacement Firmware
pbForth Overview
About Forth
pbFORTH Words
An Expensive Thermometer
Minerva Revisited
Debugging
Online Resources

7. A Remote Control for Minerva
Two Heads are Better Than One
The Allure of Telerobotics
Building Instructions
Programming the Remote Control
Programming Minerva
Online Resources

8. Using Sprit.ocx with Visual Basic
You May Already Have Visual Basic
About Spirit.ocx
Calling Spirit.ocx
Immediate and Delayed Gratification
Programs, Tasks, and Subroutines
Tips
Retrieveing the Datalog
Online Resources

9. RoboTag, a Game for Two Robots
Building Instructions
Subsumption Architecture
Online Resources

10. LegOS
About legOS
Development Tools
Hello, legOS
Function Reference
New Brains for Hank
Development Tips
Online Resources

11. Make Your Own Sensors
Mounting
Passive Sensors
Powered Sensors
Touch Multiplexer
Other Neat Ideas
What About Actuators?
Online Resources

A. Finding Parts and Programming Environments

B. A pbFORTH Downloader

C. Future Directions

Index