[ quotes are from various people ]
>> Could we try for something LGPL like instead of GPL. This allows this
>> code to be mixed with freely licensed hardware as well without losing
>> the motivation for the restrictive license.
>
> I specifically DO NOT want this. By applying LGPL some company could sell
> this in their SoC for $billions, as long as they published their
> modifications to just the GPU portion. If someone uses this under the
> terms of the GPL (like putting it together with other open source hardware
> components), then I want to encourage that and don't want to ask for
> royalties. If some smart phone maker decides that our design is more
> energy efficient than PowerVR and wants to use it in their SoC, then I want
> us to bring in revenue in the same way that PowerVR does.
The smart phone maker could make the entire SoC GPL, make $billions,
and not pay us a penny.
Also, what about the "mere agregation" loophole. In software,
a statically linked binary would need to be all GPL. But there
is also runtime (dynamic) linking. In userland you can split
part out into a separate binary and "link" it with a pipe.
In hardware, on the same die would obviously be considered linked.
Separate boards would generally be considered not linked,
although if they come fastened together one could make an argument
that they are linked. What about two packages soldered to a common
circuit board? What about two packages soldered directly together?
What about two dies in a common package?
> Meanwhile, I need something I can slap on code I want to post
> to the list next week
As long as you retain ownership, you could slap on a temp license
that is very restrictive. ("All rights reserved" or whatever, IANAL)
You can always re-release it later with fewer restrictions, once you
figure out exactly what you want the normal license to be.
> I tried dual-licensing and got into some trouble over it.
Since you are concerned about this, we ought to go over the
story and try to figure out where the problem was. Something
to do with trading resources for rights to use the design
in closed proprietary commercial products, and the group
didn't know about the deal until later and didn't like
the competition (real or perceived). Is that the trouble
you're worried about?
IIRC you've said that people didn't understand the dual license,
and that was the source of the trouble. If that is the problem,
rewriting the license isn't necessarily the best solution.
Maybe write up a good explanation of the license for non-lawyers.
Or,... maybe part of the trouble was that people objected to the
deal being secret? The project is supposed to be about being
open and transparent. Secret deals raise lots of red flags.
Remember it isn't just about actual wrongdoing, it is also
about the perception of possible wrongdoing.
It may be that some people are GPL purists, and are never going
to be happy with allowing undocumented products to use our
technology.
It may be...<something else I haven't thought of>
> I'll get way more help from my
> students, and if THEY contribute, I have no choice but to let SUNY own it.
I would think that the students would own their work?
> NYS would take 60% of any revenue
I assume NYS = New York State.
So this 60% goes where? Some NYS general fund? And therefore
goes to some random mixture of good and bad things?
You've said you are concerned that others might object to "evil" NYS
taking 60%. How do *you* feel about it? Both the NYS and the 60%.
> I could probably license this under BSD or MIT, and no one in NYS would
> raise an eyebrow. It it would prevent _us_ from getting any revenue;
It would likely reduce revenue, possibly a lot, but it wouldn't
necessarily eliminate all revenue. FreeBSD just announced that
they raised $753,378 and checks are still coming in. Still, given
your stated desire to allow closed uses in exchange for money, a
dual-license seems a better way to go, as we would likely get
more money that way.
> I recently attended the talks of a CERN speaker
> about their OpenHardware initiative
> http://www.youtube.com/watch?v=7PZp-VOeKkc
> http://www.youtube.com/watch?v=iwZw2x0wo2U
Is there something more bandwidth-and-standards friendly
(mostly text with illustrations as needed) than gootube?
> This is _way_ outside of my field, but as I stare into my crystal ball,
> all of this foss graphics driver bs is going to go away over the next
> 5-10 years regardless of what you choose to do. I think that amd,
> intel, and nvidia are all moving to have their parallel processing
> elements able to work in the same address space as your program.
My fear is that it may get *worse*. :-( Look at what is happening with
AMD/ATI. AMD is more or less FLOSS friendly. AMD buys ATI. AMD has
ATI start documenting GPU stuff, but ATI drags their feet and huge
chunks remain completely undocumented after several years and
however many generations of hardware. In part due to their desire
for DRM. They could have easily isolated the DRM hardware by
now and documented everything else but they haven't. Now they
are combining CPU and GPU and DRM all in the same die, and the
integration will continue further. So we have APUs with a bunch
of undocumented crap inside. Meanwhile the CPU designers have
stumbled slightly, so Bulldozer and Piledriver aren't as wonderful
as they should be, plus they are being fabbed with a process that
is a generation behind, and thus aren't selling as well as they should.
If this trend continues, then at some point ATI will be running
the show, if they aren't already.
> I was motivated to start the OGP in 2004 because at the time, there wasn't
> any off-the-shelf graphics card that had FOSS driver support.
And here we are in 2013 and the off-the-shelf graphics cards still
aren't documented, so the FLOSS drivers are pathetic.
So we still need a documented graphics card. And I don't see anything
about that in the recent goals. I see GPL for research, and non-GPL for
commercial, but nothing about documented graphics cards for end-users.
I see a lot of stuff about SoCs, and yes, SoCs are becoming very
interesting. A FLOSS-friendly version of something like the
cubieboard/beagle*/RPi would be great. But there is more to the universe
than SoCs.
My idea of a roadmap for OGP:
Timothy and team design a GPU. In parallel with this, we design a
video card with framebuffer and a socket for optional GPU. I'm
working on this, but will need help. The card will be useful for
many applications even without the GPU. A major goal is to make the
card as useful as possible for a wide range of applications, while
keeping the cost reasonable. Once the GPU is designed, get the thing
fabbed. Now the video card is useful for most applications.
Next: Take GPU, add stuff to make SoC. Get it fabbed. Make FLOSS-friendly
cubieboard/beagle*/RPi type board. Option: does it *have* to all be
in one single die? If it can be reasonably split into 2 dies, then
when you do generation-2 of the GPU, you can update both the video cards
and the SoC-ish board with only one ma$k.
Biggest question is how to pay for the mask?
There is a lot more to it than that, but hopefully you get the
general idea.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
