Simon's accelerated X development thread

Hi there,
does anyone know what license I need to release my code under? I'm terrible at these things! There is no license information in the source code I'm building (in a readme or otherwise), and searching on the x.org wiki for 'license' gives nothing. However wikipedia says that Xorg itself is licensed under the "X11 license". This takes me to "MIT license" which tells of the ambiguities between these different licenses.

I have made some modifications to Xorg itself, and used the fbdev driver as a base. There's not much left of that driver in there though...

What do I do?
EDIT: I'm being blind, I've found the existing license files. So - do I have to use the same license?

I think that you use the same license as the project you modified. Not entirely sure though.

Any license that doesn't violate the parent license is fine. If it's MIT, you could GPL it, for example, you can also close it off. If you're concerned with people not sharing modifications they distribute, you should consider a GPL compatible license. Otherwise MIT or Apache are good open (not 'free') source licenses.

Linux is GPL v2 for reference, it is a free and open source license.

Cool thanks.
I'm not yet ready to give out the code for the VPU binary, but the driver will work happily without it - but it is an important part of it as it gives a decent speed win. There's nothing special in the code, it's just that it includes an assembler I've written that I don't really want other people to use. Not until there's an existing open source VPU toolchain that's robust.

Is there a compatible license I can use which is "I'll release some of the code, but not all of the code"? I could always break it into two projects - one which uses MIT/GPL/whatever and the other which is closed source?

It's a common misconception that everything associated with an open-source project has to be released as open-source, and this is generally simply not the case. Anything licensed as open-source that's modified must also be released as open-source, but pre-built, proprietary code that either only extends (e.g., with its own APIs) or supplements (e.g., tools and utilities) the open-source code can be included as long as it is clearly labeled as such (e.g., via comments in source files and README files). There are tens of thousands of commercial companies doing precisely this every day of the week in complete compliance with open-source licenses.

The precise mechanisms and notification text for how this is done can vary between the licensing schemes, but the most popular licenses all support this concept. Yes, there are some who believe that all software should be open-source and that anything that isn't should be reverse-engineered without the benefit of a so-called "Chinese wall" and given away for free, but their proposals haven't been adopted by very many similarly-minded adherents.

The sticky stuff with the licencing is the GPL related stuff. Some of it isn't clear cut, since it all comes down to how separate things need to be before they're not derrived works. I'm not an expert, and if you wanted to know more you could contact the Free Software Foundation. That said, if you close off things that should be opened, someone might just point it out and ask you to open things later.

Just looking over your github, and I'm not sure if it's everything involved at this point, copies-and-fills is derrived from GPL code, so it must be GPL, and anything that includes or links to it must also be GPL. If you didn't actually derrive from the original code and wrote a completely from scratch assembly file, then you can licence it however you choose.

The kernel is GPL as well, so the kernel module stuff must also be GPL.

XFree86 is MIT licence, which only requires you to preserve their copyright notice, you are under no obligation to release source, though if your patches require a modified version of XFree86, you'll have to basically take responsibility for maintaining your proprietary fork if you want people to keep using it, passing along the source to the XFree86 team means you could possibly get it incoporated into the main trunk, ensuring that it stays maintained.

I don't know how your VPU code integrates with the system, if it's a library that talks to GPL software via a strict API that separates the internals (like GL does), then you can probably keep it closed without any real issue. If its operation requires any GPL code to couple tightly to it, shares a lot of internal state information, shared memory, etc... then it's probably going to have to be GPL'ed regardless of if it statically or dynamically links. Dynamic kernel modules are a good example of this.

If it's just uglyness or just requring one to be really on top of things to understand the code or tools, I don't see any reason to keep it closed. You're not obligated to provide easy to use software, and others can potentially learn from viewing the source. If you put it out there, and you're the only one in the world who truly understands it, that's still ok.

I'm a developer of video games, and it's all proprietary stuff, and proprietary software has its place. But personally, anything I develop for the Pi I intend to make GPL (though I may need to change the licence on my xf86-video-rpi to MIT in order to get it adopted into the trunk), so that the device's primary audience, the future hackers and tinkerers of the world, have some really meaty stuff to look at.

Keep in mind that GPL ('Free') software clearly doesn't mean "Must be given away". Its intent is to provide users with all the freedoms you enjoy as the author of the software, except for the right to further restrict those freedoms. You also only have to provide the source upon request if it doesn't come with the binaries, and only to those you have disributed to. So for example, if you sell GPL binaries, then you're only obligated to give the source to someone who buys it from you, and you can wait for them to ask. Anyone you didn't sell to has no right to request the source.

At any rate, the easiest thing to do is probbaly to keep the same licence as whatever the code most tightly couples with. If the code is 100% original and functions relatively independantly of other programs, even if linked, then do what you want, it's your work. Some people will likely fuss about freedom, but then they can try and write their own VPU layer. Broadcom isn't about to open their firmware, and I honestly don't care if they ever do. I'm happy enough to have a graphics stack that works.

Excellent post. As a Free Software advocate however I'd have to recommend releasing as much as possible under a non-permissive free software license like the GPL. This insures that society continues to benefit as a whole from your work not just an individual developer. Permissive licenses (MIT, ZLib, Apache etc) allow developer to take source code and make it closed, benefitting only themselves.

"benefitting only themselves" ??

I'm not sure the average person who would use accelerated X would feel that the developer was only benefitting themselves. Quite the opposite.

Interesting point , but aren't we OT already ?

ghans

[jamesh]

Excellent post. As a Free Software advocate however I'd have to recommend releasing as much as possible under a non-permissive free software license like the GPL. This insures that society continues to benefit as a whole from your work not just an individual developer. Permissive licenses (MIT, ZLib, Apache etc) allow developer to take source code and make it closed, benefitting only themselves.

As said above - releasing binaries of software benefits everyone who uses the software. Releasing the source benefits a few more people (always <= total number of people benefiting) , and perhaps increases the benefits if they then improve the software. It's not correct to say it benefits no-one.

Just looking over your github, and I'm not sure if it's everything involved at this point, copies-and-fills is derrived from GPL code, so it must be GPL, and anything that includes or links to it must also be GPL. If you didn't actually derrive from the original code and wrote a completely from scratch assembly file, then you can licence it however you choose.

Code: Select all

This code is licensed under the GNU Lesser General Public License version 2.1

The copies-and-fills code is LGPL, not GPL, which is a big difference.

GPL = viral to everything that runs in the same address space.
If you load a GPL library into your program, your program and all other libraries the program depends on must be open source.

LGPL = non-viral.
You need to keep the copies-and-fills library itself under LGPL. But other code does not need to be.

Kernel is indeed GPL without the L, so kernel module and everything that runs in kernel space must be GPL.

Yep, I hate the virus nature of GPL and pretty much have to avoid it whenever where possible.
Anyway - can I LGPL my driver? Is that compatible with the original MIT license fbdev came with?

Anyway - can I LGPL my driver? Is that compatible with the original MIT license fbdev came with?

If fbdev_exa contains code directly copied from fbdev it might be better to release it under its original license, to avoid discussion.
Problem is that some MIT/BSD-style licenses require that the original author is acknowledged in the product documentation, while standard LGPL does not require this.

Just looking over your github, and I'm not sure if it's everything involved at this point, copies-and-fills is derrived from GPL code, so it must be GPL, and anything that includes or links to it must also be GPL. If you didn't actually derrive from the original code and wrote a completely from scratch assembly file, then you can licence it however you choose.

Code: Select all

This code is licensed under the GNU Lesser General Public License version 2.1

The copies-and-fills code is LGPL, not GPL, which is a big difference.

GPL = viral to everything that runs in the same address space.
If you load a GPL library into your program, your program and all other libraries the program depends on must be open source.

LGPL = non-viral.
You need to keep the copies-and-fills library itself under LGPL. But other code does not need to be.

Kernel is indeed GPL without the L, so kernel module and everything that runs in kernel space must be GPL.

Oops, missed the Lesser. Anything MIT should be compatible with LGPL, since the license basically says "Without restriction, provided this notice is included in the source". But the reverse wouldn't be true, since LGPL already imposes some restrictions.

Oops, missed the Lesser. Anything MIT should be compatible with LGPL, since the license basically says "Without restriction, provided this notice is included in the source".

Be aware that MIT/BSD-style licenses often say "software" there instead of "source"
Meaning that you must reproduce the copyright notice (give proper credit to the original author) when you redistribute it in binary form instead of source as well.
Be it in the documentation, an "about" box or some similar place.

That is sometimes forgotten.

Oops, missed the Lesser. Anything MIT should be compatible with LGPL, since the license basically says "Without restriction, provided this notice is included in the source".

Be aware that MIT/BSD-style licenses often say "software" there instead of "source"
Meaning that you must reproduce the copyright notice (give proper credit to the original author) when you redistribute it in binary form instead of source as well.
Be it in the documentation, an "about" box or some similar place.

That is sometimes forgotten.

Does that mean he could reproduce the notice in a text file then?

Thanks again for all the clarification guys.

I've included the original licenses and readmes, and creditted the original author - which I had already done. Then in *my* readme I say it's LGPL, and making it clear what's derived from what etc etc.

I do intend to provide the source for the VPU code at a later date, so that people can modify the blending code or use it to learn from etc. However I just don't want to make the assembler itself available and that's a pretty core part of it.

Release going on the forums this evening.

Thank you so much for this fantastic work!

Absolutely amazing! People who got a RasPi for Christmas, like myself, to use as a cheap ARM device have arrived at the best time!

cant wait for the release
Finally a reason to pickup my Pi after it was sitting all alone in the corner

It has been released on a different thread viewtopic.php?f=63&t=28294

It has been released on a different thread viewtopic.php?f=63&t=28294

Thanks for the link!
Downloading now!

Hi.

I'd like to clarify something:

"Kernel is indeed GPL without the L, so kernel module and everything that runs in kernel space must be GPL."

Kernel developers intend a mixture of proprietary and free kernel modules. This can be seen from this passage in the kernel source code file, module.h.

Code: Select all

/*
 * The following license idents are currently accepted as indicating free
 * software modules
 *
 *      "GPL"                           [GNU Public License v2 or later]
 *      "GPL v2"                        [GNU Public License v2]
 *      "GPL and additional rights"     [GNU Public License v2 rights and more]
 *      "Dual BSD/GPL"                  [GNU Public License v2
 *                                       or BSD license choice]
 *      "Dual MPL/GPL"                  [GNU Public License v2
 *                                       or Mozilla license choice]
 *
 * The following other idents are available
 *
 *      "Proprietary"                   [Non free products]
 *
 * There are dual licensed components, but when running with Linux it is the
 * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
 * is a GPL combined work.
 *
 * This exists for several reasons
 * 1.   So modinfo can show license info for users wanting to vet their setup
 *      is free
 * 2.   So the community can ignore bug reports including proprietary modules
 * 3.   So vendors can do likewise based on their own policies
 */


So while it is true that many kernel developers strive to have all modules open sourced, this is not required. In fact, many kernel modules are available only as closed source, such as graphics drivers, etc.

You can read more about the topic here:
http://linuxmafia.com/faq/Kernel/propri ... dules.html


Johan.

Hi,
Is there any progress?

Nay, I didn't have much time to work on it at the beginning of the year. When I did restart there were some weird bug reports which I could never repro, then I realised that it's just not worth the effort...the demand for an accelerated X is much lower than you might imagine.

I was under the impression that there wasn't an opportunity to do much acceleration because moribund X apps do so much single-pixel rendering that the benefits of acceleration are outweighed by the costs of setup and calling mechanisms.

The heck with X - I've been wondering about the possibility of building at least a browser that's designed to use the GPU, e.g., via OpenVG for the 2-D stuff and OpenGL ES for 3-D things like WebGL. The GPU is how video has to be played anyway, so screw the single-pixel-oriented junk. Then, a 3-D desktop could be developed - I just happened to be reading the proceedings from past SIGGRAPH conferences while boning up for the induction a couple of weekends ago of Pixar co-founder Ed Catmull as a Computer History Museum Fellow. The first paper from the 1992 conference predicted that 3-D desktops would be the next natural step in user interfaces as the cost of 3-D hardware dropped to commodity levels. For a variety of reasons, that never happened and one of the reasons is the legacy of X and other old-school implementations. As Nicholas Negroponte once wrote, the fax machine was probably one of the worst-abused inventions ever devised when used to transmit scanned versions of documents printed on paper from Word files and similar original digital forms.

We're long overdue for 3-D X Window, whether it's built on WebGL, OpenGL (ES), etc. Who's with me?

[Jessie]

Having an accelerated browser would go a long way to improving the user experience. I agree with your assessment Jim, it is a worth-while goal IMO, but I lack the skills to make it happen.

Yep. html5 hardware accelerated browser would be really nice