[erlang-questions] A PropEr announcement

[Kostis Sagonas]

We are happy to announce the first official public release of PropEr, a
QuickCheck-inspired Property-Based Testing Tool for Erlang.

The release comes with a proper site containing a User Guide, tips and
tutorials for PropEr. It can be accessed at:

http://proper.softlab.ntua.gr/

Among other things, it has a proper contact address on which we will be
very happy to receive comments and feedback. Depending on interest, we
may also set up a mailing list for PropEr users.

Enjoy!

Kostis Sagonas (on behalf of the PropEr developers)
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Edmond Begumisa]

Thank you, thank you, thank you!

The tutorials are pure gold.

It takes a little getting used to, but PropEr is a wonderful tool, even
for someone new to automated testing.

- Edmond -

On Sun, 12 Jun 2011 23:23:38 +1000, Kostis Sagonas <kos...@cs.ntua.gr>
wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[James Churchman]

Amazing news for those who's projects fall below the radar of needing commercial support but really want to test their code to destruction, as we all should! Will lightly improve the standard of all erlang code out in the wild!

James

ps :
One majorly nit-pciky thing... its more a personal hate than anything else.. I love the "Shirt & Tie with the erlang badge on it" logo, really fantastic.. less keen on the text as an image. On anything but the default zoom setting it looks blurry and you see lots of double anti-aliasing.. as the FontFace stuff is not yet widely supported best technique is to have a div with a background image of both a jpg/gif and an svg as well, any browsers that support svg will pick it up and all others get the jpg like ;

#title_image_div
{
background-image: url('images/logo.jpg');
background-image: none,url('images/logo.svg'), url('images/logo.jpg');

[James Churchman]

yes with out the font that you like in unsupporting browsers, so it looks totally different in them :-) using SVG you get pixel perfect rendering from a vector with an image fallback, which is more suitable for logo's etc... like the one in question :-)

On 12 Jun 2011, at 19:00, Dale Harvey wrote:

@fontface is very well supported and falls back gracefully, which image replacement does not.

[James Churchman]

( actually im wrong, it is widely supported, but requires a different font format for every browser and renders very poorly in IE at larger font sizes... http://blog.themeforest.net/tutorials/how-to-achieve-cross-browser-font-face-support/ )

[Francis Joanis]

Hi,

Thanks a lot for the release :)

I have a question about the GPL licensing of the tool itself: since it is GPL, doesn't it require to make the written tests themselves and to some extent the application under test GPL as well?

I'm obviously not a lawyer, but I'd like to know whether it would be possible to test commercial code using PropEr given its GPL licensing?

Thanks again,

Francis

[Vik Olliver]

On 14/06/11 11:01, Francis Joanis wrote:
>
> I have a question about the GPL licensing of the tool itself: since it
> is GPL, doesn't it require to make the written tests themselves and to
> some extent the application under test GPL as well?

Only if you distribute the tests. If you keep them to yourself, you
don't owe anyone anything. The GPL respects privacy.

Vik :v)

[Francis Joanis]

On Mon, Jun 13, 2011 at 7:09 PM, Vik Olliver <v...@catalyst.net.nz> wrote:
>
> Only if you distribute the tests. If you keep them to yourself, you
> don't owe anyone anything. The GPL respects privacy.
>

Thanks, that makes sense.

Francis

[Ulf Wiger]

On 14 Jun 2011, at 01:09, Vik Olliver wrote:

> On 14/06/11 11:01, Francis Joanis wrote:
>>
>> I have a question about the GPL licensing of the tool itself: since it
>> is GPL, doesn't it require to make the written tests themselves and to
>> some extent the application under test GPL as well?
>
> Only if you distribute the tests. If you keep them to yourself, you
> don't owe anyone anything. The GPL respects privacy.

This could become an obstacle to adoption similar to what's been seen with Quviq QuickCheck: people who have Open Source projects need to publish (=distribute) test suites as well. Just as it's not very helpful to distribute test suites that require an expensive tool, people might be reluctant to publish PropEr-based tests if it requires them to convert to GPL.

Kostis did say that they would make an exception for OSS projects. I could not find any such exception when quickly scanning the repos.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com

[Zabrane Mickael]

+1 to try to convince Kostis to release PropEr with a better license!

Please vote!

Regards,
Zabrane

Le 14 juin 2011 à 14:02, Ulf Wiger a écrit :

> On 14 Jun 2011, at 01:09, Vik Olliver wrote:
>
>> On 14/06/11 11:01, Francis Joanis wrote:
>>>
>>> I have a question about the GPL licensing of the tool itself: since it
>>> is GPL, doesn't it require to make the written tests themselves and to
>>> some extent the application under test GPL as well?
>>
>> Only if you distribute the tests. If you keep them to yourself, you
>> don't owe anyone anything. The GPL respects privacy.
>
>
> This could become an obstacle to adoption similar to what's been seen with Quviq QuickCheck: people who have Open Source projects need to publish (=distribute) test suites as well. Just as it's not very helpful to distribute test suites that require an expensive tool, people might be reluctant to publish PropEr-based tests if it requires them to convert to GPL.
>
> Kostis did say that they would make an exception for OSS projects. I could not find any such exception when quickly scanning the repos.
>
> BR,
> Ulf W
>

[Richard Carlsson]

On 06/14/2011 02:02 PM, Ulf Wiger wrote:
> On 14 Jun 2011, at 01:09, Vik Olliver wrote:
>> On 14/06/11 11:01, Francis Joanis wrote:
>>> I have a question about the GPL licensing of the tool itself:
>>> since it is GPL, doesn't it require to make the written tests
>>> themselves and to some extent the application under test GPL as
>>> well?
>>
>> Only if you distribute the tests. If you keep them to yourself,
>> you don't owe anyone anything. The GPL respects privacy.
>
> This could become an obstacle to adoption similar to what's been seen
> with Quviq QuickCheck: people who have Open Source projects need to
> publish (=distribute) test suites as well. Just as it's not very
> helpful to distribute test suites that require an expensive tool,
> people might be reluctant to publish PropEr-based tests if it
> requires them to convert to GPL.
>
> Kostis did say that they would make an exception for OSS projects. I
> could not find any such exception when quickly scanning the repos.
>
> BR, Ulf W

As I have remarked before on this list, I believe the normal GPL (all
versions) cannot be used for Erlang modules, because the dynamic loading
and linking of classes/modules at runtime is not considered to be any
different from static linking - at least according to the FSF.

The standard Erlang library modules and the runtime system BIFs are
published under the Erlang Public License, which is an even more
restrictive variant of MPL. The MPL is not compatible with GPL
(http://en.wikipedia.org/wiki/Mozilla_Public_License#Compatibility_with_GPL),
due to some of its restrictions, so it should follow that the EPL is
also not compatible.

If you want to enforce copyleft in your code, but not force it on other
libraries that link with your code, you can use LGPL instead of GPL.
(Preferably, use v3, which is compatible with Apache License 2.)

http://www.gnu.org/licenses/lgpl-java.html

/Richard (not a lawyer)

[Eric Merritt]

I talked with Kostis about this at the erlang factory. He said he is going to provide the exception to the gpl for open source projects. I think he just has not had time to do the actual work.

[James Churchman]

Could the lgpl not be chosen instead? Would this not allow the tests to be distributed along as they don't ship a custom version of propEr as somebody else states?

Also is it really the case that the tests could not be distributed, or more a case that it is totally fine to distribute the tests along as the person receiving the tests downloads proper themselves? the code that is not tests would still run fine.

Also what was the original reasoning behind choosing the gpl in this case? 

Regards

James

also +1 to try to convince Kostis to release PropEr with a better license!

[Francis Joanis]

+1 as well for me.

Even if it is a far fetched use case, I can imagine a customer wanting
to request a copy of the "test suite" (i.e. including PropEr based
tests) of a commercial product.

Thanks,
Francis

[Jared Morrow]

At a very minimum, the LGPL was invented for cases exactly like these.   So +1 to at least moving it to LGPL if something like Apache, BSD, or MIT isn't wanted.

[OvermindDL1]

Ditto, GPL is completely incompatible with the (non-fsf) open licenses of things I use.  LGPL would work, but with the GPL I would never be able to use PropEr.

[Richard Carlsson]

On 2011-06-14 19:50, Daniel Luna wrote:
> The GNU GPL has always allowed for linking with "system libraries" and
> in version 3 that now explicitly includes the standard libraries of
> common programming libraries.
>
> So I don't know whether older versions of GPL are incompatible with
> Erlang or not, but it seems clear cut that version 3 is.

GPL v2 talks rather specifically about only "the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs", which does not seem to cover things like runtime
libraries of a language implementation apart from the language the OS is
written in. You're right that v3 seems to be much more "modern" in this
regard, so the libraries and runtime system of the Erlang/OTP standard
distribution are probably not a problem under GPL v3.

Still, any other software (i.e., your tests) specifically designed to
depend on PropEr as currently published under the GPL would itself have
to be offered under the terms of the GPL.

> Generally I would not recommend LGPL, but would rather recommend that
> Kostis dual licenses the software. Most (if not all) users would be
> fine with GPL. The few that really, really want to give the tests to
> their clients without also giving away the source code, could then
> purchase a closed source version of the software.

There are many open source projects that wish to include their test code
as part of their distribution, both because it's easier not to strip
them out, and because their users may want to run the tests. If they
want to distribute their main code offering under a non-copyleft license
like MIT or Apache - it's their choice - they could only do that by
splitting the code into one non-copyleft distribution without the tests
and one GPL-compatible distribution with the tests. That's asking quite
a lot of your poor users.

Test frameworks are simply a bit different from other library code, and
I think the licensing should reflect this. But that's all down to Kostis
and Manolis to decide, of course.

/Richard

[Frédéric Trottier-Hébert]

I'm wondering about this myself. If I only provide the tests (including the -include_lib line) but not the PropEr code
itself, is it breaking the license? Technically, none of the PropEr code is running in there, only its API.

--
Fred Hébert
http://www.erlang-solutions.com

On 2011-06-14, at 10:13 AM, James Churchman wrote:

> Also is it really the case that the tests could not be distributed, or more a case that it is totally fine to distribute the tests along as the person receiving the tests downloads proper themselves? the code that is not tests would still run fine.
>

> Regards
>
> James
>
>
> also +1 to try to convince Kostis to release PropEr with a better license!

_______________________________________________

[Torben Hoffmann]

I am afraid that the GPLv3 is contaminating in this case - I have spent some time reading the license and how to interpret it and I also asked around, so I do not think you can ship PropEr test code with your product without becoming GPLv3. At least I personally would not run that risk.

Note that if you are using PropEr internally and you are not shipping the test source or beams you are free to use PropEr to test your code. But if you ship then your code becomes GPLv3 (as I read the thing).

However, as Eric mentioned earlier, the PropEr team is looking into adding a FOSS License Exception and now that the big v1.0 is behind them they hopefully get the time need to investigate this and see if it is possible to do.

The PropEr team has been very approachable about this issue so I think we should just wait for them to find the time it takes to get this done right.

With a FOSS License Exception there will be no issues and it will open the doors for PropEr to prosper for Open Source Erlang projects.

If you want to work with PropEr and receive some guidance from a semi-veteran (me) you can join us on the Erlware team where we are working on property based tests for the erlware-commons and gradually adding them where it makes sense.

Cheers,
Torben

2011/6/15 Frédéric Trottier-Hébert <fred....@erlang-solutions.com>

--
http://www.linkedin.com/in/torbenhoffmann

[Kostis Sagonas]

Torben Hoffmann wrote:
> I am afraid that the GPLv3 is contaminating in this case ...

>
> However, as Eric mentioned earlier, the PropEr team is looking into
> adding a FOSS License Exception and now that the big v1.0 is behind them
> they hopefully get the time need to investigate this and see if it is
> possible to do.
>
> The PropEr team has been very approachable about this issue so I think
> we should just wait for them to find the time it takes to get this done
> right.

Thanks for this comment!

We have discussed the issue extensively yesterday and today we wrote a
mail to the Free Software Foundation to also ask their opinion and their
suggestion on how to properly deal with the issues involved.

Quoting from the mail we sent to FSF:

Our primary concern is that PropEr be as useful as possible to FOSS
programmers. Therefore, the most important requirement from PropEr's
license is that it allows FOSS projects (regardless of license) to:

* use PropEr without restrictions, and especially without needing to
switch to another license
* release their testing code under whatever license they choose
* distribute PropEr freely, to be used as part of the build cycle of
the project, or for other uses (e.g. if the project in question is
an Erlang IDE, it could distribute PropEr as a plugin), again
without needing to switch licenses

The above benefits need *not* extend to developers of proprietary
software. If PropEr's license could restrict them in some way, that
would be an added bonus, but this is not a strict requirement.

Another requirement is that PropEr's license is a (preferably strong)
copyleft: we would like to guarantee that any extensions to PropEr are
also free software.

// ... We also told them about the issue that the GPL is supposedly
// unusable for Erlang programs due to the nature of Erlang.

In short, we are looking for a solution/license that will allow at least
all open-source projects to use PropEr without any restrictions or by
being contaminated by GPL.

I'll be surprised if we do not find a solution, but please bear with us
until we resolve this the proper way.

In the meantime, you can use the software and the proper e-mail address
for questions and comments.

Kostis

[Dmitrii Dimandt]

Then MPL or EPL should work for PropEr, won't they?

To quote from EPL:
3.2. Availability of Source Code.
Any Modification which You contribute must be made available in Source Code form under the terms of this License

This covers the "requirement is that PropEr's license is a (preferably strong) copyleft: we would like to guarantee that any extensions to PropEr are also free software". I believe that extensions can be treated as modifications (I can be wrong here).

As for distribution and usage:

2.1. The Initial Developer Grant.
The Initial Developer hereby grants You a world-wide, royalty-free,
non-exclusive license, subject to third party intellectual property
claims:

(a) to use, reproduce, modify, display, perform, sublicense and
distribute the Original Code (or portions thereof) with or without
Modifications, or as part of a Larger Work; and

(b) under patents now or hereafter owned or controlled by Initial
Developer, to make, have made, use and sell (``Utilize'') the
Original Code (or portions thereof), but solely to the extent that
any such patent is reasonably necessary to enable You to Utilize
the Original Code (or portions thereof) and not to any greater
extent that may be necessary to Utilize further Modifications or
combinations.

3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger
Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code.

[Jon Watte]

Isn't that almost exactly what the lesser/limited/library gpl is for?

However, the "all patent rights may become contested" parts of gplv3 and mpl make those licenses unlikely to be used by real companies, even if they generally support sharing source. Else one of my competitors can take something I release, use it in a system infringing my product patents, and life
becomes really complex really quickly. I would recommend upgrading to lgpl v2.1, or even BSD/MIT, if you really care about people being free to use PropEr for real. As it is, gpl3 based software is not "free" (as in speech) at all for most people.

Anyway, it sounds as if the "L" addition might solve the stated problem, assuming no desired user/collaborator has any patents they care about.

Jw

[Frédéric Trottier-Hébert]

But BSD and MIT do allow commercial users to change and extend the software, write extensions in ways that they can be closed. This is something the PropEr developers want to avoid given the previous messages. So clearly, BSD, MIT and DWTFYW licenses are not acceptable.

--

Fred Hébert

http://www.erlang-solutions.com

[Jon Watte]

Yes. To clarify: My message had two parts:

1) LGPL will solve the stated problem according to the current definition of "acceptable."

2) An argument for changing the definition of "acceptable."
If I want to contribute to PropEr, I can't, because of license. For me, that means the license is not free at all.

Jw

[Daniel Luna]

On 15 June 2011 13:07, Kostis Sagonas <kos...@cs.ntua.gr> wrote:
>  // ... We also told them about the issue that the GPL is supposedly
>  //     unusable for Erlang programs due to the nature of Erlang.

(Hoping that I'm now properly subscribed so that this message actually
reaches the list)

The GNU GPL has an exception for "system libraries" and in version 3

that now explicitly includes the standard libraries of common

programming libraries. So Erlang should be fine with version 3.

The Quick Guide on gnu.org has a short section about that exception
here: http://www.gnu.org/licenses/quick-guide-gplv3.html#less-source-to-distribute-new-system-libraries-exception

/Daniel

[OvermindDL1]

As for a non-license related question, how does PropEr compare to
http://krestenkrab.github.com/triq/ in features, speed, reducibility,
etc...?

On Jun 15, 2:57 pm, Daniel Luna <dan...@lunas.se> wrote:
> /* snip */

[Daniel Dormont]

I'm not a legal expert, but I did study some of this licensing business some time ago, so just a couple of things to bear in mind:

- the question of what constitutes a derived work is an issue under copyright law and may vary by jurisdiction; it is not up to the author of the license to define that. See for example http://en.wikipedia.org/wiki/GNU_General_Public_License#Point_of_view:_dynamically_and_static-linking_violates_GPL

- I don't imagine most proprietary software programs ship with unit tests included. Then again, I could be wrong :)

dan

[James Churchman]

in that its apache 2.0 :-)

As for a non-license related question, how does PropEr compare to
http://krestenkrab.github.com/triq/ in features, speed, reducibility,
etc...?

Is this a fact or a stated FSF opinion? seems counter intuitive that something that writes to an api ( even if it's dynamically linked ) can be considered an alteration of derived work, as what is to stop someone producing an identical api with the same, or indeed a different set of behaviour, does the existence of this "new" api now change things.

Better still what if it targets an intermediate api. In that case if all calls in your code go to notgplmodule:do() which is a dual licensed opensource project, which calls gplv3 code, what happens then??

James

[Amy Lear]

On Wed, Jun 15, 2011 at 6:18 PM, James Churchman
<jamesch...@gmail.com> wrote:
> > - the question of what constitutes a derived work is an issue under
> > copyright law and may vary by jurisdiction; it is not up to the author of
> > the license to define that. See for
> > example http://en.wikipedia.org/wiki/GNU_General_Public_License#Point_of_view:_dynamically_and_static-linking_violates_GPL

> Is this a fact or a stated FSF opinion? seems counter intuitive that
> something that writes to an api ( even if it's dynamically linked ) can be
> considered an alteration of derived work, as what is to stop someone
> producing an identical api with the same, or indeed a different set of
> behaviour, does the existence of this "new" api now change things.
> Better still what if it targets an intermediate api. In that case if all
> calls in your code go to notgplmodule:do() which is a dual licensed
> opensource project, which calls gplv3 code, what happens then??
> James

Magical Things Happen. The tendency for linking to GPL works being
required to be GPL works is a complicated thing that gets contested in
different ways in different places.

Making an intermediate API to present a non-GPL interface to
proprietary code is a pretty well established technique. See: some
video card drivers in Linux, with having a GPL compatible bit that
just creates an interface for the non-GPL compatible bits to later
use.

Making an identical API to an existing GPL based API also complicates things.

From here, the only correct answer is "Consult a lawyer in your
jurisdiction." Unfortunate, but that's how it goes.

[Max Lapshin]

Damn, what a problem in GPL for a testing program?
Guys just want to protect their investment, but want to make a free
advertisement by offering their excelent product to community.
If it would be MIT, they can see their work in commercial product
without any profit for them.

There is absolutely no problem in using GPL software to test your
products: just don't include it into distribution.

Tests are not part of PropEr, but if any of you is afraid of GPL
virus, so don't include tests into your main repository: keep it
separate.
For example, I don't include test files for erlyvideo tests into
repository, because I don't want accidential discussions with their
potential copyright holders.

Btw, about PropEr. It is so widely told, that it is a magic tool, that
can remove all bugs in software, that I'm very interested to try it.
I will try to find time for it and tell if it helped me with erlyvideo or not.

[Vlad Dumitrescu]

Hi,

This kind of issues are worse than flame wars! :-)

I have yet another point of view that increases the confusion: PropEr is mostly compatible with Triq and QuickCheck (there's a free older version). Each tool might have their extensions, but the basic functionality is the same and it should be possible to run basic tests with any one of them (if not at the moment, then in the future). Now if I distribute property-based tests with my open-sourced application, the users could in principle use any one of the tools to execute them. In this case, would the tests still be affected by the fact that PropEr is GPL? If I have tests that depend on a certain behaviour that only PropEr has, and those tests are ifdef'd, does that change the answer to the previous question?

best regards,

Vlad

[Max Lapshin]

Of course, tests aren't covered with the same license.

GCC is licensed under GPL. You are writing C code, which has ifdefs
for GCC and for MSVC. How can you imagine, that someone will order you
to release your program under GPL?

PropEr is just a tool. If you distribute this tool, you must share
sources. You may sell it, but with opened sources. But you don't have
any restrictions about files, that this tool works with.

[Ulf Wiger]

On 16 Jun 2011, at 08:30, Vlad Dumitrescu wrote:

Hi,

This kind of issues are worse than flame wars! :-)

I have yet another point of view that increases the confusion: PropEr is mostly compatible with Triq and QuickCheck (there's a free older version).

Well, there is a version available in jungerl, but to my knowledge, it was not put there by the authors, and not actually intended to be free. Even so, one might consider it a lot less sensitive to copy that version than the later, proprietary, versions of QuickCheck.

"Inspired by QuickCheck" is the wording in the README, or more specifically:

"We have generally tried to keep PropEr's notation and output format as compatible as possible with QuviQ's QuickCheck, to allow for the reuse of existing testing code written for that tool."

(https://github.com/manopapad/proper/blob/master/README.md)

As far as I can tell, PropEr is an unauthorised reverse-engineering effort of the later commercial versions (the early version did not have shrinking or statem support, for example); even if it *had* been in line with EU copyright protections (which allow reverse-engineering for personal purposes, given that a legal copy has been obtained in the first place), publication of the resulting product is not permitted.

I don't know EU copyright laws well enough to know how this affects the legal implications of any PropEr license. I know that if someone would steal a physical item from me, by law I cannot simply steal it back; legal action is required.

BR,

Ulf

This is the Wikipedia version of what the EU has to say about reverse-engineering proprietary software:

"Article 6 of the 1991 EU Computer Programs Directive allows reverse engineering for the purposes of interoperability, but prohibits it for the purposes of creating a competing product, and also prohibits the public release of information obtained through reverse engineering of software.[24][25][26]

In 2009, the EU Computer Program Directive was superseded and the directive now states:[27]
(15) The unauthorised reproduction, translation, adaptation or transformation of the form of the code in which a copy of a computer program has been made available constitutes an infringement of the exclusive rights of the author. Nevertheless, circumstances may exist when such a reproduction of the code and translation of its form are indispensable to obtain the necessary infor mation to achieve the interoperability of an indepen dently created program with other programs. It has therefore to be considered that, in these limited circum stances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the right holder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. Such an exception to the author's exclusive rights may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program."

(http://en.wikipedia.org/wiki/Reverse_engineering)

I assume that reverse-engineering in order to form a basis for research could be said to be in line with the above*, but if the expressed purpose is interoperability with QuickCheck, it seems logical that one should choose a license that encourages future interoperability as well, e.g. by making it easy for Quviq QuickCheck to incorporate innovations from the PropEr side, and contributing back.

* Except the "prohibits the public release of information obtained through reverse engineering of software", which is a bit difficult to get around.

[Jon Watte]

As a commercial entity with (unrelated) IP to protect, I may be able to USE GPLv3 software, as long as I don't distribute to others (free or not), but there is no way I can CONTRIBUTE to GPL v3, because of the uncertainty around usage-based poisoning of patents and other IP.

Regarding "others may make money if it's MIT" -- so what? Is the point to help the world in useful ways, or not? Useful things tend to make money. If there's an alternate, commercially supported, non-gpl license available for payment, that solves that problem, but if you won't make that available, choosing gplv3 just means you choose *not* to help a large set of software developers.

Jw

[Joel Reymont]

On Jun 16, 2011, at 10:43 AM, Ulf Wiger wrote:

> As far as I can tell, PropEr is an unauthorised reverse-engineering effort of the later commercial versions (the early version did not have shrinking or statem support, for example);

How do you tell it's a reverse-engineering effort as opposed to a clean-room re-implementation?

Is QuviQ QuickCheck rocket science that requires decompiling bytecode?

There have been several release clean-room re-implementations of the JVM, how is QuickCheck different?

--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

[OvermindDL1]

On Jun 16, 2011 12:48 AM, "Jon Watte" <jwa...@gmail.com> wrote:
>
> As a commercial entity with (unrelated) IP to protect, I may be able to USE GPLv3 software, as long as I don't distribute to others (free or not), but there is no way I can CONTRIBUTE to GPL v3, because of the uncertainty around usage-based poisoning of patents and other IP.
>
> Regarding "others may make money if it's MIT" -- so what? Is the point to help the world in useful ways, or not? Useful things tend to make money. If there's an alternate, commercially supported, non-gpl license available for payment, that solves that problem, but if you won't make that available, choosing gplv3 just means you choose *not* to help a large set of software developers.
>
> Jw
>

Exactly.  I have contributed code to many non-gpl projects, but I cannot to gpl for the same reason, and likewise I cannot use gpl things either because I always release my code under more permissive licenses because I want it to be actually useful and used and not wage some holy war.

Also, as a side point, in my experiences, when you have someone who is *forced* to release code it is always of such low quality so as to be unusable anyway, where the people who actually want to release code always tend to be much higher and of actually useful quality.  As I see it gpl code not only reduces their audience but they also get fewer quality patches, which makes no sense to me at all.  I make code to be used, not to make a worthless point.

Now my original other question, how does this compare to the one at the afore-mentioned link?

[OvermindDL1]

Oh, and another point, the only code I have ever been paid for is code that I have written for work, everything else is freely released under boost style licenses, and the gpl still makes no sense to me.

On Jun 16, 2011 1:09 AM, "OvermindDL1" <overm...@gmail.com> wrote:

[Ulf Wiger]

On 16 Jun 2011, at 09:01, Joel Reymont wrote:

On Jun 16, 2011, at 10:43 AM, Ulf Wiger wrote:

As far as I can tell, PropEr is an unauthorised reverse-engineering effort of the later commercial versions (the early version did not have shrinking or statem support, for example);

How do you tell it's a reverse-engineering effort as opposed to a clean-room re-implementation?

First of all, my intent was not to pass judgement (IANAL), only to point out that there are other legal subtleties regarding PropEr. But since the point of expressing an opinion is mainly to stimulate discussion, I dug into the legal text in order to try to answer your question.

The relevant EU legal text [1] says, under Article 4 - restricted acts:

"(a) the permanent or temporary reproduction of a computer program by any means and in any form, in part or in whole. Insofar as loading, displaying, running, transmision or storage of the computer program necessitate such reproduction, such acts shall be subject to authorization by the rightholder"

This seems to imply that if it happened as Kostis said - that they wrote PropEr based on available tutorials, articles and documentation, never having been in possession of a copy of the software, this will not constitute a violation of said directive.

Is QuviQ QuickCheck rocket science that requires decompiling bytecode?

It doesn't have to be. It only has to fall under the laws regarding copyright protection.

"3. A computer program shall be protected if it is original in the sense that it is the author's own intellectual creation. No other criteria shall be applied to determine its eligibility for protection."

(Article 1)

But the more difficult part is perhaps what parts are protected in the first place:

"2. Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive."

A possible interpretation of this is that releasing any implementation that almost perfectly emulates the API of a protected program *does* violate the directive, much as a reproduction of a painting would. What is hard to reconcile is whether it is still infringement if the copy was made without ever having been in possession of the original. :)

Presumably, this would also mean that the PropEr authors never used QuickCheck Mini - also a protected program.

BR,

Ulf

[1] "Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs"

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:HTML

[Dmitrii Dimandt]

> Damn, what a problem in GPL for a testing program?
> Guys just want to protect their investment, but want to make a free
> advertisement by offering their excelent product to community.
> If it would be MIT, they can see their work in commercial product
> without any profit for them.
>
> There is absolutely no problem in using GPL software to test your
> products: just don't include it into distribution.
>

This won't work for a lot of opensource projects. GPL is simply not compatible with anything. And since most opensource include tests, the issue of GPL creeping up the chain and contaminating code becomes relevant.

Since you distribute tests which link to both PropEr *and* your own code:
- tests themselves must be GPL, since they link to GPL code
- since tests are now GPL, they cannot link to GPL-incompatible code. Therefore your own code must now become GPL.

I wonder why EPL/MPL is not an option for PropEr?

> Tests are not part of PropEr, but if any of you is afraid of GPL
> virus, so don't include tests into your main repository: keep it
> separate.
> For example, I don't include test files for erlyvideo tests into
> repository, because I don't want accidential discussions with their
> potential copyright holders.
>
>
> Btw, about PropEr. It is so widely told, that it is a magic tool, that
> can remove all bugs in software, that I'm very interested to try it.
> I will try to find time for it and tell if it helped me with erlyvideo or not.

See Kostis Sagonas' presentation on PropEr on erlang-factory.com. It's much better with video, but video isn't there yet

[Vlad Dumitrescu]

On Thu, Jun 16, 2011 at 08:43, Max Lapshin <max.l...@gmail.com> wrote:

Of course, tests aren't covered with the same license.

GCC is licensed under GPL. You are writing C code, which has ifdefs
for GCC and for MSVC. How can you imagine, that someone will order you
to release your program under GPL?

I don't know. But I've seen stranger things in my life :-)

 

PropEr is just a tool. If you distribute this tool, you must share
sources. You may sell it, but with opened sources. But you don't have
any restrictions about files, that this tool works with.

Apparently, that the tests are linked with the PropEr runtime code is enough to contaminate them with GPL.

regards,

Vlad

[Vlad Dumitrescu]

On Thu, Jun 16, 2011 at 08:43, Ulf Wiger <ulf....@erlang-solutions.com> wrote:

On 16 Jun 2011, at 08:30, Vlad Dumitrescu wrote:

Hi,

This kind of issues are worse than flame wars! :-)

I have yet another point of view that increases the confusion: PropEr is mostly compatible with Triq and QuickCheck (there's a free older version).

Well, there is a version available in jungerl, but to my knowledge, it was not put there by the authors, and not actually intended to be free. Even so, one might consider it a lot less sensitive to copy that version than the later, proprietary, versions of QuickCheck.

Quviq released an official mini-version last year.

http://www.quviq.com/news100621.html

regards,

Vlad

[Ulf Wiger]

Yes, but the QuickCheck Mini license agreement, while permitting free use and re-distribution, specifically forbids reverse-engineering. Thus, we should hope that the PropEr developers did not obtain a copy of QuickCheck Mini and ran it in order to learn how it worked, as this would put them in violation of the EU Directives regarding software copyright.

For those who are inspired by PropEr, but are put off by the GPL, using and re-distributing QuickCheck Mini is of course unproblematic. ;-)

BR,

Ulf W

[Richard Carlsson]

On 2011-06-16 08:43, Max Lapshin wrote:
> Of course, tests aren't covered with the same license.
>
> GCC is licensed under GPL. You are writing C code, which has ifdefs
> for GCC and for MSVC. How can you imagine, that someone will order you
> to release your program under GPL?
>
> PropEr is just a tool. If you distribute this tool, you must share
> sources. You may sell it, but with opened sources. But you don't have
> any restrictions about files, that this tool works with.

This is pretty simple: to a compiler, the source code you write are just
input, and the resulting object files are just output, and these are not
affected in any way by the licensing of the compiler itself, just like
editing a photo in GIMP has no legal implications on the resulting image
file.

There is one exception: if the generated object code contains
significant portions of code copied from templates that belong to the
compiler - then the license of the templates applies to the generated
object code. The GNU Bison parser is such a case: see
http://www.gnu.org/software/bison/manual/html_node/Conditions.html#Conditions
for their explanation of how they originally used GPL for the template
code as well, but later dropped that so it could be used freely by anyone.

(This also applies to code fragments in included header files - the
guideline is that macros of up to 10 lines of code are not considered
significant, but if they are larger, the author of the header file
should consider adding an exception to the license - I have done that in
EUnit - or use different licensing for the header files in order to
avoid tainting users' code.)

But in a test framework, you often write code (your tests) which calls
out to the test framework library code. In this respect, test code is no
different from, say, scientific code that calls a math library. The
resulting code, after linking (statically or at run-time) is a work
based on the code of the test framework.

I guess that if the test code is written solely as callbacks, as done in
the Common Test style of test suites, the situation is less clear.

/Richard

[Richard Carlsson]

On 2011-06-16 03:18, James Churchman wrote:
> Is this a fact or a stated FSF opinion? seems counter intuitive that
> something that writes to an api ( even if it's dynamically linked ) can
> be considered an alteration of derived work, as what is to stop someone
> producing an identical api with the same, or indeed a different set of
> behaviour, does the existence of this "new" api now change things.
> Better still what if it targets an intermediate api. In that case if all
> calls in your code go to notgplmodule:do() which is a dual licensed
> opensource project, which calls gplv3 code, what happens then??

Here's a good summary of the FSF's thoughts about combined works, from
the GPL FAQ:

"Where's the line between two separate programs, and one program with
two parts? This is a legal question, which ultimately judges will
decide. We believe that a proper criterion depends both on the mechanism
of communication (exec, pipes, rpc, function calls within a shared
address space, etc.) and the semantics of the communication (what kinds
of information are interchanged).
If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.
By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs. So
when they are used for communication, the modules normally are separate
programs. But if the semantics of the communication are intimate enough,
exchanging complex internal data structures, that too could be a basis
to consider the two parts as combined into a larger program."

By this reasoning, it is for example not sufficient separation to use
two Erlang processes and use message passing to avoid direct linkage -
the connection is still too "intimate".

Using an intermediate/wrapper API doesn't work either; the linked
combination of the GPL code, the wrapper code, and your code, becomes a
single larger work, and the GPL will apply to all of it (also covered in
the FAQ).

An API in itself (a list of function names, type signatures and other
calling conventions) cannot to my knowledge be copyrighted, because it's
simply not considered a "work" that can be protected by copyright laws -
it's too trivial. The question is: if your code is written to use a
particular API (like the one in your wrapper example), can you
reasonably claim that your code is not designed to use a particular
implementation of that API? I.e., do there exist any real alternatives?

The (very) little I know of law is that courts tend to throw out
reasoning that is pretty obviously only trying to create a smokescreen,
like "I wasn't being paid, I just happened to pick up a bunch of dollars
dropped by someone who turned out to be the guy who asked me to do him a
favour yesterday." If the only existing, working, implementation of your
neat wrapper API, is one that just forwards calls to some GPL'ed
library, the "intermediate API" argument won't hold. But reversely, if
you do write a program targeting an API with several available
implementations, then if one of those happens to be a GPL'ed library, it
doesn't affect your code, because it wasn't designed to use that library
specifially, and it's up to your users if they choose that
implementation. (I know I've seen a good summary of this stuff once, but
I can't seem to find a reference right now.)

So, if there was once just one implementation, using GPL, of a
particular API, and someone does a clean-room implementation of that
same API but under a different license like MIT, then as far as I can
tell, that does change the situation, at least as long as the non-GPL
implementation is somehow available to the users of your code. I.e., I
don't think you can create an alternative and buggy implementation, lock
it up in your vault, and then claim that your program isn't necessarily
designed to use that GPL'ed library that actually works.

It's of course also possible for the author of a library to use the GPL
with an exception that says something like "as long as you as a user
just call these API functions, the GPL licensing doesn't affect your own
code even if you link with this library". But if there is no such
exception, you won't get around the GPL by a simple wrapper. Using
separate OS processes and pipes for communication _might_ be enough, but
probably not if you're marshalling complex data structures in an obvious
attempt to get around the GPL.

/Richard

[James Churchman]

Part 1)

Ok better still, if the PropEr team really do feel that this is the kind of project that would benefit from begin gpl licences ( it's not... tho i can see the benefits for something like the linux kernel of being gpl ) then if i understand correctly to fix all theses problems all they need to do is :

The interface module & the macro header to PropEr needs to be dual licensed,

All the clever code that does all the property testing can still be put as gpl.

Part 2)

To ask the wider question, is the worry of some commercial company grabbing the source and making a heavily modified close source version that is better, then attempting to *sell it*, really an issue:

There *already was* a closed source version, called "QuickCheck" and this got, in its near entirety, fully cloned, and in a relatively short space of time. I really cant see a few additions made by some unknown erlang company ever working :

A) There are not that many companies that know erlang well enough:
>> Even if for some unknown reason erlang solutions tried to do this, not that they would, there are still enough erlang coders out in the world to look at the version being sold, and to very very very very very very rapidly, if the additions are good, clone them again.. as i said before the entirety of PropEr is a clone to start with
>> There is no other erlang company that has even 50 % of the erlang talent, even dare i say erricson ? so not other company could even come close..

B) The additions made to PropEr are unlikely to be so substantial that people would pay thousands for these additions...

C) What any company would really pay for is the commercial support, the brains to produce very *good* tests, training, and if they really needed their own additions to the property based testing tool, these to be written by the people who know along with a lot more, none of which is the tool its self, but the brains who *understand* the tool
In *all* these cases they would go to QuviQ to have them do it, not to some odd startup that has a mildly bastardised PropEr that they refuse to open source

In this case ( and not the case of say linux etc..) i can only see the gpl getting in the way of the very purpose of the tool, and think that in the long run there will be a total NEED for the erlang community to produce a testing tool that is truly "free". "triq" should be possible to "trick" out, as it is apache 2, everybody can comfortably contribute, has the basic underpinning, and would be worth the effort in the medium, and definitely long term, to everybody.

James

On 16 Jun 2011, at 13:10, James Churchman wrote:

>> Magical Things Happen. The tendency for linking to GPL works being
>> required to be GPL works is a complicated thing that gets contested in
>> different ways in different places.
>>
>

> hey amy, thanks for your reply

>
>> Making an intermediate API to present a non-GPL interface to
>> proprietary code is a pretty well established technique. See: some
>> video card drivers in Linux, with having a GPL compatible bit that
>> just creates an interface for the non-GPL compatible bits to later
>> use.
>>
>

> well then, an intermediate (mit+gpl) module, lets call it "prop", fixes all the issues then :-)
> add in a few cleanroom macros and that sounds like an hour long job! anybody willing?
>
> ...no need to panic guys... :-)
>
> James

[Joe Armstrong]

On Thu, Jun 16, 2011 at 11:44 AM, Richard Carlsson <carlsson...@gmail.com> wrote:

On 2011-06-16 03:18, James Churchman wrote:

Is this a fact or a stated FSF opinion? seems counter intuitive that
something that writes to an api ( even if it's dynamically linked ) can
be considered an alteration of derived work, as what is to stop someone
producing an identical api with the same, or indeed a different set of
behaviour, does the existence of this "new" api now change things.
Better still what if it targets an intermediate api. In that case if all
calls in your code go to notgplmodule:do() which is a dual licensed
opensource project, which calls gplv3 code, what happens then??

Here's a good summary of the FSF's thoughts about combined works, from the GPL FAQ:

"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
 If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
 By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

What a load of complete and utter nonsense - what does "are intimate enough mean" etc.

What about systems that are non-deterministic? If I send a message to a black box
and it tosses a dice to see if it will reply then surely this is not an "intimate communication"

Black box abstract says that two systems are identical if their observed I/O behavior is identical.
But if I open the black box and discover either one or two communicating things inside then
the law is *different* since in the one case I do not have to consider the intimacy of the relationship and the
other I do.

The basic idea in object-oriented programming is *independent* objects communicating by
message passing. Would a lawyer in a court of law have to decide if a collection of communicating objects
constituted one program or many - what happens when you put them all in the same address space
like smalltalk - is this one program or two thousand small programs each with it's own license.
 

By this reasoning, it is for example not sufficient separation to use two Erlang processes and use message passing to avoid direct linkage - the connection is still too "intimate".

No if you send a process it might on good day if it feels like it send a reply.

Image two nodes one in Sweden the other on the moon with flaky communication - sometimes a reply
to a message would be received sometimes not - anyway in the absence of a formal proof one would never
know if a message will be returned unless you can solve the halting problem.


/Joe

 

[Richard Carlsson]

On 06/16/2011 02:59 PM, Joe Armstrong wrote:
> What a load of complete and utter nonsense - what does "are intimate
> enough mean" etc.
>
> What about systems that are non-deterministic? If I send a message to a
> black box
> and it tosses a dice to see if it will reply then surely this is not an
> "intimate communication"
>
> Black box abstract says that two systems are identical if their observed
> I/O behavior is identical.
> But if I open the black box and discover either one or two communicating
> things inside then
> the law is *different* since in the one case I do not have to consider
> the intimacy of the relationship and the
> other I do.
>
> The basic idea in object-oriented programming is *independent* objects
> communicating by
> message passing. Would a lawyer in a court of law have to decide if a
> collection of communicating objects
> constituted one program or many - what happens when you put them all in
> the same address space
> like smalltalk - is this one program or two thousand small programs each
> with it's own license.

Basically, yes, if it came to a court case, it would be up to lawyers.
The little I know of law is that the kind of abstract,
down-to-first-principles reasoning that we programmers like to entertain
doesn't usually impress the courts. Law is pretty different, and is very
much about intentionality - both the intentions of the lawmakers (even
when the paragraphs aren't totally clear, there may be other background
material, previous cases etc., that are used as guidelines), and the
apparent intentions of the accused: it's hard to get away on an abstract
technical point if it's rather obvious that you were trying to do
something against the intention of the law - see for example the case
against the Pirate Bay where the defendants were found guilty of
"assisting in making copyrighted content available", even though they
claimed they were only running a kind of billboard service and it was
down to the users what they decided to publish on it.

When it comes to software and licenses, it all boils down to the
question "did the defendant intentionally create program B in such a way
that it builds on program A, without complying with the licensing terms
of program A", and I don't think the defense "but it's all just objects"
is likely to work. But the exact boundaries of how B may or may not
build on A have never been extensively tried in court as far as I know,
so there is definitely some uncertainty here. (And if they ever are
tried, I pity the judge and jury who will have to listen through hours
of geeky arguments about static and dynamic linkage, separate address
spaces, marshalling, etc., and try to make any sense of it.)

[Edmond Begumisa]

Just to clarify/reinforce, what gets a little confusing in these
discussions are the rights and obligations between licensor and licensee,
which is a contractual arrangement and subject to the doctrine of privity.

[Continuing with the mentioned hypothetical]

* If the PropEr developers have copies of QuickCheck Mini, then they bind
themselves to a license agreement with Quviq, including the promise not to
reverse engineer.
* If PropEr is GPL'ed, and Vlad uses it, he binds himself to an agreement
with the PropEr developers, and the terms thereunder.

Vlad is not privy to the first agreement, and thus can never be held
liable for its breach, if there is such a breach. And he cannot be
expected to stop using a version he already has. (Though he might have the
rug pulled out from under him, should PropEr development cease and future
versions stop being made.)

However, assuming all parties are in Europe, and although the concept of
freedom of contract generally applies, they also bind themselves doctrine
that they can never make an agreement that contravenes codified EU law -
including said reverse-engineering law in said copyright statute. Then the
aggrieved party need not be privy to an agreement to have their rights
enforced since these rights are not established by an agreement, but by a
statute. In this case, Vlad and all PropEr users in Europe could well be
ordered by a court to cease using the program regardless of any agreement
they have with it's developers (since such an agreement would be
considered invalidated.) Hypothetically speaking.

That said: Erlang being a small-friendly community -- I assumed (and like
to continue to a assume) that PropEr and QuickCheck developers have not
only been aware of each others projects, but I also like to think that
they've been in touch with each other and sorted out any such concerns
before version 1 of PropEr was announced. Like Erlang, I prefer to think
of the happy case!

- Edmond -

On Thu, 16 Jun 2011 18:23:04 +1000, Ulf Wiger
<ulf....@erlang-solutions.com> wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Edmond Begumisa]

Aaaaa ... the all to common Legislature vs Judiciary problem.

* Legislators make laws.
* These laws are made sufficiently vague (usually due to "legislative
compromise" or plain incompetence)
* Courts have to interpret vagueness, judges make precedents to do so.
* Legislators then complain that judges are making their own laws...

"Not their mandate! The Judiciary should only enforce laws that *we*
make," they scream.

Maybe engineers should make laws that pertain to engineering! Heck, maybe
engineers should be on the bench for enforcing those laws!

- Edmond -

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Edmond Begumisa]

On Fri, 17 Jun 2011 12:56:59 +1000, Edmond Begumisa
<ebeg...@hysteria-tech.com> wrote:

> Just to clarify/reinforce, what gets a little confusing in these
> discussions are the rights and obligations between licensor and
> licensee, which is a contractual arrangement and subject to the doctrine
> of privity.
>

CORRECTION: This was inaccurate. A licensee agreement is not strictly
contractual agreement, but a license may be passed as consideration
exchanged as part of a contractual agreement. Nevertheless, the privy
doctrine usually applies to agreements in which licenses are past in most
jurisdictions.

[Ulf Wiger]

It has been brought to my attention that some have interpreted my posts in this thread as gunning for Kostis. I am not. I sincerely hope that no one has been on the wrong side of the law here (and even more that there will be no attempt at legal action). Knowing Kostis, I am pretty certain that he had very carefully considered what he was doing.

I think it is extremely important to have a discussion about not just what is strictly legal, but also how we as a community act to show respect for other people's right to innovate and make money on their innovation.

OTOH, Kostis definitely could have written a quickcheck-like tool with a different interface, staying absolutely clear of even the slightest risk of being accused of infringement. Safer for Kostis, but actually worse for the community. I believe it is better, ultimately for all parties involved, that the APIs are almost fully compatible. I hope that Quviq will find a way to profit from this too, not least since they have done a tremendous amount of good for the Erlang community.

Uncritically applauding acts of essentially cloning other people's IPR may have unwanted consequences.

Let's consider for a while that one of the main driving forces behind the current patent system is the Pharmaceutical industry. Why? Much because it is extremely expensive to develop and approve a new drug, but very cheap to copy it. 

It's clear that OSS is pushing the point at which one can charge for a software component higher and higher. Today, it seems, if you don't have several man-years of effort invested in your software, you might as well not even bother, since as soon as you launch, chances are that someone in the OSS community might decide to build a free version just as a fun exercise.

I can't help thinking that this sort of activity is mostly self-gratifying, and doesn't take into account the fact that the Open Source community has yet to figure out how to be self-sustaining. Much of the money that funds Open Source (or at least pays the rent for those who contribute to it) comes from largely proprietary companies.

What OSS has so far demonstrated is that giving things away for free can be extremely beneficial for innovation and quality. On the topic of ensuring steady revenue and managing to pay people's salaries at the end of each month, it has some way to go still.

BR,

Ulf W

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[James Churchman]

making something with a similar-ish api to something else is not reverse engineering. its a rewrite from scratch. reverse engineering would be disassembling the beam files to discover how they work, simply reimplementing them it is not. if that was the case there would be one cd player, one car, one bike, one washing machine, one fridge, one operating system etc.. in the world and never ever a second version, and having a copy of the original will make no difference, if you clean room something, as long as you don't break any patents in the process.

[James Churchman]

Dear Ulf

I agree almost entirely with the sentiment of your email. I think that it is quite easy to be in a position where you are funded by external bodies, in the case of proper being funded by a large university and also EU grants, and then afford to give the software away for free. I also think it makes it a tad rich to release it under something as restrictive as the gpl given that it's the profits of the commercial companies, by virtue of paying taxes, that have in effect funded the software, tho it is of course in the end entirely the decision of the original authors.

I however take a different take on the mater of open source and startups, especially in the case of developer facing tools. Taking the case of QuickCheck as the perfect text book example, it is crazy to turn up with a fantastic product that costs thousands of pounds & is totally closed to any contributions, present it to hundreds of the cleverest programers in the world and then expect them not to copy it when it is that good and also not something beyond the abilities of those people to build themselves. In the world, which is nothing but a realised version of game theory, this is crazy.

Also how long was this meant to continue? is it realistic to think in 10 entire years nobody would produce a copy, or 5 , or 3 ? There was an obvious huge demand and the barrier to building one far lower than that huge demand.

What it shows is that you want the benefit of these other people contributing to your product, essentially out-sourcing half the costs and innovation, and then sell some ancillary thing. If you create the tool you should know the most about it, and even if you don't people will approach you first. The world is a moving place, especially the world of IT. ( I would also argue that in many regards this is the basis Erlang Solutions operates on, Erlang is open source, and it sells its expertise in erlang whilst contributing somewhat back to erl/opt)

Also in the case of QC i would assume that 95 % of people who wanted to use it did not, entirely due to cost, and that 100 % of people who wished to contribute to it could not, and by the pure definition of the tool all 195 % of those people were ALL developers.

Therefore if you look at the biz model that by contrast Process One etc. etc. etc. follow they provide the software totally open, and in their case i think they were further clever picking up on an already popular open source project rather than an untested home grow affair, and this allows students that might be building the next Facebook or Google to use the software and pay for what they need in the future if / when they need to pay for things as well as when they have the cash to do so. I doubt ejabberd would have 1% of the users and even that process one would have a profitable biz if it was a closed up shop, tho that is a difficult one to back up.

I don't think this applies to all products, but it seems to apply to many developer tools in the software industry. Other products probably less so, as its harder to coordinate say the design of a fantastic GUI between hundreds of dispersed developers, and for many consumers they are not aware of the open alternatives, don't mind paying a few $ and are not comfortable compiling code etc.. but i think this is an ok situation as consumers don't want & would not pay for training, support contracts, custom extensions to be written etc.. for their copy of photoshop elements.

And you want to start with that model reasonably early, then hope to make it a successful business, not have the ticking time bomb of when something 0 cost, open source and in many cases far far superior come out & you have to change everything, as well as you becoming the awkward non-industry standard option.

In the case of property based testing, i would imaging that there is a far far far larger biz around supporting PropEr, if it becomes the industry standard teasing tool that every single erlang dev uses, than there is in selling the software outright, as writing good test can be tricky, so i hope that Quviq works this out and do prosper greatly from this opportunity :-)

James

[Edmond Begumisa]

On Fri, 17 Jun 2011 20:43:51 +1000, James Churchman
<jamesch...@gmail.com> wrote:

> making something with a similar-ish api to something else is not reverse
> engineering. its a rewrite from scratch.

I didn't say that it was, and neither did Ulf.

Ulf just raised a hypothetical chain of events which may be interpreted by
_some_ people reading _some_ statutes as reverse engineering.

In said hypothetical legal dispute -- what *you* and *I* think is reverse
engineering doesn't matter. What matters would be the aggrieved parties
argument for interpretation of the statute, and any precedents supporting
such an interpretation, but most importantly, their evidence for the facts
and chain of events that lead up to the dispute, and ultimately how well
both sides can convince the court in session. In such a dispute, the
defendant/respondent may well present the the points you raise as part of
their side of the case.

My point was in regards to whom would be liable to whom in such a dispute.

- Edmond -

[Eric Merritt]

Guys,

None of us are lawyers (I think ;) so lets leave the legalities to
the lawyers. If you are really worried about things buy a QuickCheck
license otherwise Kostis has produced a good open project that finally
makes property based testing (an extreme improvement over simple unit
testing) accessible to the average joe, from a price perspective yes,
but even more importantly from an openness perspective. Kostis is
working on the license issue and I suspect will come out with
something pretty acceptable.

Eric

[Edmond Begumisa]

I love PropEr!

One of it's early adopters (I think).

- Edmond -

On Sat, 18 Jun 2011 00:07:52 +1000, Eric Merritt <ericbm...@gmail.com>
wrote: