Thank you for taking the time to review the documents!
On Aug 14, 2004, at 4:49, Joe Orton wrote:
> 1. "When your application is not licensed under either the
> GPL-compatible Free Software License as defined by the Free Software
> Foundation or approved by OSI"
> this is still vague and ambiguous, and talks about the future in the
> present tense. What is "the GPL-compatible Free Software License"
> the FSF define? Neither OSI or FSF approval is relevant to the FLOSS
> exception anyway.
This clearly needs to be fixed. I will modify this to specifically
reference the FLOSS exception and to discuss what additional rights the
exception grants users.
> 2. "If you distribute MySQL Software within your organization, you
> should purchase a commercial license."
> this is a direct contradiction of the FSF's interpretation of the GPL.
> 3. "If you include the MySQL server with an application that is not
> licensed under the GPL or GPL-compatible license, you need a commercial
> license for the MySQL server."
> Why? "including the MySQL server with an application" is very vague.
> Sounds like "mere aggregation" to me.
Two and three are good points, but sensitive ones. We rely on having
our proprietary users who distribute MySQL pay us licensing fees to
help fund further development. To do this, we need strong language in
our policy documents. At the same time, we know that our policy needs
to be accurate and fair.
I will add these specific issues to the issue tracker as soon as the
new tracker is online and will start discussing with the rest of MySQL
As for the request tracker, I have already made the request with our
web-team to get things rolling, so it should not be too long. (Though
there is the possibility that the web team is trying to enjoy their
> After all the efforts on the FLOSS exception, it's a shame to see stuff
> like this, which make it sound like you impose *restrictions* on the
The policy documents are older than the new FLOSS exception by at least
1/2 of a year and are clearly weak or inaccurate in certain areas.
Also, it is important to consider that these documents were written to
satisfy internal MySQL review. A document written to satisfy the people
inside of a organization is very unlikely to really speak to the needs
of those outside of the organization.
We are undertaking this activity with the understanding that we need to
listen to our community of users and involve them in the process of
making choices that affect them.
We tried this approach out with the second version of the FLOSS
exception and were pleased by how well it worked. Granted, the process
had many flaws, but the overall result was far better than our attempts
with our first FLOSS exception. Some of the most notable changes were:
* better transparency
- using a simple request tracker made it easy for everyone to see
what was going on
- that cut out a lot of confusion and uncertainty
- people could easily see when we had stalled, instead of having to
* less boring work
- by archiving the issues in the request tracker, we had many less
comments to deal with
- most people seemed to agree with the initial set of issues raised
and we did not have to engage in the same discussions over and over
* easier internal discussions
- knowing what people want and think is better than guessing or
- clear feedback from the community helps remove some matters of
personal opinion from our internal discussions
- instead of us arguing about how the community feels, we knew how
various informed and vocal people felt about specific issues
- this removes some uncertainty from our discussions
* more brains working on the same problem
- by giving people a voice, they were willing to share their
thoughts with us
- the more people thinking about the issues and discussing them, the
- this is exceedingly valuable to the entire MySQL community, as
this entire project is moving in mostly uncharted territory