[Discuss] free/open licenses could discourage participation just because they're unusual

[Mario Gómez]

Hello all,

You'll also have to consider that, in general, for crypto libraries the
culture behind their development is  "Don't roll your own
implementations... Ever!"

Why? Because the cost of introducing a bug on a crypto library could be
higher than just use something that everybody(or almost everybody) agreed
that was working fine and then blame another person if something goes wrong.

The OpenSSL library was widely used and many people tought that it just
worked well. So... What kind of incentives the developers could have to
participate on the review/validation of a source code implementation that
apparently worked OK for many years? Even code analysis tools failed to
identify a problem with the sourcecode.

I think that trying to attribute the problem on the license that was used
just miss the whole picture. And the bigges problem was that the
development team behind OpenSSL didn't were diligent enough to try to
peer-review their code considering that it was used for critical tasks
(even when the people from OpenBSD told them about technical problems in
their source-code).

This could have happened to any project independently of the license used.
If the license was a problem then the people from OpenBSD wouldn't have
started with the LibreSSL proyect that aims to correct the problems with
OpenSSL using the same code-base.

But is a lesson for the whole open source community that, for critical
applications, it's  necessary to implement code-review methodologies that
guarantee that  the code is reviewed by a group of experts before going
into production. (I think that's the way that the OpenBSD people works with
their software).

Regards,
Mario.



On Fri, May 2, 2014 at 10:00 AM, J. Simmons <jrs at mach30.org> wrote:

> Matt,
>
> I don't have any hard data, but I do have some thoughts on this topic.  My
> experience as an observer of (and occasional contributor to) open source
> software is that licenses very much matter (both well known ones and
> one-off licenses).  Just look at the flame wars about licenses and the
> corporate level decisions that happen (at places like Redhat or Apache) to
> be a "insert license here" shop.  I think people can feel so strongly about
> licenses because they are a manifestation of values (if you are a proponent
> of "share alike" then "attribution only" would be a mere shadow of "true
> licenses").  And nothing gets people worked up faster than a disagreement
> over values.
>
> It would not surprise me at all if reactions are magnified for less well
> known licenses (after all they either require potential contributors to
> read and understand a new license, take it on faith that the license
> matches their values, or just skip the project entirely).  Note, I have
> seen other commentary from OpenBSD that points to technical concerns in
> OpenSSL's default error handling, so in this case, the real story behind
> the event is probably very complicated and has many layers of causation.
>
> One final thought, this business about licenses manifesting personal and
> corporate values is one of the reasons why I think it is important to
> develop a range of OSHW licenses that are sanctioned as being compatible
> with the OSHW definition and cover the range of values we see in software
> licenses (GPL-like, LGPL-like, Apache/BSD-like, etc).  And it is why I
> think it is essential for projects to declare their license choice(s) in
> plain site on their project pages so new users and contributors can see the
> project's values when they first visit the project.
>
> Thanks for posting the link,
>
>  -J
>
>
> On Fri, May 2, 2014 at 11:19 AM, Matt Maier <blueback09 at gmail.com> wrote:
>
>>
>> http://www.infoworld.com/d/open-source-software/heartbleed-postmortem-openssls-license-discouraged-scrutiny-241781
>>
>> An interesting theory about why OpenSSL got so little development help is
>> that it has a custom license which is incompatible with standard FLOSS
>> licenses.
>>
>> "*Developers would rather not deal with these issues; as such, they use
>> the code as-is and do the least necessary to comply with the license*"
>>
>> Does anybody know if there is data to support this theory? Do a
>> significant number of developers shy away from projects just because
>> they're unfamiliar with, or annoyed by, a slightly off-of-center license?
>>
>> -Matt
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Open Source Spaceflight Export Control" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to oss-export-control+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> J. Simmons, President
> Mach 30: Foundation for Space Development
> http://mach30.org
>  <https://www.facebook.com/Mach30>  <http://twitter.com/mach_30> <https://plus.google.com/u/0/b/104373960473278544446/104373960473278544446/posts>
>
> *~ ad astra per civitatem ~*to the stars through community
>
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20140502/62710df0/attachment.html>