> Proposal: come up with set of goals and desires rather than legal
> text. Send these goals over to license-discuss. I am happy to
> Shepard this process. Let them ensure that whatever goals are desired
> still is "open source". Once we have that then it requires taking the
> time (and possibly money) to find a lawyer willing to write the
> license. This is the only way you are going to get a useful license
> that may stand up in court.
>
> In this case it seems almost like GPLv2 would meet your needs exactly.
>
> I do have some concerns that the GPL is meant for code, not hardware,
> but since the hardware actually *is* code (verilog or whatever) this
> isn't a real concern.
There is going to be some problem with this, and we're only going to
find it out with lots of review, and maybe litigation. This is why
I like explicit dual (or triple, or more) license models.
I'd also propose we start *from the beginning* by tracking every
contributor, so that if at some point we do need to change the license,
each and every contributor can be offered some sort of notification to
either approve the new license, or state their code must be cleanroomed
for a new license.
This is technically a project policy, with the goal of allowing migration
to a new license. Linux, for example, has no way to move to anything other
than GPLv2.
> Suggestion: start with GPLv2 because it sounds like what you want
> already. Let the discussion play out and then possibly change it
> later.
how about: GPLv2, or at your option, GPLv3, or AGPLv3, or any later version
> I would however consider an apache like patent retaliation clause ("if
> you sue us over patent issues, you lose your rights to use the
> software").
>
> > Ok. So at the very least, I need two documents, one for licensing terms,
> > the other for project policy.
>
> Yes. You may also need a third: the actual "copyright assignment"
> form. Personally, I'd look into a foundation for this effort or ask
> the SPI if they are willing to act as the host for the assignment. I
> am willing to approach them provided there is consensus on this list.
> Note that requiring copyright assignment is very useful for the goals
> of the project (eventually licensing out the work to commercial users)
> but it does tend to reduce contribution.
My thought is we want unofficial (or even official) development forks
and sandbox clones that take code regardless of assignment, but that
there's a good policy (and code to validate that 'official' releases
only use code that's been properly assigned)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
