For Approval: Some License Or Another

Chuck Swiger chuck at codefab.com
Tue Nov 30 01:40:28 UTC 2004


Lawrence Rosen wrote:
>><snip> As you
>>say, you're inventing this as you go, so I'm pleased to see that
>>you're willing to make changes.
> 
> I've avoided commenting on some recent licenses partly because this
> "inventing as you go" experience turns me off. And from what I am told
> privately, many of the lawyers on this list tend to tune out when the
> discussion turns to non-lawyers debating "what if I changed X to Y and A to
> B...." There are just too many open source licenses, and too little time, to
> give that much attention.

I value the contributions you have made, and I hope you chose to comment on 
issues which interest you in the future.  Beyond that, should people pay 
particular notice to whether any one individual responds to a thread (or not)?

I'm not sure what else to say; are you suggesting that this mailing list ought 
to prohibit such discussions because they aren't relevant?

> Which brings up the larger question: Why do we keep receiving requests for
> approval of new licenses? 

It seems perfectly reasonable to me that an author of a software program who 
wants to "share" it with other people might want to write a license which 
describes the terms they want their software to be shared under.

It also seems reaonable that software authors would attempt to use an existing 
license rather than writing their own if they (a) knew about suitable 
licenses, and (b) felt confident that they understood them well enough to 
trust what they meant.

Given the effort that it requires even from qualified legal professionals to 
understand some of the more complex software licenses, it doesn't suprise me 
at all that software authors are not adopting some existing licenses.

> Does anyone seriously believe that our customers
> and distributors can keep up with this barrage?

FreeBSD handles this situation by:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-restrictions.html
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/LEGAL

...which handles the 370 exceptional license cases out of ~12000 or so 
software distributions, including Sun's Java; DJB's stuff; OpenSSL, OpenSSH, 
commercial SSH, and other forms of cryptography; various emulators using 
copyrighted ROM or boot disk images; and so forth.

Questions about the license status of some port appear less often than monthly 
on the <freebsd-ports at freebsd.org> mailing list.  People ask why 
"such-and-such a package isn't available as a prepackaged binary?", perhaps 
once a week. [1]

This issue doesn't seem to represent a big problem. [2]

	--

However, I would be interested to know what groups of people you mean when you 
say "customers" and "distributors"?  Does the OSI board share a common 
understanding of this usage?

For myself, I think of OSI-related issues in terms of authors and users, and 
the latter group I also regard as "potential future authors".  My observation 
has been that license candidates which make much distinction between these 
groups of people are likely to not be compliant with the OSD.

> Perhaps we ought to require license submitters to go through a private
> process of requesting changes to specific already-approved licenses before
> an entirely new license is proposed?

Are you suggesting that license submitters should not be allowed to discuss 
changes to their licenses on this mailing list without paying a lawyer?

I wasn't aware that the intended purpose of this mailing list was to generate 
business for your profession.  While I do not object if you desire to solict 
more business, Larry, I would question whether this forum is the correct venue 
to do so. [3]

> If an idea is a good one, shouldn't it be easier to get an existing
> licensor to adopt that provision for his license rather than try to
> convince customers to adopt something entirely new?

There exist a number of software authors who do not see the need to convince 
other people to use their software, and are more interesting in specifying 
license terms which suit their own perceived needs.

I agree that the situation would be better if authors chose to use existing 
licenses for their software.

> As the author of a few approved licenses, I can count on the fingers of one
> hand the number of times that people have come to me and said, "Your license
> would work for me if only it were changed this way...." That happens
> occasionally, and that's largely why the OSL/AFL licenses are at version
> 2.1. But far more often I'm not asked to make improvements to my licenses.
> Instead, license submitters just start from scratch with something new, over
> and over again. Isn't that tiresome?

It certainly can be tiresome, although I would say there has been some degree 
of interesting ideas or novelty in some licenses that have been proposed over 
the past year or two.

The specific issue which bothers me is licenses which fail to be internally 
coherent, much less consistent within a particular legal framework.  The most 
recent example would be a lack of version number in the GFSL even though the 
critical/controversial clause 9(2) depends on such.

-- 
-Chuck

[1] Someone points them to the resources mentioned above and suggests the user 
look at the specific license terms of such-and-such.  Whether that user then 
chooses to use the software, or is unable or unwilling to accept the license 
is up to them.  This seems to be an appropriate division of responsibility.

[2] I could make similar observations about Fink, or dselect/apt, or pkgsrc, 
but there are other people who know about and might describe those systems 
better than I could, and it also seems redundant.

"Inept excess verbiage disqualifies qualifiers."  :-)

[3] To be very specific, between these comments and your 7-line .sig 
mentioning your company, contact info, and the book you wish to sell, I'm 
getting the same feeling I had when the lists on securityfocus.com started 
including advertisements in the footer of every message.




More information about the License-discuss mailing list