[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] New Update Manager UI : Your thoughts

I like it!

Do that, plus make the default be: plugin provider requires you to agree to
the license agreement.

-Don


On 6/13/07 2:41 PM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:

> To clarify my point, it was that if a plugin provider chooses to _require_
> that the user acknowledge a license (this is the software equivalent of
> signing a contract or signing a waiver absolving the provider of liability),
> the UI should not be able to bypass that.
> 
> I don¹t think it necessarily needs to be that complex -- in line with
> "keeping simple things simple'.
> 
> So a possibly more elegant solution would be that accepting a license _the
> first time_ drops a digital signature locally.  Any future updates from a
> site that presents that same signature would not require acknowledgement
> because it is in the local cache (similar to SSH keys, if you know what I
> mean).  This allows a one time agreement to the license.  If the provider
> decides to change the terms of the license and needs the user to acknowledge
> it, he simply changes the signature he presents.
> 
> The beauty of this is, if you have an application with an installer it can
> simply install the signature file and therefore the user would never be
> prompted to accept an agreement by the software (he would have already
> acknowledged it in the installer).
> 
> -Brett
> 
> 
> On 6/13/07 1:28 PM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
> 
>> OK, lets step back and look at it differently.
>> 
>> I don¹t think this would be illegal, but I am not a lawyer, and I don¹t play
>> one on TV.
>> 
>> Infor (the company writing the software) is using equinox server-side to
>> assemble an ERP system at WidgetCo, the company that manufactures widgets.
>> 
>> This is not an eclipse IDE of any kind.
>> 
>> WidgetCo and Infor have a licensing agreement between them. WidgetCo has
>> purchased a license for Infor¹s software and can receive free updates for 1
>> year from the purchase date. Now, instead of automatically accepting license
>> agreements, we have a more complex requirement, but a real one that needs a
>> solution.
>> 
>> Possible options:
>> 
>> 1. There are update sites that are always trusted by the update manager. The
>> user that sets the ³I trust this update site² flag must have in essence
>> agreed
>> to the license in advance. Such as free updates for a year as per a license
>> agreement. In this case, Infor will stop populating the WidgetCo update site
>> with new versions after a certain date, and the onus is on Infor to make this
>> happen. Probably by getting a new license agreement signed. Very little needs
>> to be done in the update manager in this case, except to trust sites that are
>> marked as trusted. Notes could be added as to why it is trusted, perhaps.
>> 
>> 2. The update sites in the update manager could have attached multiple
>> license
>> keys. These keys are transmitted to the update site with the update request.
>> Now the update site is not a simple set of web pages and resources served by
>> a
>> apache. It needs to be a web application that can validate the license keys.
>> The update site either sends the updates or rejects the request.
>> 
>> 3. The update site provided by Infor could be behind a password protected
>> URL.
>> Access to this URL is only given to customers that have a signed license
>> agreement. The license requirements are all handled outside of the scope of
>> the update manager. The the update manager, the update site is marked as
>> trusted.
>> 
>> 4. Infor provides a password protected URL from which WidgetCo can download
>> an
>> update site that WidgetCo can host locally. Again, Infor and WidgetCo have
>> the
>> license agreement managed outside of the scope of the update manager. This
>> downloaded and hosted update site is marked as trusted.
>> 
>> In all cases, the marking of an update site as trusted means that all license
>> management is being handled outside of the update manager. And the act of
>> marking an update site as trusted means that the administrator has agreed
>> that
>> all licenses required at that site are already handled outside of update
>> manager.
>> 
>> An update site should have the ability to override this and say: ³Never allow
>> update manager to trust me². This could even be the default.
>> 
>> Without introducing a full blown license management system, we cannot get too
>> complex in the requirements here. But server-side implementations will
>> require
>> the ability to trust some update sites and not need license agreements
>> individually agreed to. If only because sometimes there will be no human and
>> no UI present when the update happens.
>> 
>> -Don 
>> 
>> 
>> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
>> 416-543-1085 | don.laidlaw@xxxxxxxxx
>> 
>> On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:
>> 
>>> I think there are legal ramifications, at least in the United States for
>>> that.  While we¹re all annoyed by licenses, I don¹t think you can
>>> ³auto-dismiss them² any more than you can stamp your car loan with your
>>> signature.
>>> 
>>> -Brett
>>> 
>>> On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
>>> 
>>>> 
>>>> True, but it can also be a policy of a plugin consumer to accept the
>>>> licenses of trusted update sites. Then the consumer only has to determine
>>>> which update sites will always be trusted.
>>>> 
>>>> In using equinox on the server side, the update sites will usually be in
>>>> the
>>>> same company.
>>>> 
>>>> -Don
>>>> 
>>>> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 |
>>>> mobile:
>>>> 416-543-1085 | don.laidlaw@xxxxxxxxx
>>>> 
>>>> On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx> wrote:
>>>> 
>>>>> 
>>>>> The need for license acceptance is  typically a requirement discretion of
>>>>> the plugin provider and not the consumer of the plugins. So allowing the
>>>>> consumer to disable the license acceptance should only be optional at the
>>>>> discretion of the plugin provider.
>>>>> 
>>>>> Peter 
>>>>> 
>>>>> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:
>>>>> 
>>>>>> 
>>>>>> The provisioning system should already know about the sites and
>>>>>> should be able to discover more.
>>>>>> 
>>>>>> Actually I missed in there where the users said which plugin they wanted.
>>>>>> 
>>>>>> User should not have to accept a license if the plugin is coming
>>>>>> from a known/trusted site.  Sites should be ranked in this way
>>>>>> 
>>>>>> Restart may not be needed
>>>>>> 
>>>>>> Jeff 
>>>>>> 
>>>>>> 
>>>>> 
>>>>>> 
>>>>>> "Prashant Deva" <prashant.deva@xxxxxxxxx>
>>>>>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>>>>> 06/12/2007 08:26 PM
>>>>>> 
>>>>>> Please respond to
>>>>>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>>>>> 
>>>>>> To 
>>>>>> 
>>>>>> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>>>>>> 
>>>>>> cc 
>>>>>> 
>>>>>> Subject 
>>>>>> 
>>>>>> Re: [equinox-dev] New Update Manager UI : Your thoughts
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Ok, here is some thoughts on the gui for installing a new plugin.
>>>>>> This is in keeping with the philosophy of keeping the simple things
>>>>>> simple.
>>>>>> I wish there were a place where I could upload some docs and sample
>>>>>> images to make the point more clear, but i will just type some stufffor
>>>>>> now. 
>>>>>> 
>>>>>> 1.        User clicks on 'Install new plugin' button
>>>>>> 2.        Dialog box with single text field asks to enter the url of
>>>>>> pluign update site.
>>>>>> 3.        update manager automatically gets the latest available
>>>>>> version of the plugin.
>>>>>> 4.        asks the user to accept the license.
>>>>>> 5.        if license accepted, then installs plugin and asks user
>>>>>> torestart. 
>>>>>> 
>>>>>> The update site url, etc are automatically saved by the program and
>>>>>> user doesnt need to give a 'name' along with the url as we have to do
>>>>>> now.
>>>>>> Also no dialog box for confirming 'install all'. All user has to
>>>>>> enter is the url and accept the license.
>>>>>> 
>>>>>> the dialog in step 2 can have an 'advanced' button, which when
>>>>>> selected allows user to choose the exact version to install.
>>>>>> 
>>>>>> your thoughts? any compulsory steps in the install process we might
>>>>>> be missing this way?
>>>>>> 
>>>>>> prashant_______________________________________________
>>>>>> equinox-dev mailing list
>>>>>> equinox-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>> _______________________________________________
>>>>>> equinox-dev mailing list
>>>>>> equinox-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
416-543-1085 | don.laidlaw@xxxxxxxxx